Re: Ada in command / control systems

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

> > In what way it is not scalable?
> 
> You have a model running a simple loop: read all inputs, calculate, 
> write all outputs. If you have events, many loops, input/outputs that 
> come and go, you are in deep trouble. If you have 10k inputs all 
> asynchronous?

I agree with these examples, they would be very challenging for Simulink. But I did not refer to Simulink specifically, but to the MBD as a general approach. There is no reason to limit MBD to "a model running a simple loop" only.

> Add here lack of any modularity and abstraction.

Here I disagree. Even if we stick to Simulink (which was never intended), operators can nested and higher-level modules can be easily created.

> It is OK 
> when fancy blocks and edges fit into one screen. What about two? What is 
> when they do not fit into ten football fields?

What if your source code does not fit into one screen? It's the same problem and has similar solutions.
At least on diagrams, lines going over the football field can be continuous, which makes them somewhat easier to follow. This has no equivalent in source code and if you have the same signal referred by N places in source, there is no visual clue that they are related at all.

> >> The software designed this way is not verifiable, non-testable.
> 
> How do you merge or decide if two graphs are equivalent?

This has nothing to do with testability. It's the configuration management thing and I agree that graphical tools are at disadvantage here and I very much prefer to diff and patch text than diagrams. Nobody seems to care, though and it has to be admitted that tool vendors, on their part, are catching up in this regard, too; newer tool versions become more and more passable in this area.

> So, for the sake of argument, let's consider Ada program a requirement 
> and Ada compiler a generator of object code (which Ada compiler indeed is).
> 
> I claim that Ada is an infinitely better requirement language than 
> Simulink blocks.

You are almost correct, except you have mixed levels. Simulink blocks are considered low-level requirements and Ada source code is further below it in the hierarchy. So it cannot be better. It can be better than something at the same level, for example C source code. But it cannot be better than something higher, because you cannot replace one with another.

However, it is reasonable to treat package specs (especially with contracts) as low-level requirements, which are then fulfilled at the implementation level by package body sources. Now your claim would be interesting - and I would actually agree. I have actually promoted such idea on one of the LinkedIn groups.

But nobody cares. Get ready for MBD.

> It is like with all other entitlements. When you run out of other 
> people's money the party ends...

But you have noted yourself that other domains are happy to bleed to keep financing this mess. So the party goes on.

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