It’s Jan from spotflow.io. We're trying to solve the problem of monitoring and troubleshooting embedded devices. Our goal is to build a platform for collecting and analyzing telemetry from such devices (kind of like Datadog, but for embedded systems).
We're a group of nine, mostly engineers, with cloud and IoT experience. In the past, we've built an IoT platform and implemented many solutions on top of it. When working on IoT projects, we’ve often heard people in embedded engineering talk about the difficulties of troubleshooting embedded devices. It started to repeat.
We decided to give it a closer look. We had 20+ conversations with embedded engineers about device monitoring and troubleshooting and learned about the engineering of physical devices for tracking position, gaming, audio management, medical aesthetics, and more. We discussed approaches and tools engineers use to monitor and troubleshoot devices in the field.
We heard a lot about pitfalls, obstacles, and cumbersome approaches that embedded teams must overcome every day.
One story that comes to my mind is about downloading logs from multiple machine components to a laptop, opening them in a text editor, and trying to correlate the logs from modules based on the timestamp.
Another story is about a machine manufacturer always asking their customers to create a VPN to access the machine and fix it.
Some customers are used to sending the devices back to the manufacturer to debug and fix the software, even though those devices are connected and could be monitored and fixed remotely.
And I can go on, but the examples kind of illustrate the current state.
We took the findings and created a list of pain points. There are some that we’ve been hearing very often:
- Logs are scattered across many devices and can’t be accessed without visiting the device. - It’s difficult and takes too long to search through log data, leading to increased issue resolution time. - Custom-made or legacy systems for logging do not work well and require a lot of maintenance. - As the number of devices grows, handling larger volumes of log data reliably and securely becomes increasingly difficult.
We would like to resolve the pains with a new platform for embedded observability. We decided to focus on ZephyrOS first and add support for more operating systems later. Narrowing the product makes it easier for us to interact with the audience and develop the first version.
There are many platforms for app observability on the market and just a few for embedded. App observability platforms, by their nature, have different focus, and they don’t, for example, solve the challenge of running a log collector on constrained embedded devices. There are some embedded observability platforms, but we believe that we can build a product that is easier to use and cheaper.
I would like to hear your thoughts on our plan and the offering we described on the website!
It’s Jan from spotflow.io. We're trying to solve the problem of monitoring and troubleshooting embedded devices. Our goal is to build a platform for collecting and analyzing telemetry from such devices (kind of like Datadog, but for embedded systems).
We're a group of nine, mostly engineers, with cloud and IoT experience. In the past, we've built an IoT platform and implemented many solutions on top of it. When working on IoT projects, we’ve often heard people in embedded engineering talk about the difficulties of troubleshooting embedded devices. It started to repeat.
We decided to give it a closer look. We had 20+ conversations with embedded engineers about device monitoring and troubleshooting and learned about the engineering of physical devices for tracking position, gaming, audio management, medical aesthetics, and more. We discussed approaches and tools engineers use to monitor and troubleshoot devices in the field.
We heard a lot about pitfalls, obstacles, and cumbersome approaches that embedded teams must overcome every day.
One story that comes to my mind is about downloading logs from multiple machine components to a laptop, opening them in a text editor, and trying to correlate the logs from modules based on the timestamp.
Another story is about a machine manufacturer always asking their customers to create a VPN to access the machine and fix it.
Some customers are used to sending the devices back to the manufacturer to debug and fix the software, even though those devices are connected and could be monitored and fixed remotely.
And I can go on, but the examples kind of illustrate the current state.
We took the findings and created a list of pain points. There are some that we’ve been hearing very often:
- Logs are scattered across many devices and can’t be accessed without visiting the device.
- It’s difficult and takes too long to search through log data, leading to increased issue resolution time.
- Custom-made or legacy systems for logging do not work well and require a lot of maintenance.
- As the number of devices grows, handling larger volumes of log data reliably and securely becomes increasingly difficult.
We would like to resolve the pains with a new platform for embedded observability. We decided to focus on ZephyrOS first and add support for more operating systems later. Narrowing the product makes it easier for us to interact with the audience and develop the first version.
There are many platforms for app observability on the market and just a few for embedded. App observability platforms, by their nature, have different focus, and they don’t, for example, solve the challenge of running a log collector on constrained embedded devices. There are some embedded observability platforms, but we believe that we can build a product that is easier to use and cheaper.
I would like to hear your thoughts on our plan and the offering we described on the website:
https://spotflow.io/
It’s Jan from spotflow.io. We're trying to solve the problem of monitoring and troubleshooting embedded devices. Our goal is to build a platform for collecting and analyzing telemetry from such devices (kind of like Datadog, but for embedded systems).
We're a group of nine, mostly engineers, with cloud and IoT experience. In the past, we've built an IoT platform and implemented many solutions on top of it. When working on IoT projects, we’ve often heard people in embedded engineering talk about the difficulties of troubleshooting embedded devices. It started to repeat.
We decided to give it a closer look. We had 20+ conversations with embedded engineers about device monitoring and troubleshooting and learned about the engineering of physical devices for tracking position, gaming, audio management, medical aesthetics, and more. We discussed approaches and tools engineers use to monitor and troubleshoot devices in the field.
We heard a lot about pitfalls, obstacles, and cumbersome approaches that embedded teams must overcome every day.
One story that comes to my mind is about downloading logs from multiple machine components to a laptop, opening them in a text editor, and trying to correlate the logs from modules based on the timestamp.
Another story is about a machine manufacturer always asking their customers to create a VPN to access the machine and fix it.
Some customers are used to sending the devices back to the manufacturer to debug and fix the software, even though those devices are connected and could be monitored and fixed remotely.
And I can go on, but the examples kind of illustrate the current state.
We took the findings and created a list of pain points. There are some that we’ve been hearing very often:
- Logs are scattered across many devices and can’t be accessed without visiting the device. - It’s difficult and takes too long to search through log data, leading to increased issue resolution time. - Custom-made or legacy systems for logging do not work well and require a lot of maintenance. - As the number of devices grows, handling larger volumes of log data reliably and securely becomes increasingly difficult.
We would like to resolve the pains with a new platform for embedded observability. We decided to focus on ZephyrOS first and add support for more operating systems later. Narrowing the product makes it easier for us to interact with the audience and develop the first version.
There are many platforms for app observability on the market and just a few for embedded. App observability platforms, by their nature, have different focus, and they don’t, for example, solve the challenge of running a log collector on constrained embedded devices. There are some embedded observability platforms, but we believe that we can build a product that is easier to use and cheaper.
I would like to hear your thoughts on our plan and the offering we described on the website!
reply