8 ms·

Launch HN: Synnax (YC S24) – Unified hardware control and sensor data streaming

38 points by embonilla 2y ago

Hi Hacker News! We’re Emiliano, Elham, and Patrick, co-founders of Synnax (https://www.synnaxlabs.com https://www.synnaxlabs.com). With Synnax, engineers connect to their sensors and actuators, stream telemetry for control and post-processing, and query historical data for analysis. Hardware teams use our platform in areas ranging from firing rocket engines to operating manufacturing lines. Here’s a video: https://youtu.be/OJtVBfRwooA https://youtu.be/OJtVBfRwooA. Software developers on hardware teams don’t usually have infrastructure to build their custom software on. They have to work with dozens of data acquisition devices to get data into a single database. Oftentimes, they have to use several different solutions to communicate with different devices: LabVIEW for National Instruments hardware, ROS for robotics, and SCADA software for PLCs. There’s no good “glue” that lets you coordinate all of these devices together. Developers end up using tools like Apache Kafka for streaming and InfluxDB for storage, but these tools are hard to get working with hardware, plus it’s a pain to configure these tools to also record and stream data whenever commands are sent to control hardware. This forces developers to repeatedly build adapters to get data off hardware devices and manage separate systems for real-time streaming, data storage, and hardware control. I (Emiliano) discovered this problem while working as a test engineer at an aerospace company. We used old control software that spit out data in massive 10 GB CSV or TDMS files. After a long day and night of testing, no one wanted to go through all the work to review the data. One day, I was operating the system, and a very expensive component failed, causing a multi-million dollar test stand to explode. After many days of data review, we found a small anomaly that indicated a component defect. I then got fascinated by this problem, and moved into a software engineering role to improve their data pipeline. After I left this job and went back to school, I spent most of my time skipping classes to build Synnax, eventually meeting Patrick and Elham. Synnax has several main parts. We have a custom time series-database that was designed to be horizontally scalable and fault-tolerant. The database can deploy in an OS or in a container. Every sensor and actuator can fit into a “channel” that can be written to using our client libraries in C++, Python, and TypeScript. When writing to a channel the server both persists it to the database and streams it for real-time consumption for any type of service, such as a GUI, automated post-processing tools, and supervisory control sequences. Finally, we’ve built a React component library that simplifies the process of making a GUI, a visualization and control desktop application, and pre-built device integrations for National Instruments hardware and PLCs via OPC UA. We think Synnax is unique in that it provides a bridge between existing solutions like ROS, LabVIEW, and SCADA software and general purpose tools like Apache Kafka or InfluxDB. Synnax is source-available on a BSL 1.1 license (GitHub: https://github.com/synnaxlabs/synnax https://github.com/synnaxlabs/synnax, documentation: https://docs.synnaxlabs.com https://docs.synnaxlabs.com). Usage of the software is free for up to 50 channels. We aren’t yet sure on what pricing to settle on—we’ve talked about doing only usage-based implementation or also adding an implementation cost. If this sounds interesting to you, please check us out! You can follow through on our documentation website (https://docs.synnaxlabs.com https://docs.synnaxlabs.com) to deploy a database and download the desktop visualization dashboard. We’d really love to hear your feedback and look forward to all of the comments!

candiddevmike 2y ago
This is really neat, I know a lot of folks in manufacturing QA that would love something like this. The telemetry aspect of industrial equipment is terrible IMO, so many folks are hand rolling sensors and triggers and then trying to duct tape an extremely fragile monitoring and dashboard system using something like graphite. Neat space to be in! How are you going to interface with the big boys like rockwell? I see you have drivers, what about partnerships? I know a lot of companies tend to only work with toolsets their provider "blesses", so having them on "your team" can help. You may have to pick favorites to win early deals/"synergy" (and may help with acquisition?) I've worked with industrial automation in the past and have always enjoyed the technical constraints within it. I would be interested in helping you with pre or post-sales support/training/implementation for your customers if you need it. Email is in my profile.
- embonilla 2y ago
  It's been a really interesting problem to tackle - we've seen so many different ways that companies try to tackle this problem, and while theres one or two companies that have made really fantastic internal tools, most are ... lacking, to say the least. Our plan so far has been to try to interface with the bigger companies through the drivers we make for their hardware. We haven't reached out about partnerships yet, but that is a really good idea. Thank you for the offer - will definitely reach out if and when we need more help on the implementation side.
kpmcc 2y ago
Hey! I work at a startup that does industrial automation related work and this looks super helpful. Going to take a deeper look later, but off the bat I wanted to ask why you felt a custom time series database was warranted when there are options like timescale or regular old postgres out there?
- elham 2y ago
  Hey! Great question we get a lot. We've come from/talked to a lot of companies that do what you described with stuff like timescale and influxdb. They're useful tools and support a breadth of applications. We thought by building one to specifically leverage the read/write patterns you'd expect with sensor-heavy systems, we could achieve better data throughput and thus better enable real-time applications. For example, we've been able to get 5x write performance for sensor data on our DB compared to influxDB. In general, having built out the core DB, it has been valuable in allowing us to expand to the other useful features such as being able to write commands out to hardware at sufficient control loop frequencies or create smooth real-time visualizations. The other thing we think is really powerful is having a more integrated tool for acquiring, storing, and processing sensor data & actuating hardware. One common issue we experienced was trying to cobble together several tools that weren't fully compatible - creating a lot of friction in the overall control and acquisition workflow. We want to provide a platform to create a more cohesive but extensible system and the data storage aspect was a good base to build that off of.

38 points by embonilla 2y ago

candiddevmike 2y ago

This is really neat, I know a lot of folks in manufacturing QA that would love something like this. The telemetry aspect of industrial equipment is terrible IMO, so many folks are hand rolling sensors and triggers and then trying to duct tape an extremely fragile monitoring and dashboard system using something like graphite. Neat space to be in! How are you going to interface with the big boys like rockwell? I see you have drivers, what about partnerships? I know a lot of companies tend to only work with toolsets their provider "blesses", so having them on "your team" can help. You may have to pick favorites to win early deals/"synergy" (and may help with acquisition?) I've worked with industrial automation in the past and have always enjoyed the technical constraints within it. I would be interested in helping you with pre or post-sales support/training/implementation for your customers if you need it. Email is in my profile.

embonilla 2y ago
It's been a really interesting problem to tackle - we've seen so many different ways that companies try to tackle this problem, and while theres one or two companies that have made really fantastic internal tools, most are ... lacking, to say the least. Our plan so far has been to try to interface with the bigger companies through the drivers we make for their hardware. We haven't reached out about partnerships yet, but that is a really good idea. Thank you for the offer - will definitely reach out if and when we need more help on the implementation side.

kpmcc 2y ago

Hey! I work at a startup that does industrial automation related work and this looks super helpful. Going to take a deeper look later, but off the bat I wanted to ask why you felt a custom time series database was warranted when there are options like timescale or regular old postgres out there?

elham 2y ago
Hey! Great question we get a lot. We've come from/talked to a lot of companies that do what you described with stuff like timescale and influxdb. They're useful tools and support a breadth of applications. We thought by building one to specifically leverage the read/write patterns you'd expect with sensor-heavy systems, we could achieve better data throughput and thus better enable real-time applications. For example, we've been able to get 5x write performance for sensor data on our DB compared to influxDB. In general, having built out the core DB, it has been valuable in allowing us to expand to the other useful features such as being able to write commands out to hardware at sufficient control loop frequencies or create smooth real-time visualizations. The other thing we think is really powerful is having a more integrated tool for acquiring, storing, and processing sensor data & actuating hardware. One common issue we experienced was trying to cobble together several tools that weren't fully compatible - creating a lot of friction in the overall control and acquisition workflow. We want to provide a platform to create a more cohesive but extensible system and the data storage aspect was a good base to build that off of.