What will be the benefits of interoperability for customers?

Community Feedback
1

Hi all
this came up during a call organised by GOGLA, and I think the topic is both important and not quite well-addressed yet. There is probably a general feeling that interoperability across eg manufacturers and distributors is a good thing, but it is a bit unclear what the (attainable) benefits for customers and end-users broadly will be.

This is particularly important as should those benefits not be apparent or strong enough the risk is for the interoperability effort to be mostly top-down and not gain independent momentum.

This thread is meant to allow that discussion to be developed further

fabio

2

Hi Fabio,

Its probably worth exploring further what types and levels of ‘interoperability’ are being discussed, and in what domains. Here are some questions that come to mind:

  • Considering only “PAYG” devices, or off-grid devices in general?
  • Is the focus on cloud interoperability (e.g. the ability to migrate devices between sales or device management platforms seamlessly), or on device interoperability (e.g. the ability for devices from different manufacturers to communicate with one another?)
  • What distributor use cases are being thought of when the term ‘interoperability’ comes up?
  • Is there concern for a consistent user experience from the customer standpoint, so that one device can be ‘exchanged’ for another with minimal UI/UX change from the end user perspective?

The answers to those sorts of questions might help better constrain the question, as the word ‘interoperability’ is often not, by itself and without context, a particularly descriptive term.

3

thanks Josh for pushing the boundaries to define the scope and definition of interoperability for different actors in the discussion : manufacturers, customers, distributors or cross cutting service providers. This is where it will be worth for Group working on Interoperability to share the roadmap been thought so far : interoperability at device level and at cloud level.

4

I’ll add one more comment that extends what @jjmilburn said. At Angaza, we distinguish between these two types of interoperability:

  • Platform interoperability: The ability for a PAYG device to be able to be managed on one of multiple different PAYG platforms. This capability comes from either the use of an open source token protocol (like Nexus Keycode or OpenPAYGO Token), or through a managed service that provides PAYG device management via an API (like Nexus API).
  • Device interoperability: The ability for devices to communicate with each other, even if they weren’t explicitly designed to do so. This is enabled through the use of industry-standard communication protocols like Nexus Channel on top of a communication system like OpenPAYGO Link.

From the end customer’s perspective, I think the biggest benefit of platform interoperability is greater choice of products and choice between distributors. Distributors can offer a wider range of products without being limited to those exclusive to the PAYG platform they use, and when looking to buy a particular product, customers may be able to choose between several distributors based on the most favorable terms, most convenient payment integrations, etc.

Device interoperability also promises to provide the customer more product choices since they may be able to acquire a variety of devices from different manufacturers that work together. But even within the ecosystem of a single manufacturer’s products, customers can enjoy a much simpler and easier to manage experience as they acquire more PAYG products. For example, managing 5 different devices on 5 different PAYG accounts may be overly complex – but device interoperability would allow all of those devices to be managed on a single PAYG account, with a single token to add credit. Communication between those linked devices and PAYG platforms can also empower distributors to detect problems early and provide better customer support.

5

Thanks Chad for breaking down interoperability layers with platform and at device level. However I see big role of communication here in explaining these terms to first level of customer i.e Distributors. These distributors are the gateway to reach last mile customers. Thoughts on how to bring early stage engagement of Distributors in terms of their feedback and buying into this work to really understand they have complete buy-in into this and any additional feedback to build-in at the design and development phase ?

6

Thanks to all for contributing.
My specific thought here was around device interoperability. I think that is probably the most challenging target, but also the one that customers (as in end-users) may directly see a benefit from. On the other hand, at first sight Platform Interoperability seems something that would immediately benefit distributors - as they would e.g. not be locked in with a platform anymore - but not necessarily the end-users.

I am glad to see that some level of platform interoperability is already happening (kudos to you guys for that, too!) and that is great.
Device interoperability is instead something that clearly will require a more coordinated effort, eg in the establishment of standards on pretty much every layer, from connectors to communication protocols.

There is already an effort in this direction, coordinated by GOGLA. During a recent call, someone asked the million dollar question: what is the need we are addressing with [device] interoperability?
The context to the question is that if there is a need, there will be a natural push to implement whatever solution addresses that very need.
An example of that was USB, where a real need of device and computer manufacturers was to simplify the interface across peripherals and computers. Intel and a few others addressed that need and created the USB standard, which then device manufacturers gladly jumped on.
Sure, Intel was a big player, but they were not addressing a non-problem, so they did not just use their weight to make USB a success, although that must have helped, too.

All the above to explain the initial question further: what is the customers need that device interoperability will address?
Do we expect end-users to plug a Fosera TV into a Sun King SHS? and if they did, how important is it to those end-users that eg the two can talk to each other? How often will this scenario actually materialise? Sure it can happen in theory, but is it a real problem worth solving today?

I am intentionally being critical here, with the purpose of finding a good answer to the questions raised above, as they have been bugging me since I started thinking about them.

Ciao
fabio

7

All the above to explain the initial question further: what is the customers need that device interoperability will address?

I’ll share one perspective around one of the ‘needs’ that come to mind. It relates to the increased number of larger systems as well as PULSE devices being rolled out that either require or gain value by ‘sharing data’ with other devices in the same ecosystem. Whether those are from the same or different manufacturers is somewhat irrelevant to this concern - if you have a pump (with electronics), a separate control system for that pump, and some other solar array ultimately powering the pump, there is some communication between at lease the pump and the control system. Or, imagine a fridge and an SHS in a home, where the SHS communicates ‘something’ about control (both PAYG and non-PAYG) to the fridge. This is a different story from the situation where the market consists only of a bunch of ‘standalone’ devices, where nothing interacts with other devices outside of their own plastic/metal enclosure.

There is the definite possibility of just building ad-hoc, proprietary messaging protocols for these devices that do not interoperable with other devices (even from the same manufacturer). This has a cost in terms of R+D to build something that every industry player now has to build on their own, when really, ‘communicating data between the devices’ by itself probably isn’t a market-differentiating feature. What if there was some way to use a standard reference design that was tested, works for a number of different use cases, and isn’t restricted to those use cases (anyone is free to expand/build upon it without breaking compatibility, to some extent?)

In that case, some industry standards to ‘drop in’ connectivity for the devices saves R+D effort, and increases the possibility of reuse between different product lines (and even potentially manufacturers, given other considerations) in the future. Thats true at the connector level (the ongoing GOGLA discussion I think you referenced), link/transport layer (OpenPaygo Link, for example), and application/presentation data level (Nexus Channel Core, for example).

But the outcome there is specifically reduced R+D, faster time to market, and a platform designed for extensible future feature development (not going to be thrown out and replaced in the next iteration next year, incurring more R+D effort…). The standards probably only get used if they solve the problem, that is, actually save time and effort to let manufacturers get something better to market, faster, without needing to reinvent the wheel every time.

Theres definitely other areas or ways to approach the question (PAYG interoperability between devices, so an end user doesn’t need to enter 5 different keycodes into 5 different devices), or ‘I want to buy a fridge from manufacturer X because it has the features I want, but I like the TV from manufacturer Y, and I want them to work together in some way’, but those are downstream impacts of making it easier for manufacturers to innovate without constraining their development or forcing everyone to invent their own ‘solution’ for the same problem (connecting off-grid devices, similar in some ways to the case you mention around USB - the market doesn’t benefit from having every party go invent their own proprietary interconnection cable and data transfer mechanism between devices - why not standardize it, but in a way that manufacturers can build whatever application they want on top of it?)

(I talk a bit more about this in context in an E4A webinar here, if you want to hear more from that perspective).

8

Thanks Josh for sharing more light on how interoperability is addressing customer needs and potentially preventing manufacturers from re-inventing the wheels. I think its worth to bring some leading and local manufacturers in this discussion to share the interoperability plans to identify any gaps in design team vision Vs. adopters understanding. This will be instrumental in providing the communication roadmap to downstream users.
Please do share you webinar link.

9

Hey Aarti,

Sorry, I should have called out the link to the webinar better (its hard to see in the above post). Its probably nothing particularly different from what I’ve written above, but maybe provides some different emphasis. Affordability of Appliances Webinar Efficiency for Access Design Challenge - YouTube

One of the fastest ways to get manufacturer feedback and direct involvement might be just to directly encourage proposals and edits of the Nexus Channel Core “resource models”. These are the foundation upon which application-layer device interoperability is being built up, and capture ‘what’ might be valuable to share info about with other devices (e.g. battery) and what attributes, specifically, should/could be shared (capacity? voltage? low battery alarm threshold? etc).

The larger question is ‘what application level use cases are actually valuable when talking about sharing resource state between devices?’, which drives what resource models actually need to exist (instead of us just copying every existing OCF/ISO standard resource model out there). For instance, if no one actually cares about monitoring or controlling a fridge/freezer setpoint remotely, does it make sense to ‘standardize’ a fridge resource model with that attribute? etc.

I noticed that there is another thread open about how to make that process better/more streamlined as well: An RFC process to improve Open Source for Energy Access materials

I suspect the connector interoperability discussion is already going on via GOGLA, but I’m not involved at that level personally.

12

Hi @fabio

Since you first bought up this topic, GOGLA has published their white paper about the Connect Initiative.

On the topic of interoperability, the paper proposes the adoption of four Technical Guidelines to ensure that SHS Kits and appliances from different manufacturers work together safely and reliably. Here are the layers involved:

1.Universal Family of Connectors for 12V SHS Kits that will support power delivery and communications for lights, phone charging and many appliances
2.Electrical characteristics (such as voltage and current)
3.Communications protocol (OpenPAYGO Link) developed by Solaris; and
4.PAYGo Activation and Device Control (Nexus Channel) developed by Angaza.

The document concludes that that a “Universal Connector and PAYGo firmware for SHS Kits and appliances could catalyse market growth and offer benefits to companies, consumers, and the environment,” and GOGLA is looking for feedback, debate point, and suggestions. Would be great to hear thoughts from those of you who have already participated in these earlier conversations, as well as get some new people involved - Here are the questions they propose using to form feedback:

1.Does the Connect Initiative present a compelling value proposition for your company, and the industry? What is the value for your company?

2.How will your customers, supply chain partners and investors react to Connect?

3.What do you feel are the main challenges/risks of an industry transition to the Connect initiative? Can these be overcome, and how?

4.Would you like to adopt the Connect Technical Guidelines?

5.How can we work together to make this a reality?

13

Hi everyone, keen to hear your thoughts on this feedback shared by a couple of PAYGo companies…

“The main concern for the Connect initiative comes from our Distribution businesses, who are worried that the money they spend acquiring a customer and getting them onto the company platform could be lost if a customer moves to another product from another provider. Often in our business model, it is the subsequent upgrades to new products where the profit is made for our distribution businesses. What is the business case for a switch to Connect? How can we mitigate this risk?”

Clearly it’s a key questions for companies that are considering aligning their business strategy with Connect. Please share your thoughts.

14

I’m thinking that Connect would allow devices to get their own PAYG update from any other device i.e. if a Connect A distributor’s light bulb connects to Connect B distributor’s home system, the customer would still need to pay A to get the bulb on and B to get the home system on, is that right?

15

I’m thinking that Connect would allow devices to get their own PAYG update from any other device i.e. if a Connect A distributor’s light bulb connects to Connect B distributor’s home system, the customer would still need to pay A to get the bulb on and B to get the home system on, is that right?

Hi Vaibhav,

That particular question (device to device interoperability and PAYG control) is something that Nexus Channel is focused on solving. Right now, a major use case is ‘credit mirroring’, where distributor B’s device (the SHS in your example) is a ‘controller’, which receives and manages credit securely for any number of linked accessory devices (the light ‘A’).

That assumes that light ‘A’ has enough intelligence to implement a basic messaging protocol over any link (even UART), but in cases where light ‘A’ is a ‘dumb’ device, Nexus Channel is irrelevant (then, its just up to connector and electrical standards).

16

That makes sense, would the distributors then sync on payments too? i.e. customer only signs contract with one distributor for the overall package? Or would they have two independent relationships with the distributors in terms of making payments? Sorry maybe that discussion is not exactly about devices interoperating but more the other part of the UX,

17

That makes sense, would the distributors then sync on payments too? i.e. customer only signs contract with one distributor for the overall package?

Thats a great question, but one I’m not equipped to answer well. I think its helpful to consider the separate types of interoperability that @ChadNorvell mentioned earlier in this thread - “Device interoperability” and “Platform interoperability”. At the end of the day, platforms do have a way to control devices, but the way they interact with one another is a separate concern. I am sure someone else here will have better responses on your specific platform related questions, though!

18

Yeah, a good question that has also come up in the consultation. What are the ‘scenarios’ (relationships and payments w different manufacturers and components) that are possible / desirable?

I think that a single customer having an active payment relationship with two different companies at the same time is a recipe for confusion. Whilst it may be technically possible, i don’t think it is desirable for anyone (the consumer has complexity of two different keycodes etc, and the companies w troubleshooting etc. ).
I envisage the most likely scenario as being that a customer gets a SHS Kit w TV (say) from Company A. They complete payments, then want to get a bigger TV. If the products are Connect compliant, the customer could get a TV from company B. (Or… Company A could source and sell TVs from Company B more easily).