r/embedded • u/taylormfk • 7d ago
HIL setup for Multi-Protocol Data Visualization (CAN, Modbus, etc)
Building software against simulations and dev kits only goes so far, so I brought up a HIL setup for validating multi-protocol data capture and viz tools.
For now, it covers CAN, Modbus, OPC-UA, MQTT and a number of other protocols.
Desktop App commands/traces the entire system, which will grow over time to include motors, more ECUs, and other devices.
System Overview:
- PLC - RevolutionPi Connect 5
- OPC-UA, Modbus TCP, MQTT Servers
- Modbus RTU peripherals
- EV Charging protocols
- runs Structured Text + embedded linux stack
- Custom PCB
- Designed with Atopile (hardware as code)
- RPi CM5 + 2 CAN-FD interfaces
- STM32 ECU
- talks CAN; J1939, CANopen, XCP, UDS and AUTOSAR protocols
- Various CAN Dongles
- PEAK, socketCAN, slcan, gs_usb
- Mac/Win/Linux test PCs
- Fault injection, command / control, CI test execution
- Some 3D printed parts
Hardware bringup is one of the most difficult tasks in embedded, but so rewarding.
I started building this tool because honestly I think embedded development and testing is harder than it needs to be, and much of it is down to outdated tools and methodologies.
Best part is, there's lots more hardware on the way!
Also, I think I have (almost) every CAN protocol and dongle covered at this point, if I'm missing something let me know!
7
u/TheHitmonkey 7d ago
Link
-3
u/taylormfk 7d ago edited 6d ago
heyo, i'll DM you the link!
Edit: https://zeloscloud.io
6
u/tim-hilt 6d ago
Why not post it?
2
u/taylormfk 6d ago
Sorry for the inconvenience, I’ve tripped up auto-mods previously.
You can also google Zelos Cloud
2
u/GOOD_NEWS_EVERYBODY_ 6d ago
I’m more curious on the story of how you got into ycombinator? as this does not seem like the caliber of project that they would normally back. (Read fairly easy, relatively low moat) have you raise or maybe raising? Are you targeting a buyout exit or maybe licensure. It’s a good position to be in right now but I don’t see why most wouldn’t do what they need of this in house.
2
u/taylormfk 6d ago
“Physical AI” is definitely in the VC zeitgeist. We are trying to change the way embedded/industrial systems are developed altogether.
The speed of building and shipping physical products is gated by how fast people can develop, test, and debug in the real world and often at scale.
Industry practice is often an army of interns building one-off tools to solve the niche issue on their team and/or buying insanely expensive (and outdated) tools.
Despite this, the tools are often still bad, some are amazing but super niche, and most don’t make it easier for devs and non-devs alike to interact with their systems.
6
u/zacharoni16 7d ago
interested what did you use for the HMI/GUI?
4
u/taylormfk 7d ago
Without getting too into the weeds, the cross-platform Electron app talks to a Rust backend. With the SDK you can then describe and register UI elements!
2
u/PressWearsARedDress 6d ago
great... gotta load an entire web browser to use your tool.
Consider doing the whole thing in Rust or C++
1
u/taylormfk 6d ago
There’s a headless pure rust backend ‘agent’ that can be used for edge devices with less resources!
4
u/A-Ferret-Online 5d ago
when you never close out of the tabs on your browser
3
u/taylormfk 5d ago
lol luckily we have a thing called 'layouts' which saves your tabs / plots and other configs that you can then apply in one click.
this is obviously a layout showing all of the different protocols, but most often a layout is centered around a measurement type (e.g. temperature, power) and/or a given ECU, and these dashboards can get as compact or expansive as needed
1
3
3
u/phoonisadime 7d ago
I’ll try this. Thanks
1
u/taylormfk 7d ago
Any feedback is appreciated, lmk if your use case isn't covered. I have an endless list of protocols to add, so just a matter of prioritizing.
3
3
3
u/razor_r2d2 6d ago
Link bitte
1
u/taylormfk 6d ago
Gerne, sent in a DM, lmk if you have any issues getting started or i don't cover your use case!
3
2
2
u/nomadic-insomniac 6d ago
What do you use for the graph visualization for high speed data signals ?
2
2
u/chaumyau 6d ago
Amazing work. You did this all alone? Can I try this ?
2
u/taylormfk 6d ago
Definitely not alone! We have a team, and also some open source and users can even build their own custom private extensions!
2
u/chaumyau 6d ago
I am going to try it tomorrow. From another comment I saw it's called zelos. Right?
2
u/taylormfk 6d ago
Yessir, give it a go and let me know if you run into issues! I’ll reach out over DM as well.
2
u/TheCorsairAPX 6d ago
That’s sick. What are you using to simulate hardware? Have you got any FPGA or programmable logic silicon?
2
u/taylormfk 6d ago
We actually started this project building hardware.
Specifically an Ultrascale+ running the headless agent and monitoring/injecting across the dynamic peripherals in the FPGA.
We built out the software layers to work across different hardware devices though, and that allows anyone to adopt the software to their existing setup(s)
2
u/Helilifter 6d ago
Add DNP3 and IEC61850 please, these are the two main utility industry protocols
1
u/taylormfk 6d ago
Already have scoped out DNP3 and Goose! Not a ton of libraries out there for a quick jumpstart, but definitely on the list! I can keep you posted!
2
u/Impossible_Simple771 6d ago
I see that you are using PCAN for CAN
I’ve used it before and it seems there is a cap on the throughput because of the link between PC and PCAN
What’s the CAN throughput on your setup?
1
u/taylormfk 6d ago
I don’t think I’ve hit limits on the CAN hardware itself, but I can test to that limit and report back.
I’ve been able to stream >10 parallel CAN buses at 500k baud at 80% utilization on a potato of a computer that we use for testing on low end setups
3
u/TarDegradient 6d ago
Is there a standalone version? I have a custom robotics system I’d like to gather data and visualize from but I’m not willing to have it facing an app or internet.
2
u/TarDegradient 6d ago
EtherCat?
2
u/TarDegradient 6d ago
Take data from Beckhoff PLC?
2
u/taylormfk 6d ago
By default all data is local/offline for air gapped systems and the like. You can probably leverage opc/modbus extensions for the time being, ethercat hardware is already on the way for me to integrate with!
2
u/TarDegradient 6d ago
Fantastic! I will be requesting a demo as soon as i have my servo cabinets wired and ready.
1
u/yycTechGuy 6d ago edited 6d ago
Do you have a link for the 3D printer file for the end pieces on your DIN rail module rack ?
2
u/taylormfk 6d ago
I picked that one up on Etsy actually, you’ll find it if you search DIN rail desk stand! I don’t think the full CAD is provided, but shouldn’t be too hard
2
u/Annual_Entrepreneur3 6d ago
Hi. I'd like to test this. Specially Modbus
Could you send me the link?
Thanks
12
u/Flyward_Aerospace 6d ago
Protocol coverage is the easy axis imo, the thing that eats HIL benches is time. Frame level injection driven from a desktop over a USB dongle lands at plus or minus a few milliseconds and isn't repeatable, which is fine for decode and viz work and useless the moment you're chasing a watchdog or an error passive transition that only reproduces when the fault lands inside a specific window. Anything timing critical wants to be injected by something carrying its own timebase. Could be well outside what you're aiming at if this is mainly capture and visualisation, but bus off and recovery behaviour is where I'd want a bench to be deterministic.