About 12 weeks ago, I jumped into the world of connected vehicle insights and analytics for my summer internship at Motorq, a leading player in the field.

As a person without any technical background, a good chunk of my summer was spent understanding what Motorq does and how we make things happen. This was not only to excel at my internship, but also to answer questions I frequently receive from my friends and family, such as “Where do you work?” and “Cool! What does Motorq do?” In this blog post, I will try to answer these questions at a grade school drawing level.

If a Motorq-engineer-level explanation is like Vermeer's View of Delft (left), then my explanation will be like AI's attempt to replicate it (on the right)

Recap: But what does Motorq actually do?

In fact, there is already a blog post published awhile ago by Ethan Alter, our VP of Product Marketing (and my boss), on what Motorq is. We connect our customers to the data inside their vehicles and turn vehicle data into insights that matter. But how? Let’s first talk about why there is a company like Motorq.

The market demands it — businesses want to know more about their fleets

I’ve learned there is a huge value space in the automotive industry: businesses want to know certain things about their vehicles. To name a few, they want to know where their cars are, how to best maintain their cars at the right time, and how to deploy them most advantageously. Of course, they could ask employees or physically check themselves, but this would be very time-consuming. Luckily for them, modern cars can talk: “Hey, I need you to look at my rear tires because the pressure is not normal. It will become a bigger problem if you don’t look at it now.” Unfortunately, humans do not speak car language. This is where Motorq comes in: as a translator that lets businesses listen to what their vehicles are saying!

How connected cars generate data & how Motorq accesses it

Cars? Data? Aren’t cars just a means of transportation to get us from point A to B? What kind of “data” do cars generate? This analogy from Ethan’s blog post was helpful for my understanding: modern vehicles are like computers on wheels.

When you have a computer, in this case a car, there are two ways to access the data: hardware and software:

1. Hardware - you plug a device into a port and get the data from the device
2. Software – you access via a wireless connection, device-free

In case you hadn't already guessed, the software model is the Motorq model. When a customer comes to us to enroll their vehicle, we work with the OEMs (a.k.a. automakers — yes, the car brands you see on road or their parent companies) to verify ownership, obtain affirmative consent for specific use cases, and get the insights flowing as quickly as possible (much faster than via the hardware option).

Motorq normalizes disparate data into a single output "language"

The thing is there is no industry standard for automotive data. It is almost like each OEM data are written in different languages.

I talked to Robert Yu, one of our Product Managers, to understand how this works on a deeper level.

Robert also specified that data is usually passed through streaming, which we will talk later in this post. I asked him to show me a raw snippet of an example raw data we get from OEMs.

{
"key": "ChargeState",
"value": {
"stringValue": "Idle"
}
}

And this is after Motorq’s normalization:

"evChargingState": {
"timestamp": "2015-04-12T17:44:11.821Z",
"value": "charging"
}
}
],

You'll notice the slightly different compositions, but you might also have recognized that the word ChargeState in the OEM raw data changed to evChargingState in Motorq schema. At Motorq, there is a set of logic, like dictionaries, for OEM languages to translate into Motorq language.

Our customers, no matter how many makes and models they have in their fleet, only have to speak one: the Motorq language.

How do we create actionable insights?

Ok, now we know how Motorq takes OEM data as input and translates it into a single language as output. Now for the next step: how does Motorq make actionable insights from the data? Let me explain how it works by introducing three different levels of vehicle info that Motorq provides.

Lvl. 1: Telemetry — When you think of "telemetry," think of point-in-time status. Things like odometer, current speed, fuel level — the closest to the raw signals from the vehicles. If you can see it on the dashboard, it’s likely a telemetry signal.

Lvl. 2: Insights — These are insights generated by syndicating multiple signals. Trips and events (speeding, collision, etc.) are examples. The cars do not tell us there was a Trip. Motorq models interpret the telemetry to identify and create Trips (e.g. engine start location, stop location, speed, time, etc.)

Lvl. 3: Metrics. Metrics are built on top of telemetry and events. They are designed to collapse a ton of data into a single human-interpretable number (or a few). One example is the Motorq Driver Behavior Score. Telemetry and events are interpreted to generate a single score out of 100 that can identify a fleet’s best and riskiest drivers.

Our app, or the customer's app: how insights get delivered

Ok. Now we have a normalized data and actionable insights. From day 1 of my internship, I was curious how the customers get the insights. There are three musketeers of technical interfaces: a data stream via Kafka, the Motorq API, and a queryable database. On top of that, for people who want the insights in beautiful ready-to-use application, Motorq has built a Fleet Management Portal.

Wait, streaming, API, what?

Streaming Interface

For those who are new to the world of SaaS data, like myself 12 weeks ago, Kafka is an open-source distributed event streaming platform. In less technical terms, in Kafka, the data is streaming constantly (as opposed requesting specific data via API; more on that later). It constantly feeds the customer data, like a mountain stream feeding a river. Typically, a customer would be ingesting this data into one of their own applications.

Motorq API

The Motorq API is a technical interface that can act as a “middle man” between a customer's application and Motorq insights. It is like that one friend at a bar who takes all the order (request) from the group and put in the order to the server (both at a bar and in SaaS, it is server :D). That means the customers can put in their order (request) of any insight to Motorq’s API and the API get the insight they need from the server. For example, if a rental company wanted to get the odometer reading from the vehicle once a lease ends, they could make an API call to Motorq that’s triggered by changing lease status in their system.

Queryable database through Snowflake

Customers often want to do their own analysis on the breadth of data coming from their vehicles. To meet that need, Motorq provides the historical data in a relational database via Snowflake. This is useful when the customer wants to know a historical trend of data e.g. what is the average EV charging reimbursement cost for the last month and how does it compare to this month? SQL is the most common language used to write queries against structured data.

Motorq Fleet Management Portal

Let’s say your business just needs an easy-to-use off-the-shelf application to surface the insights that really matter. Good news! Motorq built the Motorq Fleet Management Portal just for you. You can find more information on our portal here.

EV charging metrics from the Motorq Fleet Management Portal

Phew! That was a lot to cover. Hope this was useful to understand how Motorq works.

Still hungry for more? ⬇️