Home > On-Demand Archives > Talks >

Rust and Medical Device Development

Milica Kostic - Watch Now - EOC 2025 - Duration: 34:42

Rust and Medical Device Development
Milica Kostic

In this talk, I will present how Rust fits into the medical device development process. What are the pros and cons of using Rust in medical device development? How can Rust help with fulfilling rigorous mendatory regulatory requirements? Join me to find out!

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

GlebPlekhotko
Score: 0 | 2 weeks ago | no reply

A nice material, thanks.

I'm using the Rust for my weekend projects and have to say, that this is a very poor choice for the low-level embedded software, you know. :-) At least in the area of the baremetal and, probably, RTOS-supported applications.

The thing is its primary "feature" called the "memory safety" creates too much obstacles when addressing the hardware resources or shared memory locations. There are certain workarounds, like the unsafe regions you mentioned, but they bloat the code. A simple application running at the something like Cortex-M0 will have absolutely no benefits and it will definitely reduce the readability of the code base. And such primitive applications developed by countless vendors somewhere in Asia comprise a significant part of the market by the gross device count.

Moreover, I have a strong feeling that "memory safety" turned into some sort of the marketing motto. Especially if being applicable to the embedded area. Let's address the "Use-after-free" scenario. Again, the majority of the small embedded applications perform only one distinct function. And a well-designed one engages the static allocation only. So there is no room for the dynamic memory, and hence the "use-after-free". Something like uninitialized local variables or pointers definitely remains, and Rust does make them vanish, but again. It is a small device and should be well-tested before going to market. And if not, nothing will save it regardless of what is used to write the software: Rust, C or Ada. It simply crumples.

So I believe that the forced injection of Rust will just fragmentize the development: in the lower end C will prevail, while on the high ground, Rust, supported by Linux or other advanced OSs, will thrive.

Anyway, attempting to create "something the same across all domains", a "swiss knife" for any situation, usually leads to the solution, which does everything equally badly.

Regardless the medical devices, where safety means all, the accelerated transition to Rust may create an isolated environment detached from the rest of the C/C++ world. That may potentially yield problems when hiring and training the personnel, as well as importing some third-party code.

But it is just my humble opinion. Maybe I'm completely wrong and the "Brave New Rust World" is just around the corner. We will see that in the future. :-)

maurizio.brignoli
Score: 0 | 4 weeks ago | 1 reply

Hi Milica, would you please suggest some books or website tutorial to start learn Rust with a strong background of C langue for with microcontroller like STM32 or PIC32? Thank you.

MilicaKosticSpeaker
Score: 0 | 4 weeks ago | no reply

Hi Maurizio,

I would suggest to start with https://doc.rust-lang.org/beta/embedded-book/intro/index.html. Happy learning!

RaulPando
Score: 0 | 2 months ago | 1 reply

Thanks for an insightful presentation Milica. I was wondering based on your professional experience with embedded Rust on microcontrollers whether you tend to resort to async with an executor (not sure if embassy is the defacto) or more of an RTOS + Rust type of solution. In general, I wonder if you had any input on what approaches may be more ergonomic when considering professional Rust embedded development.

MilicaKosticSpeaker
Score: 0 | 2 months ago | no reply

Hi Raul,
good question! It is more natural to use async + Rustm such as embassy (I think embassy is the most mature solution we have at the moment). RTOS + Rust - all I know is that there is a Zephyr basic Rust support (https://docs.zephyrproject.org/latest/develop/languages/rust/index.html), and it is in a very early stage, so I would recommend to start in that direction. Things might change in the future, and I think RTOS + Rust will have it's place, but we are not there yet.

John_Singleton
Score: 0 | 2 months ago | 1 reply

I didn't know that unit tests are a part of Rust's standard library. I guess it's not the only language that has this feature, but having dealt mostly with unit testing in C/C++ for the past year, this sounds really nice. Great talk. Thank you!

MilicaKosticSpeaker
Score: 0 | 2 months ago | no reply

It really does make your life easier... So unit testing, integration testing, coverage reporting, static code analysis, all is there out of the box with cargo :)

datamstr
Score: 0 | 2 months ago | 1 reply

Excellent presentation!

MilicaKosticSpeaker
Score: 0 | 2 months ago | no reply

Thank you! I hope you find it useful!

OUR SPONSORS & PARTNERS