Hacker News Reader

Comment by molteanu | Hacker News Reader

Well, software developers in the embedded field of automotive use Matlab and Simulink quite extensively. I haven't worked with it myself but the "excuse" for using it was that "we have complicated state machines that would be difficult to write directly in C".

View on HN

You would think about a lot of the things that they do, "how hard can it be?". Take a look at the simplified example statechart here (scroll down) for a power window control and ponder all the ways an embedded programmer could struggle to get the behavior right in plain procedural C code as well as how difficult it would be to get a typical team to document their design intent.

https://www.mathworks.com/help/simulink/ug/power-window-exam...

Where statechart design is appropriate, it is a very powerful tool.

Those do strike me as elucidating the power in suitable contexts very nicely.

For those following along at home, click https://uk.mathworks.com/help/simulink/ug/powerwindow_02.png first and then realise that's a top level chart with per-case sub charts (and then follow buescher's link if you want to see those) ... and that at the very least this is probably the Correct approach to developing and documenting a design for something like that.

Thank you kindly for the Informative Example.

You're welcome, and yeah, that is the statechart. It's actually at the low zoomed-in level. That's the controller at the heart of the example. A lot of the diagrams in the article are higher-level, not sub-charts. I am not a 100% advocate for the BDUF-flavored model-driven-design approach in the whole document at that link, though I can understand why some industries would take it.

Remember, too, this is undoubtedly a simplified example. Just off the cuff I'd expect a real-world window motor controller in 2024 to have at least open-loop ramp-up and ramp-down in speed, if not closed-loop speed control. I also would expect there'd be more to their safety requirements.

> A lot of the diagrams in the article are higher-level, not sub-charts.

I must have failed to understand even more things than I thought I did. I'll have to read through again when more awake if I want to fix that, I suspect.

I think if faced with that class of problem (am not automative developer, just spitballing) I would probably try using some sort of (no, not YAML) config format to express the various things.

But that's a 'how my brain works' and I am aware of that - for database designs, I've both ensured there was a reasonable diagram generated when the point of truth was a .sql file, and happily accepted an ERD as the point of truth once I figured out how to get a .sql file out of it to review myself.

I haven't worked in automotive. And I'm not a strong advocate of exhaustive model-driven design like what's shown at that link. But it's worth looking at.

Generally if you have a state machine or state chart with more than a few states, it's worth implementing as a table. The "config format" is then an array in a source file. There is a standard interchange format, scxml, for statechart tooling and libraries, but if you're implementing your state machine directly from a whiteboard drawing, you might not bother with it.

What they didn't tell you is that these state-machines are differential equations as well. Again, the math is more important than the code. If you want to look more into it, just search for state variable control.

Matlab also solves a ton of common engineering problems with efficient BLAS wrappers. And it is (or at least used to be) pretty trivial to drop in a CUDA kernel for hotter code paths.

It's still great for simulation work imo.

Reply on news.ycombinator.com