Re: Ada in command / control systems

[Maciej Sobczak <see.my.homepage@gmail.com>]

> Once you let user-defined stuff in, you risk a situation when there 
> would be no corresponding system of equations or no solution of the 
> system. Simulink, wisely, does not attempt to resolve this. It admits 
> defeat allowing so-called s-functions: a piece of code written in a 
> *sane* language that implements what Simulink cannot (more or less 
> everything). So much for modeling...

Great! Now you can have the best of two worlds instead of being slowed down by the limitations of any particular approach. Of course, this opens an opportunity for a turn-key sets of such s-functions, which you can just pick from the library and drop in your model. So, no, you're not going to write any of this, everything will be written for you already. FPGA people call these "IP cores" and everybody seems to love them.

The fact that you can have blocks implemented in some other formalism whenever needed, instead of fighting with the tool, only gives more credibility to modeling. Ironically, you do it with Ada, too, when you rely on components (OSs, DBs, middleware, etc.) written in a sane language like C (sorry, could not resist :-) ). Actually, Ada would be dead already if this possibilities did not exist. Same with modeling.

> Simulink is an example of why this does not work on larger scale. You 
> can have a small subcomponent in Simulink, but all falls apart once you 
> move to larger components and their interplay.

Still I don't see how this is worse from source code. Things seem to fall apart no matter what we try to stick together. Maybe we're just bad at engineering software.

> My suspicion is that 
> there cannot be such thing as a unified model language, in some strong 
> fundamental way.

I agree here. So let's mix different modeling formalisms when needed. How about a Simulink model that refers to s-functions implemented by generating code from some other modeling tool, like SCADE? There is no need for a unified language if every team member can have their own, right?

(Yes, it's that bad.)

> I have crashed compilers, too.
> 
> Yes, but you do not start patching the object code. Assembler insertions 
> are extremely rare. s-functions is a norm

You are mixing arguments. Before you have argued that your modeling tool crashed when you have hacked its files by hand (which is hardly an argument against modeling). Now you don't like s-functions (which everybody uses elsewhere, see the other posts about Python code in GNAT). Please don't mix these things, so I can debunk them one by one.

> you have to break out of the 
> model abstraction and write a lot around it in order to make that puny 
> model work.

Which is a norm in this industry. All high-level languages rely on modules implemented in other (presumably low-level) languages. Python would not exist if everybody expected it to be functionally closed, instead, everybody is happy with Python calling C functions below it. Same with modeling.

> Companies cannot claim 
> software free of any liability anymore.

Which is very interesting and I even applaud it. But here we are talking about tools. And it is a long established tradition to verify final software products in a way that recognizes or bypasses tool deficiencies. That is, the safety of airplane does not depend on Simulink crashing or not. In this scheme (and I don't see this scheme going away) the tool vendor does not take any liability for plane crashing.

> Even giants like Facebook and 
> Amazon get charged.

Because they make final software (tool vendors don't). And as long as these companies believe that modeling allows them to get their stuff released faster, they will use modeling, with all its deficiencies. And tool vendors will do their best to keep this show going.

> I don't know how the industry is going to refund 
> these new liabilities. At some point they will have to and the pyramid 
> will collapse.

I'm not such optimist. I don't see it happening any time soon.

-- 
Maciej Sobczak * http://www.inspirel.com