Architecture & GPS hardware

Hello jhrjdata 

Welcome to this Fabric community forum.

There are many vendors providing quality GPS trackers. TCP based protocols (like MQTT) are preferred. This provides fast, secure, and reliable communication.  

Reading data from the ODB2 connector is nice for customers when they need to connect the device themselves. But probably this offers a subset of the canbus data needed and it's not temper proof. Connecting a device directly to the canbus (or multiple canbusses) is more work but makes it possible to 'hide' the tracker. There are way to read canbus data non-intrusive (no need to cut wires or void warrenty)

I have tested the Teltonika FMC150 (which uses the same configurator tool. Please check the specs yourself). The message interval can be controlled and support a wide range of vehicles, probably the same as the tracker you mentioned. It has several ways to connect to the cloud, including to the Azure IoT hub over MQTT.

This means that no 3rd party cloud gateway is needed and the Microsoft Fabric eventstream can connect directly to the Azure IoT Hub source. Optionally, an Azure Eventhub can be put in between providing the ability to pause the egress, a practical feature while doing maintenance.

You are doing IoT and Real-Time communication so yes, using the Eventstream and Eventhouse are the right tool. Together with the real-time dashboards and Fabric Maps, you get insights directly. KQL databases are perfect for storing data over years. The storage is automatically compressed making the storage cheap in an automated way. Still, years of data, giga bytes, terra bytes or more, can be queried within seconds. One eventhouse can hold multiple KQL databases.   

You want to support multiple customers. This brings the question, how can we prevent customers from seeing eachother data? The recommended way for our customers is to ingest the raw messages as one stream but splitting up the messages over multiple customer KQL databases, one for every customer. This makes it easy to manages access rights with EntraID or external tooling (for example, I Azure Managed Grafana, a connection is created on database level).

An alternative is splitting the stream (eg via IoT Hub routing) or working with multiple customer tables in the database or using row-level security. This is possible but this makes it a bit more complex in our opnion.  

Be aware that the stream must be able to split the customer specific messages. So you need to have enriched the messages with an customer id somether upstream (Perhaps in the device or via and extra, stream analytics job, or Azure Function). Check out the Eventstream SQL transformation and filter transformation if you want to add splitting logic in the Eventstream. Notice that the Eventstream only understands the message body, at this moment message application properties (as seen in the IoT Hub message enrichment) is not supported.

Geofencing, we have you covered. The device I tested could do geofencing too but why not use the KQL database geofencing functions as seen in this blog post? Just combine it with the Activator and you can do some nice geofencing.

Regarding the SKU, that's not easy to answer. Because Fabric items like the Eventstream and Eventhouse run day and night, adding value 24/7, this you need a solid capacity, or better, two capacities. Use one for ingestion and data storage and the other for user interaction. I recommend spinnig up a few capacities (a bit larger than expected) and start meassuring. Why a bit larger? You pay a bit more for a few weeks but then you can measure without overages or throttling. You can try to calculate Eventstream usage upfront here. 

Recently, I gave presentation about IoT location based data, maps and geofencing here. 

--

If this answer helps you, a thumbs-up or marking it as accepted answer is appreaciated. All community members with similar questions will benefit by doing so. Your contribution is highly appreciated.

Hello jhrjdata 

Thank you for your kind words.

Regarding the device being connected to the IoT Hub, if you can execute this IoT Hub integration, you are fine. You will see device messages arrive, at least GPS data if there is a fix. At this moment, it's using SAS tokens of the IoT Hub service. I'm in contact with Teltonika to discuss device keys.

Row-level security vs multiple databases, this choice is based on either flexibility and the customer choice to have their data being stored (at rest) separate from other customers. 

So, this is a viable option:

GPS (FMC920) → Azure IoT Hub (MQTT) → [Optional: Event Hub] → Eventstream → Eventhouse (1 KQL DB per customer)

The maximum number of KQL databases per Eventhouse is 10.000. Splitting the messages is done in the Eventstream over the databases. There seems no limit to the number of eventhouse destinations.

Regarding enrichment, I would add the customer identification at the IoT Hub, as an entry in the device tags and enrich each message with it. If you choose for row-based-access-control, you could postpone it and do this in the database flow.

Regarding the calculation, you can do the math yourself. But be aware that both Eventstream, Eventhouse, Activator, etc. need services running at the background so these pick a part of your capacity by default. I suggest, go for an F8, test for a few weeks, measure, and see how much consumption there is. Do not start too small, then you will encounter throthling and overages which slows down you development phase. You can then scale down if needed. Bonus tip: put Eventstream and Eventhouse in a separate capacity so this one is not affected by noisy neighbours.

Regarding the geofencing, we go for the activator on top of Eventhouse approach. This is not a full streaming solution but it can be executed every few minutes and that is ok for our usecase. An alternative flow is filling a table with geofencing outcomes (via medallion architecture) and use Eventhouse/ADX CDC for a second Eventstream. Depending on the value, this extra architecture can be valuable.

In the end, you're still flexible in your architecture so do a few experiment and learn what fits best for you.

--

Please mark this answer as accepted answer if it helps you. All community members with similar questions will benefit by doing so. Your contribution is highly appreciated.

jhrjdata ,

I double-checked the Eventstream for app settings support. Only system properties are supported.

So, moving application properties (added via IoT Hub message enrichment) to the body must be done before the message arrives at the Eventstream. This is possible via eg. Azure Stream Analytics or Azure functions.

As an alternative, row based access control is still an option.