MARTIN: As an analogy, back in the early part of the century you had roads that were very well developed within individual communities, but the interstate highway system was just getting started. And that’s really essentially what we’re trying to get started with OIC. There’s a lot of great work going on in different areas of the IoT – you’ve got digital health, obviously smart home is huge, you’ve got in-vehicle – but there’s nothing that does a really good job of connecting all of those things together. We believe that while you may have a lot of good things going on in those individual communities, the next big thing in IoT is going to be the applications that span multiple verticals. What we’re really trying to develop is the framework for that.

McCALL: The developer has had an easy time getting connecting a device to a server for many years. All the developer really needs to know is an IP address and port number, and they don’t need to understand anything about Wi-Fi or Ethernet or switches or routers or VPNs. It just works. So you can have a lot of complexity underneath, but from a developer point of view communication is very simple.

With IoT, what we’re really looking at is Moore’s law taking the cost of compute power and communications to the point where you can start putting them into things that previously had neither. So you’ve got all this data, all these control points, and the communications between all these devices is not all going to be through the cloud. The communications between is really complicated and we need to make that simple. Now, we’re not going to be able to provide one solution that’s going to be everywhere because there’s already a lot of fragmentation, but you’re going to want a lot of developers building applications that can access this broad range of data, talk to all these control points with permissions, and so on. We have to make it easy, and we don’t want to have some smart people solving it one way over here, and some other smart people solving it another way over there, then we have 15 different incompatible versions of this framework. Hence, the OIC is an organization made up of some of the leading industry players and smaller companies who are interested in participating in this space, and we are all coming together to solve the interoperability problem once.

Explain a little bit about how the OIC is structured.

MARTIN: We obviously believe that code is important, but there are a lot of companies that approached us saying that they needed a specification to be able to have the business freedom to go off and build a different implementation and still have something that’s compliant. The specification part is where the members of the Open Interconnect Consortium can come in and work together on what the standardization process looks like for discovery and communication.

There were also a lot of companies that did want to look at code, so there’s an open-source reference implementation at IoTivity.org, which is a project that soft launched at the end of 2014. Basically it’s an apache open source project, and the way that that interacts with the OIC is that IoTivity.org is hosted by the Linux Foundation, the governance is all open source, and OIC sponsors that.

One of the things that is kind of exciting is the interesting bi-play between what goes on in the standard and what goes on in the open source project. Technically you could have someone contribute something to the open source project who’s not even an OIC member, and as long as with the open governance it’s a good idea and it’s important enough to that project, there’s a very good chance it could end up migrating its way into the spec, which is an interesting model when you think about it. But also the opposite – what we’re building in the open source project is reflective of the spec, so there’s an interesting interplay between what goes into the spec and goes into the open source project, and how what comes from the open source project may influence the spec at some point.

McCALL: The approach that we’re taking is different from some of the other organizations, not just because we have this combination of standard and open source working together rather than just having one, but we’re also taking a more inclusive approach and trying to have an OIC native way of mapping, which is not us building something new, but taking specific Lego blocks and putting them together in specific orders to provide a general way of communicating. It’s going to be slightly different if you’re talking over Bluetooth versus talking over Wi-Fi, but at the developer level, the API level, it should look the same. They shouldn’t necessarily have to worry about what the underlying transport is.

Beyond the OIC native mapping, there’s also opportunity to talk to other devices by importing them into our resource model. That’s really the focus that we have from a developer point of view – that there’s a single resource model, a clean resource model where the baseline features are ”get, set, subscribe,” and that’s then mapped over everything else, and if you can’t do the OIC native mapping you can then import.

We also handle other, more complex managing of the data that you’re only going to get on the richer devices by making sure there is a core that is in C that can scale all the way down, and we’ve got some of the heavy-duty functions that are in C++. It’s all designed to be portable so we can take this onto multiple operating systems (OSs), and the idea is that the developer shouldn’t have to relearn all of their APIs and working models every time something underneath changes, whether that’s the OS or whether it’s the communication transport (Figure 1). It’s going to be familiar to them how to find devices and how to interact with devices, whether that’s a messaging type communication or a streaming type communication.

 

 

 

 

 

 

What are some of the biggest challenges you see going forward?

McCALL: I think the challenge going forward is, intentionally, there are a lot of different sorts of companies involved in OIC, and because of different vertical markets some of them want to use smart device app-to-app stuff, which is an important part of IoT, but others are wanting to focus on smaller devices. So how we make sure an organization with this scope stays together and produces something that allows people to implement real products in real markets. You’ll see this probably come in stages. The first market that we’re going to have a really solid solution for is consumer. That’s partly because that market just moves faster, and it’s partly because some of the requirements that industrial or automotive have don’t apply, so there’s a little less work to be done. There are companies involved like Samsung, for example, that are very strong in consumer and that’s going to drive some effort in the open source project because, like any open source project, it’s going to move in the direction that the people contributing are most interested in. Then you’ll see us going with the same code base, which we’ve architected from the beginning to perform in those other vertical markets.

Last question. What has your response been to questions about creating “yet another IoT standard?”

McCALL: In the initial conversations we say we’re trying to set up an organization to deal with fragmentation in the industry, and the initial reaction is there are 13 different standards in the industry and you’re creating number 14. We did look at all the other organizations and we compared with what we believed was necessary to provide a high level of interoperability in terms of developer approaches. How do you enable developers to deal with fragmentation in the short term, and also provide in the longer term a path toward some level of consolidation? We’re not going to say everyone should use Bluetooth and stop using Wi-Fi, or vice versa. Those are going to exist. So in the long term you’re going to have to deal with that. But you can maybe have some level where we’re not going to be using multiple different discovery mechanisms. So when you explain the inclusive approach with both the standard and the open source project, and the right IPR foundation – Apache 2.0 license for the open source project and RANDz cross-licensing for certified members – we’re not trying to create something new and then drive it as better than everybody else. We’ll have this native approach that we think of as a sort of sensible mapping, but we’re also working with a lot of existing technologies so that, from a developer point of view, everything is the same.

So for a lot of companies that come in asking why we’re creating yet another standard, when we explain that actually we’re trying to provide in the short term as much interoperability as possible, long term a path to level consolidation, they say, “Okay, that’s reasonable.”

Open Interconnect Consortium

openinterconnect.org

@OpenInterConn

LinkedIn: www.linkedin.com/company/open-interconnect-consortium

Facebook: www.facebook.com/openinterconnect

Google+: plus.google.com/116305832525312494483/posts

YouTube: www.youtube.com/channel/UCc6aqLd9jD5n0_F45NUa9ag