C# for Embedded ?...

> I've been invited to a meeting to discuss am automotive like engineering
> project with a high level of safety critical requirements.
>
> They are using Simulink for some of the top level design work, but are
> programming the whole lot in C#, with some of the code already written.
> Not sure at this stage which rtos is being used, if at all.
>
> From what I've read, C# is a web / application / database programming
> language and a quick look at the Wiki page suggests that the two
> most recent versions are not approved by any international standards
> organisation.
>
> C# raises alarm bells here for all kinds of reasons, but what do you
> think ?...

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

On Fri, 04 Nov 2016 17:54:56 +0100, David Brown wrote:

> On 04/11/16 17:07, George Neuner wrote:
>> On Fri, 04 Nov 2016 13:12:57 +0000, Chris <xxx.syseng.yyy@gfsys.co.uk>
>> wrote:
>>
>>> From what I've read, C# is a web / application / database programming
>>> language
>>
>> 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.
>>
>>> and a quick look at the Wiki page suggests that the two most recent
>>> versions are not approved by any international standards organisation.
>>
>> That's probably true.  I haven't paid attention to it.
>>
>>> C# raises alarm bells here for all kinds of reasons, but what do you
>>> think ?...
>>
>> 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.
>>
>>
> 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.)

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!

On 04/11/16 16:32, Tim Wescott wrote:
> On Fri, 04 Nov 2016 15:37:22 +0000, Tom Gardner wrote:
>
>> On 04/11/16 13:12, Chris wrote:
>>> Hi,
>>>
>>> I've been invited to a meeting to discuss am automotive like
>>> engineering project with a high level of safety critical requirements.
>>>
>>> They are using Simulink for some of the top level design work, but are
>>> programming the whole lot in C#, with some of the code already written.
>>> Not sure at this stage which rtos is being used, if at all.
>>>
>>>   From what I've read, C# is a web / application / database programming
>>> language and a quick look at the Wiki page suggests that the two most
>>> recent versions are not approved by any international standards
>>> organisation.
>>>
>>> C# raises alarm bells here for all kinds of reasons, but what do you
>>> think ?...
>>
>> 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.
>
> 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.

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 and 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 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 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 system that has real-time features. However, in a safety critical systems you will 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 reliable systems (like early satellites at least) had very simple "operating systems" that didn't have any fancy features like pre-emptive multitasking or even interrupts. The "operating system" was just a simple control loop running fast enough using polling to get the data from the sensors. What, no interrupts or multitasking? Why? Because the simple system was predictable. Something 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 completion tasker.

Br,
Kalvin

On 04/11/16 16:07, George Neuner wrote:
> On Fri, 04 Nov 2016 13:12:57 +0000, Chris <xxx.syseng.yyy@gfsys.co.uk>
> wrote:
>
>>  From what I've read, C# is a web / application / database programming
>> language
>
> 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].

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)

> 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.

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 :)

On 11/4/2016 6:12 AM, Chris wrote:
> Hi,
>
> I've been invited to a meeting to discuss am automotive like engineering
> project with a high level of safety critical requirements.
>
> They are using Simulink for some of the top level design work, but are
> programming the whole lot in C#, with some of the code already written.
> Not sure at this stage which rtos is being used, if at all.
>
>  From what I've read, C# is a web / application / database programming
> language and a quick look at the Wiki page suggests that the two
> most recent versions are not approved by any international standards
> organisation.
>
> C# raises alarm bells here for all kinds of reasons, but what do you
> think ?...

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?

<https://gcn.com/Articles/1998/07/13/Software-glitches-leave-Navy-Smart-Ship-dead-in-the-water.aspx>

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.

On 04/11/16 18:22, kalvin.news@gmail.com wrote:

> Some people might argue that C++ would be just fine,

Make sure such people can provide good answers to
the "Frequently Questioned Answers"
http://yosefk.com/c++fqa/


> 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 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 really competent with it.

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
<https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP>
The original is at <http://www.erwin-unruh.de/primorig.html>

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

On 11/4/2016 7:30 AM, Chris wrote:
> On 11/04/16 13:44, Dave Nadler wrote:
>> On Friday, November 4, 2016 at 9:13:01 AM UTC-4, Chris wrote:
>>> C# raises alarm bells here for all kinds of reasons, but what do you
>>> think ?...
>>
>> 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: http://www.mono-project.com/docs/about-mono/supported-platforms/
>>
>> 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.

"Big system language" and "memory requirements" and "runtime"
don't preclude a particular choice.  Consider Ada in your
above assessment (hardly "small", economical, etc.).

Embedded systems come in all different sizes and varieties.
Also the "depth" of the embedding varies tremendously
(the code running on the Mars Rover is designed to operate
in a very different environment than the code that runs
the cash registers at your local supermarket!)

As do the consequences of failures, etc.

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

Why?  It might be *perfectly* suited to the application -- that
you've not disclosed.

What you want to see is that "they" understand the issues
that are important to THEIR application -- along with the
capabilities, characteristics and limitations of the tools
and implementation they are choosing -- and in sufficient
detail that they can anticipate the sorts of problems they
WILL encounter in reifying the design... so they can AVOID
them in their implementation.

perjantai 4. marraskuuta 2016 20.51.03 UTC+2 Tom Gardner kirjoitti:
> On 04/11/16 18:22, kalvinnospamherenews@gmail.com wrote:
> 
> > Some people might argue that C++ would be just fine,
> 
> Make sure such people can provide good answers to
> the "Frequently Questioned Answers"
> http://yosefk.com/c++fqa/
> 
> 
> > 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 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 really competent with it.
> 
> 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
> <https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP>
> The original is at <http://www.erwin-unruh.de/primorig.html>
> 
> Note: not designed, but discovered - and that's exactly
> what happened.

I just wanted to bring that up as I do see C++ suitable for the safety-critical 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 predictably.

Br,
Kalvin

On 11/4/2016 10:03 AM, John Speth wrote:
>> I've been invited to a meeting to discuss am automotive like engineering
>> project with a high level of safety critical requirements.
>>
>> They are using Simulink for some of the top level design work, but are
>> programming the whole lot in C#, with some of the code already written.
>> Not sure at this stage which rtos is being used, if at all.
>>
>> From what I've read, C# is a web / application / database programming
>> language and a quick look at the Wiki page suggests that the two
>> most recent versions are not approved by any international standards
>> organisation.
>>
>> C# raises alarm bells here for all kinds of reasons, but what do you
>> think ?...
>
> 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.

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?)

> 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.

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

> It sounds like your customer is
> wearing blinders and only looking at how easy it would be for the programmer to

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*!  :>

> 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.