C# for Embedded ?...

IMHO, plain C, and maybe MISRA is the way to go.

--

-TV

Thanks. My feelings exactly and if a rtos is needed, something qualified for avionics work. The project is very mech eng centric and i'm not convinced that they really understand how critical the control software is to the success and safety of the system. As for Misra, not sure they have ever heard of it...

Regards,

Chris

Alarm bells are definitely in order.

C# is MS's answer to Java, and highly Windows-centric. The Mono open-source port of the C# VM does have support for some embedded architectures, but this should have been verified for your target prior launching into development...

See:

While I've used C# for Windows applications I haven't tried it on an embedded platform. For embedded projects normally I use C++

Hope that helps! Best Regards, Dave

Thanks for the reply and link. Do homework before going in etc :-).

So from what I can see, it's a big systems language in memory requirements for libraries and run time support. C# also uses dynamic memory allocation and garbage collection, another red line for the this type of application.

Wouldn't surprise me to find out they are using Embedded Linux, but hope not...

Regards,

Chris

g

or ADA. But it depends on the platform and the compilers.

Bye Jack

C# is a big red flag, not only for embedded but also for safety critical.

Others have made suitable language suggestions, but I'll note that in safety critical applications the process is at least as important as the language and libraries.

As with any engineering, it is necessary to consider not only what will "go right", but what could "go wrong" - and the latter will often shape the entire design and design process.

In bad cases, "go wrong" includes lawyers doing "discovery" to find anything they can latch onto and prove liability.

The "application" part is pretty accurate.

C# is designed primarily to be a safe(r) version of C with the addition of single inheritence objects [unlike C++ which has multiple inheritence].

C# is a managed language with GC - much like Java. However, unlike Java, C# has an "unsafe" mode that can bypass the runtime, eschew GC, and work directly with hardware.

That's probably true. I haven't paid attention to it.

The "alarm bells" I hear are availabiliy and performance of the CLR runtime on your hardware. AFAIK, it's only available for Windows and Linux. The Mono version might also run on Unix, but I don't know that for certain.

The "unsafe" mode of C# can do anything C can do ... but IMO there's no point to C# unless you are going to use objects and GC - and that requires the runtime.

YMMV, George

I just want to put an underscore here. I've had the "ADA vs. C" discussion with various high-rel types before, and you can pretty much divide the answers down to three bins: two are filled by "my language is better because it's better", and the remaining one is filled by "get the process right, and either C or ADA will do".

I don't think that anyone who is sane would want to use a language like Java or C#.

If a failure can injure or kill, you need to use a tool chain and library set that's up to the task -- for avionics, they need to be certified to the same level of criticality as the code itself; I would treat automotive with the same regard. I don't think you'll find a C# compiler, much less a platform on which C# will run, that even comes close.

--
www.wescottdesign.com

There are two /very/ different meanings of "safe" here. In typical c.a.embedded systems, "safe" means "Code does exactly what the designer wants it to do, otherwise someone could be injured or killed". In the world of C#, Java, Windows, etc., "safe" means "is unlikely to have serious security flaws that let bad guys steal your passwords and send you adverts for small blue pills".

I would not trust C# to be more than mid-level "safe" in its own meaning of the word, and that's before anyone writes a line of application code. Neither the tools, the run-time libraries, nor the platforms it runs on come anywhere close to c.a.e. "safe".

(The language itself might be all right - as has been pointed out, it is the process that has to be safe, not the language.)

I agree with your negative concerns about the choice. But from a testing point of view, any language is just as good as any other *IF* it can be proved as such through thorough testing. I would hope there are well defined SW QA requirements. Using C# just opens up a lot of possible quality holes that might be avoided with some other programming language. Every hole needs to be tested. Every test costs money and time. It sounds like your customer is wearing blinders and only looking at how easy it would be for the programmer to code it. I think if you're opposed to C#, present a case in terms of dollars that will convince them the choice is ill considered. It's always all about money after all.

JJS

The process AND the tools, AND the libraries.

In this case I wouldn't trust the tools and libraries unless they were independently verified (because Microsoft's idea of verification is "oh, you'll buy our stuff if we say it'll work for you -- hey! Guess what? Our stuff will work for you!")

--

Tim Wescott 
Wescott Design Services 
http://www.wescottdesign.com 

I'm looking for work -- see my website!

Agreed.

I'd like to add a second underscore...

Getting the process right will, as a side effect, show that you will almost certainly need to choose a /subset/ of a language. MISRA C and SparkADA spring to mind.

Subsets are necessary to avoid the underdefined parts of languages and toolchains, and to avoid design practices and patterns that are typically problematical in various ways.

As the others has already stated the C# is not suitable for the real-time a nd safety-critical systems.

Typically there are two options:

1. Use Ada language.
2. Use MISRA subset of C language.

Some people might argue that C++ would be just fine, but I would argue that it is very easy to create something that is doing something that you didn' t intend to do. The C++ is such a clever language that I will do some thing s behind the scene (like allocate an object from the dynamic heap although you didn't do it explicitly) unless you are very careful and know what to d o. So, I would rule out the C++ unless you are really competent with it.

In addition to the suitable programming language you will need an operating system. Typically in a real-time systems you would need an operating syste m that has real-time features. However, in a safety critical systems you wi ll need an OS that is simple enough to be safely used in a safety critical systems.

I am not an expert of the safety critical systems, so I will not be able to point you to any direction on selecting the operating system.

However, what I have read and learnt, the operating systems of highly relia ble systems (like early satellites at least) had very simple "operating sys tems" that didn't have any fancy features like pre-emptive multitasking or even interrupts. The "operating system" was just a simple control loop runn ing fast enough using polling to get the data from the sensors. What, no in terrupts or multitasking? Why? Because the simple system was predictable. S omething that a real-time and safety-critical system needs to be.

Want tasks anyway? No problemo, just implement the tasks as state machines, and use a simple yet effective timer-triggered, co-operative, run to compl etion tasker.

Br, Kalvin

No. It was designed as a response to Java's success, and was a traditional Microsoft attempt to keep developers on the Windows platform.

There are two, and only two significant differences with Java: a different runtime philosophy ("ahead of time" vs "just in time"/Hotspot optimisation), and the addition of code marked "unsafe".

The latter destroys the advantages of having a managed environment, doh!

When we put those points to Anders Hjelsberg (C#'s designer) a few months before C# became available, he did not provided a substantive answer, let alone a rebuttal)

You can work directly with hardware in Java using the JNI interface and C/assembler/ADA/etc.

There is, nominally, a realtime Java, but the necessary restrictions make it almost completely unlike Java. There's zero benefit to it over other languages.

OTOH, when I've needed to create clustered high availability soft realtime systems (e.g. telco), then Java is my language of choice.

Java is also favoured in the financial sector, where they spend /vast/ amounts or money to shave a few milliseconds latency! Example: laying dedicated trans-Atlantic fibre optic cables, resurrecting microwave links between Chicago and New York, and "blowing" /trading/ /algorithms/ into FPGAs.

Java is not necessarily slow, although like any language, it can be made slow :)

Flip your question around:

- why has C# been chosen (could it be that the developers chose it due to their familiarity with it and belief that one size fits all?)

- what does C# bring to the table (in their minds) that other languages don't (or, don't do as well)

These are THEIR questions to answer, not yours.

Virtually any language can be made safe -- if the particular implementation is "well documented" and "predictable". But, typically requires a higher level of expertise of the developers. This, in turn, tends to limit the pool of individuals who can be called on to develop and maintain the product.

Also, "safety critical" can mean a variety of different things. And, can be addressed in a variety of different ways. E.g., a system can be designed to shutdown if it starts to "misbehave" or fails to behave predictably. OTOH, if that drives your availability to zero, the system may be considered effectively useless.

The concern *I* would have is that C# is a MS product and they haven't been known to stress stability, accuracy or reliability in ANY of their products. Is it hosted on anything OTHER than Windows? Do you really think Windows itself has been "qualified" to the level of safety criticality/availability that the application requires?

If I was in your shoes, I'd be asking those advocating for C#/Windows to defend their choice -- under an aggressive set of applicable criteria.

Make sure such people can provide good answers to the "Frequently Questioned Answers"

It is worse than that: the /designers/ didn't understand what they were creating, so what chance do you think mere mortals have!

It was discovered the c++ template was Turing-complete, but the design committee didn't believe it until someone rubbed their noses in it by causing the compiler to emit the sequence of prime numbers during (infinite) compilation! That's from The original is at

Note: not designed, but discovered - and that's exactly what happened.

g something that you didn't intend to do. The C++ is such a clever language that I will do some things behind the scene (like allocate an object from the dynamic heap although you didn't do it explicitly) unless you are very careful and know what to do. So, I would rule out the C++ unless you are re ally competent with it.

I just wanted to bring that up as I do see C++ suitable for the safety-crit ical applications, although there may be some people suggesting that C++ is suitable for the safety-critical applications as there is also the MISRA C

++ subset. But the C++ is really hard to master so that it behaves predicta bly.

Br, Kalvin

The problem is that many languages/implementations are buggy or temperamental or contain nondeterministic characteristics that can hinder testing.

I use Limbo as a scripting language yet it has many areas where the implementation isn't quite as predictable as I'd like OTOH, it is a much "safer" environment for casual developers; many of the things that "seasoned professionals" often get caught making errors (buffer overruns, dereferencing pointers, etc.) are simply not possible.

But, it's much harder for me (or said users) to look at a limbo code fragment and predict how well it will behave in any given set of circumstances (e.g., how long will it take to execute? when will the GC kick in? what will happen when there is insufficient memory to satisfy the next dynamic memory request? what happens if the target of a remote communication channel goes down?)

And every language moves those holes to different places in the development process and runtime!

It sounds like the programmers have picked a tool/environment with which they are comfortable/familiar -- instead of considering its applicability! Note that if the developers are held constant, ALL OTHER CHOICES may, in fact, be *worse*! :>

perjantai 4. marraskuuta 2016 20.58.59 UTC+2 snipped-for-privacy@gmail.com kirjoitti:

ing something that you didn't intend to do. The C++ is such a clever langua ge that I will do some things behind the scene (like allocate an object fro m the dynamic heap although you didn't do it explicitly) unless you are ver y careful and know what to do. So, I would rule out the C++ unless you are really competent with it.

itical applications, although there may be some people suggesting that C++ is suitable for the safety-critical applications as there is also the MISRA C++ subset. But the C++ is really hard to master so that it behaves predic tably.

Nice typo above. Of course I meant to say "I just wanted to bring that up a s I do *not* see C++ suitable for the safety-critical applications ..."