Fuse, the open-source connected-car platform I'm working on is stack of technologies that ultimately provide the total user experience. Here's one way to look at that stack:

From bottom to top, the components of the stack are:

1. The device, a CalAmp LMU-3030, is plugged into the vehicle and has a cellular data connection. The diagram leaves out the telephone company, but they're involved as well. The device uses data on the OBD-II port along with data from its built-in GPS to create a stream information about the vehicle that is sent to Carvoyant.
2. Carvoyant uses a telematics server that is designed to interact with the LMU device to receive and process the data stream from the device in the vehicle. Carvoyant processes that data stream and makes it available as an API.
3. Kynetx hosts a rules engine called KRE. KRE is a container for online persistent objects that we call "picos." Each vehicle has a pico that processes its interactions and stores data on its behalf.
4. The Fuse API is created by the software running in the vehicle's pico.
5. Applications (like the Fuse app) use the Fuse API to provide a user experience.

Note that the mobile app is just one of many applications that might make use of the Fuse API. For example, as shown in this diagram, not only does the mobile app use the API, but so does the Fuse Management Console and the iCal feed.

Picos are modeling device that have significant advantages for connected things:

• Picos can be used to model people, places, things, concepts, and so on. In Fuse, we have one for each vehicle, one representing the owner, and one representing the owner's fleet.

• Picos are related to other picos to create useful systems. For example, in Fuse, the owner, fleet, and vehicle picos are, by default, related as shown in the following diagram.

  
• Pico relationships are flexible. For example, a Fuse fleet can have two owners, an owner could allow a "borrower" relationship with someone borrowing the vehicle, and vehicles could have relationships with their manufacturers or service agents.
• A vehicle pico can be moved from one fleet to another simply by changing the relationships.
• Picos store the data for the entity they model. There's no big Fuse database with all the vehicle data in it. Each vehicle pico is responsible for keeping track of it's own persistent data.
• As a result of the pico-based persistent data store, personal data is more readily kept private.
• Further, the pico-based persistent data store allows data about the vehicle (e.g. its maintenance records) to be kept with the vehicle when it has a new owner.
• Even though all the Fuse picos are currently being hosted on the Kynetx-run instance of KRE, they could be hosted anywhere. Even vehicles in the same fleet could be hosted in different KRE containers if need be. I'm working on a Docker-based KRE install that will make this easier for people who want to self-host.
• Each pico is an independent processing object and run programs independent of other picos, even those of the same type. This means that a given vehicle pico might, for example, run an augmented API or a different set of rules for managing trips.
• Picos have a built-in event bus that allows for multiple rules to easily interact with events from the vehicle. We've put that to great use in creating Fuse by leveraging what can be seen as a microservices architecture.

The Fuse API differs from the Carvoyant API in several significant ways:

• Fuse is fleet-based, meaning that Fuse provides fleet roll-up data not available from the Carvoyant API.
• The Fuse API includes APIs for fuel and maintenance in addition to those for trips. These interact with data from Carvoyant, but aren't available in the Carvoyant API. For example, Fuse enriches trip data from Carvoyant with trip cost data based on fuel purchases.
• Fuse uses Carvoyant and they've been a great partner. But my vision for Fuse is that it ought to allow vehicle data from a variety of devices. I'd love to let people use Automatic devices for example, with Fuse. If you're interested in helping, let me know.

The link to Carvoyant in the Fuse Management Console (OAuth) has provided some angst for people do to the need to create a Fuse (Kynetx) account and then to also create and link-in a Carvoyant account. Indeed this has been the source of 90% of the support issues I deal with. In theory, it's no different than linking you Pocket account to Facebook and Twitter so that you can share things you read with Pocket. In practice it's hard for people to understand with for a few reasons:

• In the Pocket example I cite, people already have a relationship with Twitter and Facebook.
• Not only do they already have a relationship, but they understand what Twitter and Facebook are and why they want them.
• Twitter and Facebook are used in more apps that Pocket, so Pocket is riding a wave of user understanding.
• Pocket is linking to more than one thing and the fan out helps by providing multiple examples.

If Fuse supported more than just Carvoyant devices and you linked in multiple device accounts and if people used Carvoyant with more than one app, this might be clearer. But that's not reality right now, so we live with the model even though it seems somewhat forced.

The same is true of the Fuse (Kynetx) account. For simplicity, I refer to it as a Fuse account and the branding on the account interaction is Fuse, but if you pay attention, you're actually going to Kynetx to create the account. That's because you're really creating a hosting account for your picos on the Kynetx instance of KRE. Fuse itself really has no notion of an account. The Kynetx account is used to associate you with the owner pico that belongs to you, but that's all. Other mechanisms could be used to do that as well. You could run applications other than Fuse in that Kynetx account (and I do).

You're probably saying "this is more complicated than it has to be." And that's true if your goal is just to create a connected-car app like Automatic. My goal has always been a little larger than that: using Fuse as a means to explore how a larger, more owner-controlled Internet of Things experience could be supported. All this, or something similar, is necessary to create an owner-controlled Internet of Things experience.