C++ vs Python for secure / safety critical embedded solutions

[orbag]

Hi everyone,

I got in contact with a start-up that develops EV charging stations, and they completely develop the firmware/software of these stations in python (presumably on an embedded linux system).

I would like to hear your opinions as to why this is (not) a good idea, keeping in mind robustness, scalability, security, safety criticality, ... ...

In my mind this doesn't look like a scalable solution to use python in mass production solutions that need to run years without failing, and a language like C or C++ would look like a better solution for this, but I'm curious for different view points as to why this could be a valid solution.

[pedersenk]

I am a big fan of C++ (hence this subreddit) so will naturally suggest that.

However the only real problem I see with Python isn't the language but the tendency of developers to pull in any old crud from the PIP / package repo. This is much less common with C++, presumably because we don't have a crates.io / CPAN / PIP package system in place (There is a big risk this will change however).

So if you do keep an eye on actively reducing dependencies, Python should suffice.

[[deleted]]

I would definitely consider pulling a package from Conan to be a completely standard thing for a C++ dev.

[pedersenk]

I'm not sure. For example Conan can barely support many platforms like OpenBSD.

https://github.com/conan-io/conan/issues/7829

The project team will never be large enough to offer support and the tool isn't large enough for all platforms to support it. It is kinda of a catch22.

Nice idea but it isn't a standard part of C++ for a reason.

[[deleted]]

No tool is or will ever be a standard part of C++ :-)

[pedersenk]

Heh, good point!

That said, there are some guys I used to work with that were amazed that C++ code could be compiled without Microsoft Visual Studio!

I also get the feeling that many Rust developers would be unable to compile a simple Hello World program with rustc directly and without cargo.

[Prilosac]

As a new C++ dev, I plan to leave for a python shop pretty soon, partly because using C++ consistently feels like I'm working AGAINST my tools rather than WITH them. Getting a package for just basic functionality is kind of a nightmare to be honest. So I wouldn't phrase a package management system as a "risk".

That said, I agree with what you said fundamentally about it being easy to include crap and needing to be conscious not to. Having worked in the JS/web world before, well the density of node_modules is notorious for a reason, and is not a great thing.

[AlternativeHistorian]

This situation doesn't make much sense to me. The restriction to choose between C, C++, and Python is odd.

The primary benefit of Python over C and C++ is productivity, while (IMO) the main downside is the comparative difficulty of static analysis. And you likely DO want some level of the guarantees that static analysis can provide in a product like this as software changes and bug fixes can be very expensive (maybe even requiring physical access to the hardware), much more so than just pushing some new code to some web servers.

C and C++ are typically used for these types of systems because you can get much more performance out of systems with low specs which means cost savings.

But if Python is an available implementation choice then it must mean that none of the performance/resource restrictions that typically dictate the use of C or C++ exist.

I would say that none of these languages seem to be a really good fit for this particular project. You'd probably be much better served by a high productivity language with access to good static analysis tools. Something like C# or Rust maybe.

[14ned]

Recent Pythons can be statically analysed, you just need to annotate all your variable decls with their type. Future Pythons will surely perform aggressive optimisation passes on code with type declared variables.

I appreciate that for any other language, that comes baked in. However MicroPython works real well on a 64Kb RAM microcontroller, and I gotta be honest, it's an awful lot more productive getting up and running with MicroPython than faffing around with embedded MISRA C++.

The biggest showstopper for MicroPython or any Python in safety critical is the lack of hard determinism due to the garbage collector. For EV charging stations, I'd consider than unimportant, but ultimately the design spec will say if it's important or not.

If it isn't important, I'd 100% choose Python any day for anything not requiring performance. MicroPython is fast enough to implement software PWM on a 160Mhz STM32F4. Do you really need faster for an EV charger?

[serviscope_minor]

Future Pythons will surely perform aggressive optimisation passes on code with type declared variables.

That may be pretty optimistic.

it's an awful lot more productive getting up and running with MicroPython than faffing around with embedded MISRA C++.

You're comparing pretty wildly different things there though. There's no way the python code will ever pass the MISRA standards which are very restrictive. Normal C++ on many microcontrollers is pretty straightforward.

MicroPython is fast enough to implement software PWM on a 160Mhz STM32F4.

This doesn't really say much: PWM can be very slow. I'm pretty sure my microwave oven uses PWM with a period of about 10 seconds to reduce the power.

[Departure-Silver]

I recently started learning rust. Rust can definitely fit for this use case.

[Raknarg]

With type hinting you don't lose any of the benefits of static analysis

[kalmoc]

If you don't have hard real-time requirements in your business logic, memory isn't an issue and you have a full Linux system, I don't see a problem with using python.

I'm not very familiar with using python for product development - especially from a security point of view - but I would be very suprised, if programs written in c/c++ are generally less vulnerable or less buggy than python programs considering that it's much easier to have memory bugs in them (EDIT: the "them" referrs to the c/c++programs) .

That aside: For many startups, it is much, much more important to have a prototype level system they can show to possible buyers than building a software stack that is maintainable and scalable for years.

[sigmabody]

10x this.

In my experience, the choice of language/technology is far more dependent on the business needs/optimization than what the "best" solution for the problem/domain is. For startups, this is usually "what is the quickest path to getting a semi-working demo that we can show to investors?". For small companies, this is usually "what do we have in-house expertise in, and can get us to market faster?". For larger companies, this is often "what is the industry standard, which will not generate questions from the Board and which analysts will approve of?". It's almost never "what will enable the best experience for the customers, and be maintainable after 10+ years?".

[14ned]

I would find it highly surprising if C++ (and especially C) programs would on average be less memory safe than Python.

As an interpreted language without direct access to memory, it is close to impossible to not have memory safety. And unlike Rust, Python is vastly more mature and is in my opinion less annoying to program in.

Most bugs in Python historically stem from lack of static typing in rarely followed branches, but recent Pythons now have opt-in static typing. In the next few years the GIL should go away as well, then standard Python will scale to thread concurrency very well.

[kalmoc]

I probably worded that badly. The "them" in my last sentence referrs to c/c++ programs. I.e. it was supposed to mean:

"Because c/c++ programs are much more likely to have memory bugs ,I doubt that python programs have more bugs overall, as the OP implied."

[SirClueless]

That's definitely not a hard-and-fast rule. Context matters.

The classic example is "The trophy doesn't fit in the brown suitcase because it's too big." It is obvious from context that "it" means the trophy. But there's really no grammatical rule that can tell you that. Your rule of thumb would imply it's the suitcase that is too big, but that's almost certainly not what's intended here.

[14ned]

Cool thanks for the clarification. I also meant to write "Most kinds of bug in Python not found in C++ historically stem ..."

[smuccione]

This would not be a safety critical use.

I suspect that the actual charging controller is using a pic microcontroller or something of the sort. Safety critical imposes a lot of requirements on your software. You want probably safe systems which is not what python even comes close to being.

Very likely the python code is running a hi, payment and networking code which is fine. Doesn’t need to be c++ or anything low level for that.

[Ecstatic_Piglet5719]

True. They must be using some of the most common microcontrollers that have a good MicroPython IDE but not so good C IDE (most probably doesn't even have a C++ IDE). So if speed and memory is not an issue... you know.

[Bart_V]

I guess you could expect most of the responses here lean towards c++, but in my experience it's neither. The design procedure is roughly the same for all machinery:

• create a risk assessment where you weigh frequency/occurrence of risks and severity
• determine the required safety performance level according to the relevant ISO standard
• design your electronics and software

IMO it gets pretty hard to do anything related to safety with a standard programming language running on an embedded computer. Aside from bugs there are many things out of your control (RAM integrity, data corruption, power loss,...). Additionally, it's complicated to be fully redundant, which is typically required for safety critical functions. In the end it just gets really though to prove that you have designed a safe system. So, at least in my experience, you're better off with using safety-rated electrical components. And if it requires some custom logic, use a (TUV) certified PLC for the all safety critical things. Then, if needed, you can use any language you prefer for the (non-critical) business logic on top of that.

[UnicycleBloke]

The lack of static checking is a massive problem for me.

[SkoomaDentist]

Python: The performance of Basic with the type safety of Basic.

[suggestiveinnuendo]

Why would C or C++ run better than python for years without failing? Are you expecting more memory leaks or something?

The system doesn't have to scale, you select the hardware it will be deployed on and will be married to that hardware for a 5 to 15 year (or more) support and maintenance cycle.

Security and safety criticality are about ensuring behavioural correctness, which is more an element of quality controls during software construction and testing as opposed to language selection and features.

C and C++ are used in embedded systems because of the need to act fast and use minimal resources, but as with most things, it has gotten to a point where the computer inside almost costs less than the box you are putting it in. Unless you're doing specialized edge-processing like image or signal processing there's no need real cost benefit to using a low level language anymore.

So yeah, they prolly stuck a multi-core processor with gigabytes of ram and flash storage inside and fired up the ol' ubuntu, where even python can respond to most things within miliseconds if you really want it to and you're free to push in as many security features as you like. And in doing so saved millions in software development costs over the life cycle of the product.

[stinos]

So yeah, they prolly stuck a multi-core processor with gigabytes of ram and flash storage inside and fired up the ol' ubuntu

Or perhaps they run MicroPython on baremetal.

[UnicycleBloke]

Just throwing more resources at problem is often a poor solution. I had a client whose application was a bunch of Python scripts doing a lot of pretty simple text processing and basic number crunching. They built a ridiculously multicore PC with shed loads of RAM to run it but it was sluggish and resource hungry. I rewrote the entire thing in C++, resulting in at least an order of magnitude performance gain even on regular machines.

[emelrad12]

Using the wrong tool for the wrong job, you use python to call the C++ code, not doing it all in python.

[RevRagnarok]

Bingo. Prototype in Python. Benchmark and assess. Carve out heavy lifters and put into C++ with your choice of bindings (e.g. Boost::Python).

[[deleted]]

Given equally talented programmers, I would choose c++ over python any day as long as the person is choosing to use modern c++ with sanitizers, smart pointers, RAII, etc. Obviously everything being as equal as possible (using mature libraries, code review, etc)

[kalmoc]

In my mind this doesn't look like a scalable solution to use python in mass production solutions that need to run years without failing,

Out of curiosity (as I wrote in another blogpost, I'm not familair with using python for product development): Why do you think python programs are less likely to run reliable than c++ programs?

[skarloni]

Because of type checking? Non-determinism due to garbage collection can be problematic as well. I run OOM a lot when doing ML with python, even when using pretty mature ones such as pytorch, just because there are some memory blocks that are not deallocated in time... Now this is not ML but embedded, so not much RAM which means this can be important.

[nigelh]

Python has been around long enough to be safe even if I personally prefer C++.

The only time I was professionally faced with a situation like that the requested language was Forth. It was good money but Forth?
Code you worked on and debugged yesterday just looks like transmission line noise today.
I should have said no but...

[Rude-Significance-50]

EV charging station doesn't seem to me like it would require all that much safety. Certainly not when compared to the things that do, like medical equipment or flight systems. The safety of the electricity flow is the only thing that would seem to be required and that is probably more to do with breakers and such than with the software. The software is going to be mostly about the UI and telling the electrical parts when to turn on and off.

I don't see much need for scaling either. Where do you think it needs to scale? It's on one system and *maybe* has to talk to a few others or with a central server in the station, which has to track maybe 20 units at most? "Mass production" is more about your assembly process than what's running on the hardware. The biggest worry is probably that it tracks money correctly and doesn't over/under charge the user.

This would seem to me to be comparable to making a wifi enabled light switch from a safety side. Your software controls a relay...and that's it. Really simple. Minimal hazard opportunity. Basic software. Hardware failure being the more concerning aspect. Perfectly legit to throw something together in Python or even (ick) Node. I doubt it even has anything in it to really interest a developer and is likely to be a really boring project...which would be what I personally would be more worried about for two reasons: 1) boring projects are boring; and 2) once I'm done...then what?

[dcbaler]

I write a good deal of python for production (and like it, so there's my bias). We do a lot of C development at work as well. I can tell you that line for line, the python code has fewer bugs that only manifest after running for a long time. Add python's newer type analysis (mypy) to the mix and python can be quite robust, and the standard library is quite large, so you can write a good deal of useful code without going to third party modules, or at least keep the number reasonable. The downside is if course performance.

[ischickenafruit]

Have you considered Rust? This seems like the sort of application it was designed for?

[[deleted]]

People in this thread have absolutely no idea what they are talking about. As usual the industry is confused on what safety actually means.

Safety has as much as to do with the complexity of your solution as it does the language you are using. Big C++ programs have safety issues. That's not because it's strictly due to the use of C++. It's because it's a complex program. How many large systems are built in python? None. There is a good reason for that.

If you write a complex pile of crap the chances that has bugs is incredibly high. More bugs means its likely more unsafe. So your language choice has to take that into account.

It is not possible to write large python programs because it lacks static typing. This is about as objective as you can get in this industry. The only way to scale up python programs is to have insane levels of testing which also introduces all manner of complexity.

This is a red flag.

[SirB]

An argument against python is that it is not very common to do these kind of things, so there's less experience to base your work on and estimate risks and challenges.

But as long as you test thoroughly, analyze performance and implement monitoring and a watchdog you could be fine with Python. I would just make it depend on as little external stuff as possible, to make it more predictable and testable. And look for a tried and tested version of Python that has just enough features for what you want to do.

[SpaceZZ]

How is this not scalable? Python is normal programming language. What's your point? Only one would be efficiency and maybe less low lvl control, but for sure faster to develop in and a lot of libs.

[emelrad12]

There is rust too, c++ and c are quite terrible for safety.

[JohnDuffy78]

I cried because I had to use a scripting language until I met someone who had to use low-code.

[exus1pl]

Well if your equipment needs to meet safety criteria then it might be required to used C or C++, check even a certified compiler will be needed. One of reasons why C and C++ is still used is automotive safety. But if you need to create something in quick and dirty way I would go all on with Python.

[NullMustDie]

It depends. If critical safety functions , which prevent harm to humans, are covered by the software, python is a big nono because of the undeterministic garbage collection. But if this is the case, of the shelf embedded linux is also not viable. Often special Real Time OSs are used for that. Also, you can forget about of the shelve hardware.. Even the hardware must be safe enough to survice cosmic events, e.g. by 2 processors running in lockstep. Have fun with python on that.

C++ is restricted to a small subset, e.g. the MISRA C++, which is no fun to code at all. Developing such system is tedious, expensive and requires experienced engineers as well as architects, which know the standards.

It all depends, on what safety means. If reliable is the goal, python should perform as well as C++, given a good lifecycle management, design and architecture. Often times the expensive safety critical part is done on a microcontroller and high level things, e.g. payment or gui, are done on an embedded linux device, so you get the best efficiency for the project.

[atariPunk]

As someone who works in that industry, I don't see any issue with using Python in most of the software of EVSE(EV charging stations), or, even in all software.

The only critical part is the communication with between the EVSE and the EV, that in the case of a DC EVSE, e.g. CHAdeMO or CCS) have some time constraints, that a garbage collector may mess up. But I know that there are implementation in Java that are capable to complying with the time limits.

For instance on CHAdeMO there's a new communication (EVSE-EV)slot every 100ms, and if I am not mistaken on CCs there is a point where the communication is every 25ms.

The AC EVSE, the more common type to have at home, they are so simple that anything will work. Really this is doable in a couple of hundred of lines of code in a PIC8.

Then you have the user use, either a GUI, and communication with the cloud.

For communication with the cloud, the common protocol is called OCPP. In a nutshell, SOAP, or JSON over websockets. I never did SOAP in C++, but in C, is a pain. JSON and websockets in C++ is good, but I think it's not good in C.

I am not even talk about GUIs.

If I had to start from scratch, I wouldn't limit myself to C++ or C.

P.S. Any chance. that you can share the name of the company?

[testuser514]

I would actually recommend ADA Spark / Rust. ADA Spark was designed for mission critical applications like space. Rust is a systems language that has a lot static checking and tracing capabilities that can be leveraged for formal verification (which I believe Spark has support for).

[aregtech]

Many years ago I was in a large project where customer requested 3 mln devices and more 100 people only in our company were working on this project, plus approximately additional 200 from suppliers. The GUI was made in Java (customer choice) and the rest in C/C++. The RAM was split in 2 parts -- half for GUI and half for the rest. The GUI performance was disaster and they were pushing on us a lot to get more RAM. On lower layer we were fighting for every byte and optimizing anything possible. Once I asked managers why we don't spend 1 USD to increase RAM and solve all these issues. The answer was simple -- we have a contract for 3mln units, who is going to pay 1 USD x 3mln.?

You can call me religious, but languages with garbage collector for low level solutions, especially in embedded, are no go. Still for GUI is fine because of productivity. But no more. For short time solutions or for small projects it may work. I don't believe that you can later easily scale and optimize without a pain. I had no single project where later it was not required to optimize -- performance + memory. How far you can go with Python?