Ada in command / control systems

Ada in command / control systems

[Jesper Quorning]

Why is Ada not used on industrial programmable logic controllers (PLC) platforms?

In the IEC 61131-3 standard, the language 'structured text' is defined. The language looks like the poor man's Ada.

I have not worked with structured text, but with SCL (Structured Contol Language) for Siemens S7-300 / 400/1200/1500. It looks like there are elements of Ada in it.

Should industrial programs not be Ada's wheelhouse?


        Jesper.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-25 07:51, Jesper Quorning wrote:
> 
> Why is Ada not used on industrial programmable logic controllers (PLC) platforms?

Because the PLC marked is dominated by vendors pushing their vendor-lock 
solutions, e.g. Siemens.

Another reason is the customers lacking elementary programming and 
software design skills. They are usually technicians and electrical or 
mechanical engineers.

> In the IEC 61131-3 standard, the language 'structured text' is defined. The language looks like the poor man's Ada.
> 
> I have not worked with structured text, but with SCL (Structured Contol Language) for Siemens S7-300 / 400/1200/1500. It looks like there are elements of Ada in it.

Is it a joke?

> Should industrial programs not be Ada's wheelhouse?

Possibly, if Ada community would pay attention to the emerging market of 
single board computers used at home.

In about 5-10 years so-called industrial solutions will be swept away by 
cheap hardware and hobby software coming from the home automation toy 
projects. These will be far worse than awful SPS, who could think that 
worse were possible? But the force of mass market is overwhelming. SPS 
et al will suffer the same fate as workstations did.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Jesper Quorning]

On Monday, February 25, 2019 at 9:24:33 AM UTC+1, Dmitry A. Kazakov wrote:

> Because the PLC marked is dominated by vendors pushing their vendor-lock 
> solutions, e.g. Siemens.

Is this so different from Ada suppliers?
There are also vendors like Beckhoff (lightweight PLCs) using open standards.

> Another reason is the customers lacking elementary programming and 
> software design skills. They are usually technicians and electrical or 
> mechanical engineers.

Therefore, Ada is such an advantage. I myself am not a very good programmer, so Ada would help me not be called at 3 am with a production line that does not work somewhere in a remote timezone.

In SPS systems, we do not like dynamic memory allocation, so maybe SPARK without a tasking would be sufficient for many applications. The languages ​​used already do what they can to limit the programmer to not make too many mistakes.

Technicians and engineers are people too. They try to do what they can with the training af tools they have.

> > It looks like there are elements of Ada in it.
> Is it a joke?

No, it's not a joke.
For me, it seems that Ada was considered when SCL was designed, but was considered too abitious. Ada is a much better language than SCL, which is Pascal-like. Small things like "=>" and "-" comments are used for online inspection. Also END_IF and END_CASE looks like Ada influence.

> In about 5-10 years so-called industrial solutions will be swept away by 
> cheap hardware and hobby software coming from the home automation toy 
> projects. These will be far worse than awful SPS, who could think that 
> worse were possible? But the force of mass market is overwhelming. SPS 
> et al will suffer the same fate as workstations did.

SPS was also considered dead 20 years ago. However lots of new systems are put into operation every single day. The SPS market is very conservative. When a customer signs an acceptance test he expects the program to be working flawlessly for 15+ years (in principle).

Venders has tested and time-tested solutions with many documentation and spare parts delivery systems worldwide. Hobbyist does not have that.


        Jesper.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-25 10:44, Jesper Quorning wrote:
> On Monday, February 25, 2019 at 9:24:33 AM UTC+1, Dmitry A. Kazakov wrote:
> 
>> Because the PLC marked is dominated by vendors pushing their vendor-lock
>> solutions, e.g. Siemens.
> 
> Is this so different from Ada suppliers?

Compiler vendors do not sell hardware.

> There are also vendors like Beckhoff (lightweight PLCs) using open standards.

There are plenty of software SPS.

>> Another reason is the customers lacking elementary programming and
>> software design skills. They are usually technicians and electrical or
>> mechanical engineers.
> 
> Therefore, Ada is such an advantage. I myself am not a very good programmer, so Ada would help me not be called at 3 am with a production line that does not work somewhere in a remote timezone.

Yes, but non-programmers have prejudices and very peculiar ideas about 
perceived complexity. They consider Ada complex when in fact it is far 
simpler than tools they consider simple.

> In SPS systems, we do not like dynamic memory allocation, so maybe SPARK without a tasking would be sufficient for many applications. The languages ​​used already do what they can to limit the programmer to not make too many mistakes.

Formal verification can (and must) be used even if dynamic memory 
allocation is used.

> Technicians and engineers are people too. They try to do what they can with the training af tools they have.

Yes and this shapes the landscape of these tools.

>> In about 5-10 years so-called industrial solutions will be swept away by
>> cheap hardware and hobby software coming from the home automation toy
>> projects. These will be far worse than awful SPS, who could think that
>> worse were possible? But the force of mass market is overwhelming. SPS
>> et al will suffer the same fate as workstations did.
> 
> SPS was also considered dead 20 years ago.

SPS is dead, there is no hardware SPS anymore. Software SPS is next. It 
is to expect some incredibly ugly free tools to appear, some influenced 
by software SPS, in the sense that they will inherit the worst features of.

> However lots of new systems are put into operation every single day. The SPS market is very conservative. When a customer signs an acceptance test he expects the program to be working flawlessly for 15+ years (in principle).

That does not matter. When the next generation of engineers come they 
will use tools they know best. This is how PC eradicated everything 
else. There will be no more SPS market at all.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[russ lyttle]

On 2/25/19 3:24 AM, Dmitry A. Kazakov wrote:
> On 2019-02-25 07:51, Jesper Quorning wrote:
>>
>> Why is Ada not used on industrial programmable logic controllers (PLC) 
>> platforms?
> 
> Because the PLC marked is dominated by vendors pushing their vendor-lock 
> solutions, e.g. Siemens.
> 
> Another reason is the customers lacking elementary programming and 
> software design skills. They are usually technicians and electrical or 
> mechanical engineers.
> 
>> In the IEC 61131-3 standard, the language 'structured text' is 
>> defined. The language looks like the poor man's Ada.
>>
>> I have not worked with structured text, but with SCL (Structured 
>> Contol Language) for Siemens S7-300 / 400/1200/1500. It looks like 
>> there are elements of Ada in it.
> 
> Is it a joke?
> 
>> Should industrial programs not be Ada's wheelhouse?
> 
> Possibly, if Ada community would pay attention to the emerging market of 
> single board computers used at home.
> 
> In about 5-10 years so-called industrial solutions will be swept away by 
> cheap hardware and hobby software coming from the home automation toy 
> projects. These will be far worse than awful SPS, who could think that 
> worse were possible? But the force of mass market is overwhelming. SPS 
> et al will suffer the same fate as workstations did.
> 
Languages like VHDL and SCL do borrow a lot from Ada. I've noticed that 
it is much more difficult for C/C++ programmers to learn VHDL or SCL 
than Ada programmers. But, as you say, the Ada community seems to be 
ignoring the areas where these languages are applied.

There is some support for STM (thanks Simon Wright) but has  anyone 
tried to write an Ada program for an AT Tiny? Have you noticed how many 
*.py files are in the Ada_Drivers_Library? Or how horrible gnat is on 
memory management?

Another point, having an OS written in Ada would make qualification of 
software much much easier. No need to qualify C/C++ or Python. In my 
case an Ada equivalent of Minix-1 or uCOS (first version published in 
Embedded Systems) would be very handy.

Re: Ada in command / control systems

[gautier_niouzes]

> Languages like VHDL and SCL do borrow a lot from Ada.

Same for database languages PL/SQL and PL/pgSQL (without drawing any conclusion about the rest of the statement).

Re: Ada in command / control systems

[Simon Wright]

russ lyttle <lyttlec@removegmail.com> writes:

> There is some support for STM (thanks Simon Wright) but has  anyone
> tried to write an Ada program for an AT Tiny?

Probably: see https://sourceforge.net/projects/avr-ada/

> Have you noticed how many *.py files are in the Ada_Drivers_Library?

12.

I am a bit disheartened by the way that the build system for tools like
GNATColl is migrating towards Python. What's wrong with Make? (I do draw
the line at autotools, though)

On the other hand, I do quite understand _why_ people write tools in
Python; I've done it myself.

> Or how horrible gnat is on memory management?

I'm not sure how horrible it is? I know it was an effort to squeeze a
slightly complex demo into a BBC:microbit (16k ram).

Re: Ada in command / control systems

[russ lyttle]

On 2/25/19 10:25 AM, Simon Wright wrote:
> russ lyttle <lyttlec@removegmail.com> writes:
> 
>> There is some support for STM (thanks Simon Wright) but has  anyone
>> tried to write an Ada program for an AT Tiny?
> 
> Probably: see https://sourceforge.net/projects/avr-ada/
> 
Is there a recent update to Avr-Ada? It seems the last update was 3 
years ago. My first targets are ATtimy and ATmega328.

>> Have you noticed how many *.py files are in the Ada_Drivers_Library?
> 
> 12.
> 
> I am a bit disheartened by the way that the build system for tools like
> GNATColl is migrating towards Python. What's wrong with Make? (I do draw
> the line at autotools, though)
> 
> On the other hand, I do quite understand _why_ people write tools in
> Python; I've done it myself.
> 
Python is better than C++ for one-off programs that don't have to be 
proven correct. I have the problem of showing that the 
Ada_Drivers_Library can be built without using any of the python code 
and using either Make or gnatmake. This doesn't look like a big 
stumbling block, but it is one of many. I'm looking for a tutorial for 
writing gpr files that goes beyond the trivial and isn't Windows 
specific ( -Xlinker Wl,--stack=... for example).

>> Or how horrible gnat is on memory management?
> 
> I'm not sure how horrible it is? I know it was an effort to squeeze a
> slightly complex demo into a BBC:microbit (16k ram).
> 
I have the problem of writing code only in Ada, for multiple targets 
with limited resources. The software has to be maintainable and 
re-usable for 25 years. Stack and heap space needs to be specified for 
each task at compile time. Some items need to be specified to be 
allocated to EEPROM, some to RAM, etc. Ideal would be to do this 
programatically with a *.ads configuration file. Right now I can't get 
gnat make to accept a stack size on Ubuntu 18.10. That "-Xlinker 
Wl,--stack=" idiom only works on Windows.

Again thanks for the good work.

Re: Ada in command / control systems

[J-P. Rosen]

Le 25/02/2019 à 20:21, russ lyttle a écrit :
> Stack and heap space needs to be specified for
> each task at compile time.
Did you specify Storage_Size for the tasks? Note that it needs not be
static, so you can read it from a configuration file, f.e. Heap space
does not belong to a single task, it is shared. If an access type is
local to a task, you can specify its space independently though.

> Some items need to be specified to be
> allocated to EEPROM, some to RAM, etc.
You can do that with address clauses.

> Ideal would be to do this
> programatically with a *.ads configuration file.
Address clauses need not be static, so you can specify them with values
read from a file.


-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Ada in command / control systems

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 25/02/2019 à 20:21, russ lyttle a écrit :

>> Some items need to be specified to be
>> allocated to EEPROM, some to RAM, etc.
> You can do that with address clauses.

The compiler will straightforwardly distinguish between text, read-only,
read-write, and bss.

If you need more, you can (GNAT) use pragma Linker_Section: for
interrupt vectors for an STM32F4,

   Vectors : array (-14 .. Ada.Interrupts.Names.FPU_IRQ) of Handler :=
     (-9 .. -6 | -4 .. -3 => null,                      -- reserved
      -14                 => Dummy_Handler'Access,      -- NMI
      -13                 => HardFault_Handler'Access,  -- HardFault
      -12                 => Dummy_Handler'Access,      -- MemManagement
      -11                 => Dummy_Handler'Access,      -- BusFault
      -10                 => Dummy_Handler'Access,      -- UsageFault
      -5                  => SVC_Handler'Access,        -- SVCall
      -2                  => PendSV_Handler'Access,     -- PendSV
      -1                  => SysTick_Handler'Access,    -- SysTick
      others              => IRQ_Handler'Access)
     with
       Export,
       Convention         => Ada,
       External_Name      => "isr_vector";
   pragma Linker_Section (Vectors, ".isr_vector");

and then use the linker script to place that section appropriately.

Re: Ada in command / control systems

[lyttlec]

On 2/26/19 10:50 AM, Simon Wright wrote:
> "J-P. Rosen" <rosen@adalog.fr> writes:
> 
>> Le 25/02/2019 à 20:21, russ lyttle a écrit :
> 
>>> Some items need to be specified to be
>>> allocated to EEPROM, some to RAM, etc.
>> You can do that with address clauses.
> 
> The compiler will straightforwardly distinguish between text, read-only,
> read-write, and bss.
> 
> If you need more, you can (GNAT) use pragma Linker_Section: for
> interrupt vectors for an STM32F4,
> 
>    Vectors : array (-14 .. Ada.Interrupts.Names.FPU_IRQ) of Handler :=
>      (-9 .. -6 | -4 .. -3 => null,                      -- reserved
>       -14                 => Dummy_Handler'Access,      -- NMI
>       -13                 => HardFault_Handler'Access,  -- HardFault
>       -12                 => Dummy_Handler'Access,      -- MemManagement
>       -11                 => Dummy_Handler'Access,      -- BusFault
>       -10                 => Dummy_Handler'Access,      -- UsageFault
>       -5                  => SVC_Handler'Access,        -- SVCall
>       -2                  => PendSV_Handler'Access,     -- PendSV
>       -1                  => SysTick_Handler'Access,    -- SysTick
>       others              => IRQ_Handler'Access)
>      with
>        Export,
>        Convention         => Ada,
>        External_Name      => "isr_vector";
>    pragma Linker_Section (Vectors, ".isr_vector");
> 
> and then use the linker script to place that section appropriately.
> 
The "use linker script" part is where I am having difficulty with gnat
targeting a PC. Haven't tried the STM32F4 yet.
All I've found so far, including tutorial on AdaCore, apply only to
Windows and produce errors in Linux. For example the  advice to  use
"-Xlinker -Wl --stack = ..." is Windows only.
 We may have to give up and switch back to using Makefile, which
probably isn't such a bad idea anyway.

Re: Ada in command / control systems

[Niklas Holsti]

On 19-02-27 00:10 , lyttlec wrote:
> On 2/26/19 10:50 AM, Simon Wright wrote:
>> "J-P. Rosen" <rosen@adalog.fr> writes:
>>
>>> Le 25/02/2019 à 20:21, russ lyttle a écrit :
>>
>>>> Some items need to be specified to be
>>>> allocated to EEPROM, some to RAM, etc.
>>> You can do that with address clauses.
>>
>> The compiler will straightforwardly distinguish between text, read-only,
>> read-write, and bss.
>>
>> If you need more, you can (GNAT) use pragma Linker_Section: for
>> interrupt vectors for an STM32F4,
>>
>>    Vectors : array (-14 .. Ada.Interrupts.Names.FPU_IRQ) of Handler :=
>>      (-9 .. -6 | -4 .. -3 => null,                      -- reserved
>>       -14                 => Dummy_Handler'Access,      -- NMI
>>       -13                 => HardFault_Handler'Access,  -- HardFault
>>       -12                 => Dummy_Handler'Access,      -- MemManagement
>>       -11                 => Dummy_Handler'Access,      -- BusFault
>>       -10                 => Dummy_Handler'Access,      -- UsageFault
>>       -5                  => SVC_Handler'Access,        -- SVCall
>>       -2                  => PendSV_Handler'Access,     -- PendSV
>>       -1                  => SysTick_Handler'Access,    -- SysTick
>>       others              => IRQ_Handler'Access)
>>      with
>>        Export,
>>        Convention         => Ada,
>>        External_Name      => "isr_vector";
>>    pragma Linker_Section (Vectors, ".isr_vector");
>>
>> and then use the linker script to place that section appropriately.
>>
> The "use linker script" part is where I am having difficulty with gnat
> targeting a PC. Haven't tried the STM32F4 yet.
> All I've found so far, including tutorial on AdaCore, apply only to
> Windows and produce errors in Linux.

Simon is talking about targeting embedded, bare metal platforms, where 
things like placing certain data or code in EEPROM, or at certain 
addresses, make sense. For an OS like Windows or Linux on a PC, usually 
there is no EEPROM (accessible to an application), and all special 
addreses (such as I/O control registers) are reserved for OS use.

> For example the  advice to  use
> "-Xlinker -Wl --stack = ..." is Windows only.

Yes, the way you set the stack size of the Ada environment task is 
different for each host OS (there was some discussion of this on 
comp.lang.ada a while ago, and it was agreed that a portable, standard 
method should be defined for Ada, such as using Pragma Storage_Size in 
the main subprogram).

For Linux, I believe the environment stack size is not set when linking 
the program, but through the shell "ulimit" command when starting the 
program.

> We may have to give up and switch back to using Makefile, which
> probably isn't such a bad idea anyway.

I don't see how a Makefile would help with the stack-size setting. It 
should be possible to pass all required command-line switches and 
arguments through GPS and gprbuild.

I would recommend using a Makefile only if you must run some other tools 
in connection with the build. If your build uses only gprbuild or 
gnatmake, stick with the GNAT project file, or just with the gnatmake 
environment variables (ADA_INCLUDE_PATH, ADA_OBJECTS_PATH).

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada in command / control systems

[Simon Wright]

lyttlec <lyttlec@removegmail.com> writes:

> The "use linker script" part is where I am having difficulty with gnat
> targeting a PC. Haven't tried the STM32F4 yet.
> All I've found so far, including tutorial on AdaCore, apply only to
> Windows and produce errors in Linux. For example the  advice to  use
> "-Xlinker -Wl --stack = ..." is Windows only.

gnatbind (try --help to get the full set of options) has these, which
might help. Bad idea to use these in a small MCU.

  -dnn[k|m] Default primary stack size = nn [kilo|mega] bytes
  -Dnn[k|m] Default secondary stack size = nn [kilo|mega] bytes

>  We may have to give up and switch back to using Makefile, which
> probably isn't such a bad idea anyway.

Don't see how this will help, you need to work out how to get the
compiler, binder and linker to cooperate.

I'm having a bit of trouble working out what you're trying to do. You
seem to be targeting a wide range of platforms, from Linux to embedded
MCUs. The need to control sizes etc is much less in a Unix-like
environment, and I doubt very much you'd want to use EEPROM (do you mean
that, by the way? MCUs seem to use Flash) or even bother to think about
how the linker arranges things so that the program starts up properly.

The same applies to more capable boards on the lines of the Raspberry Pi
- just another Unix-like platform.

But when it comes to MCUs like the STM32F4 with a megabyte of Flash and
128K of RAM (actually, there's another 64K of close-coupled RAM, I see)
more care is needed. A lot of this will have been looked after by
whoever provides your runtime.

Re: Ada in command / control systems

[russ lyttle]

On 2/26/19 6:09 PM, Simon Wright wrote:
> lyttlec <lyttlec@removegmail.com> writes:
> 
>> The "use linker script" part is where I am having difficulty with gnat
>> targeting a PC. Haven't tried the STM32F4 yet.
>> All I've found so far, including tutorial on AdaCore, apply only to
>> Windows and produce errors in Linux. For example the  advice to  use
>> "-Xlinker -Wl --stack = ..." is Windows only.
> 
> gnatbind (try --help to get the full set of options) has these, which
> might help. Bad idea to use these in a small MCU.
> 

>    -dnn[k|m] Default primary stack size = nn [kilo|mega] bytes
>    -Dnn[k|m] Default secondary stack size = nn [kilo|mega] bytes
> 
>>   We may have to give up and switch back to using Makefile, which
>> probably isn't such a bad idea anyway.
> 
> Don't see how this will help, you need to work out how to get the
> compiler, binder and linker to cooperate.
> 
Done that with Makefiles  on other projects. Now looking for a way to do 
it with gpr files. I don't want to give up until I'm sure that I must.

> I'm having a bit of trouble working out what you're trying to do. You
> seem to be targeting a wide range of platforms, from Linux to embedded
> MCUs. The need to control sizes etc is much less in a Unix-like
> environment, and I doubt very much you'd want to use EEPROM (do you mean
> that, by the way? MCUs seem to use Flash) or even bother to think about
> how the linker arranges things so that the program starts up properly.
> 
Should have said Flash.
Watch
https://www.youtube.com/watch?v=3jstaBeXgAs
Not my project, but you get the idea. Lots of (small) computers 
networked. Penney's count so the lowest cost mcu must be used. At least 
one device has an OS, some need a scheduler, most are bare bones. All 
are going to be pushed to the limit.  The life of the software will be 
long, even though some of the mcu might change. For example the mcu 
reporting tire air pressure might change between production runs or 
model year.
> The same applies to more capable boards on the lines of the Raspberry Pi
> - just another Unix-like platform.
We will have one or more R-Pi class devices that need a provably secure 
and correct OS. While Raspbian is much better than Windows 10, how would 
you show that it is correct?
> 
> But when it comes to MCUs like the STM32F4 with a megabyte of Flash and
> 128K of RAM (actually, there's another 64K of close-coupled RAM, I see)
> more care is needed. A lot of this will have been looked after by
> whoever provides your runtime.
The STM32F4 is one of the easy ones. Think of it as representing a class 
of target, rather than a specific target. STMicro today might be 
replaced with Freescale next year. "Whoever provides your runtime" is me.
> 

Re: Ada in command / control systems

[Niklas Holsti]

On 19-02-27 15:22 , russ lyttle wrote:
> On 2/26/19 6:09 PM, Simon Wright wrote:
>
>> I'm having a bit of trouble working out what you're trying to do. You
>> seem to be targeting a wide range of platforms, from Linux to embedded
>> MCUs. The need to control sizes etc is much less in a Unix-like
>> environment, and I doubt very much you'd want to use EEPROM (do you mean
>> that, by the way? MCUs seem to use Flash) or even bother to think about
>> how the linker arranges things so that the program starts up properly.
>>
> Should have said Flash.
> Watch
> https://www.youtube.com/watch?v=3jstaBeXgAs

Hacking automotive computers? You could have said. I suppose you are 
aiming at hack-resistant or hack-proof distributed (but closed) systems.

> Not my project, but you get the idea. Lots of (small) computers
> networked. Penney's count so the lowest cost mcu must be used.

Minimizing repeating HW costs usually means increasing the design and 
development costs. Be sure to have your balance right, especially if you 
want to push the state of the art in safety and reliability proofs. 
Having more HW resources may allow simpler SW designs that are easier to 
prove and/or validate.

> The life of the software will be long, even though some of the mcu
> might change.

Even more reason to allow margin in HW resources. You don't want to 
invest in super-optimizing your SW for a specific, minimal HW, because 
that usually reduces SW portability.

> We will have one or more R-Pi class devices that need a provably secure
> and correct OS. While Raspbian is much better than Windows 10, how would
> you show that it is correct?

So the central question is what services this "OS" should provide. 
Presumably not the full set provided by a typical Linux distro?

Even with a reduced OS, the usual approach is to partition and separate 
the critical services from the less critical services, for example using 
a "separation kernel" like Muen.

>> ... A lot of this will have been looked after by
>> whoever provides your runtime.
> "Whoever provides your runtime" is me.

Why should you provide runtimes yourself, when you can buy them from the 
Ada compiler vendors -- presumably at smaller total cost, with faster 
delivery? At most, you might yourself tailor the COTS runtimes for your 
targets.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada in command / control systems

[russ lyttle]

On 2/27/19 9:17 AM, Niklas Holsti wrote:
> On 19-02-27 15:22 , russ lyttle wrote:
>> On 2/26/19 6:09 PM, Simon Wright wrote:
>>
>>> I'm having a bit of trouble working out what you're trying to do. You
>>> seem to be targeting a wide range of platforms, from Linux to embedded
>>> MCUs. The need to control sizes etc is much less in a Unix-like
>>> environment, and I doubt very much you'd want to use EEPROM (do you mean
>>> that, by the way? MCUs seem to use Flash) or even bother to think about
>>> how the linker arranges things so that the program starts up properly.
>>>
>> Should have said Flash.
>> Watch
>> https://www.youtube.com/watch?v=3jstaBeXgAs
> 
> Hacking automotive computers? You could have said. I suppose you are 
> aiming at hack-resistant or hack-proof distributed (but closed) systems.
> 
>> Not my project, but you get the idea. Lots of (small) computers
>> networked. Penney's count so the lowest cost mcu must be used.
> 
> Minimizing repeating HW costs usually means increasing the design and 
> development costs. Be sure to have your balance right, especially if you 
> want to push the state of the art in safety and reliability proofs. 
> Having more HW resources may allow simpler SW designs that are easier to 
> prove and/or validate.
> 
>> The life of the software will be long, even though some of the mcu
>> might change.
> 
> Even more reason to allow margin in HW resources. You don't want to 
> invest in super-optimizing your SW for a specific, minimal HW, because 
> that usually reduces SW portability.
> 
>> We will have one or more R-Pi class devices that need a provably secure
>> and correct OS. While Raspbian is much better than Windows 10, how would
>> you show that it is correct?
> 
> So the central question is what services this "OS" should provide. 
> Presumably not the full set provided by a typical Linux distro?
> 
Yes

> Even with a reduced OS, the usual approach is to partition and separate 
> the critical services from the less critical services, for example using 
> a "separation kernel" like Muen.
> 
Muen might be the answer. It is SPARK and Ada. Can it target anything 
other than X86/64?
>>> ... A lot of this will have been looked after by
>>> whoever provides your runtime.
>> "Whoever provides your runtime" is me.
> 
> Why should you provide runtimes yourself, when you can buy them from the 
> Ada compiler vendors -- presumably at smaller total cost, with faster 
> delivery? At most, you might yourself tailor the COTS runtimes for your 
> targets.
> 
Yep, those are the problems we face. A big problem is convincing 
management that 40% free-board on all resources is required.
Run-time licensing fees could run into millions per year.There are lots 
of buy-vs-build discussions going on.

Re: Ada in command / control systems

[Tero Koskinen]

Hi,

russ lyttle wrote on 25.2.2019 15.50:
> There is some support for STM (thanks Simon Wright) but has  anyone 
> tried to write an Ada program for an AT Tiny?

I have done some in the past:
http://arduino.ada-language.com/tag/attiny.html
http://arduino.ada-language.com/

In short, attiny2313 is probably the smallest chip (2kB flash, 128 byte 
RAM) which makes sense for (AVR-)Ada programs.

attiny4313 (4kB flash, 256 byte RAM) has enough resources for many 
slightly more complex things.

And I haven't yet ran out of RAM/flash on atmega328p (Arduino boards) in 
my projects.

-Tero

Re: Ada in command / control systems

[russ lyttle]

On 2/25/19 2:53 PM, Tero Koskinen wrote:
> Hi,
> 
> russ lyttle wrote on 25.2.2019 15.50:
>> There is some support for STM (thanks Simon Wright) but has  anyone 
>> tried to write an Ada program for an AT Tiny?
> 
> I have done some in the past:
> http://arduino.ada-language.com/tag/attiny.html
> http://arduino.ada-language.com/
> 
> In short, attiny2313 is probably the smallest chip (2kB flash, 128 byte 
> RAM) which makes sense for (AVR-)Ada programs.
> 
> attiny4313 (4kB flash, 256 byte RAM) has enough resources for many 
> slightly more complex things.
> 
> And I haven't yet ran out of RAM/flash on atmega328p (Arduino boards) in 
> my projects.
> 
> -Tero
Great! Thanks.
I'm targeting an ATtiny85. So now I know that it is at least possible to 
do what I need to do.

Re: Ada in command / control systems

[fabien.chouteau]

On Monday, February 25, 2019 at 2:50:22 PM UTC+1, russ lyttle wrote:
> Have you noticed how many *.py files are in the Ada_Drivers_Library?

For those who don't have the time to check, there are 11 Python files in Ada_Drivers_Library vs ~800 in Ada (~1300 SLOC vs 166096)...

Re: Ada in command / control systems

[Simon Wright]

fabien.chouteau@gmail.com writes:

> On Monday, February 25, 2019 at 2:50:22 PM UTC+1, russ lyttle wrote:
>> Have you noticed how many *.py files are in the Ada_Drivers_Library?
>
> For those who don't have the time to check, there are 11 Python files
> in Ada_Drivers_Library vs ~800 in Ada (~1300 SLOC vs 166096)...

I make it 12! (as of afbe837)

Re: Ada in command / control systems

[russ lyttle]

On 3/1/19 11:58 AM, Simon Wright wrote:
> fabien.chouteau@gmail.com writes:
> 
>> On Monday, February 25, 2019 at 2:50:22 PM UTC+1, russ lyttle wrote:
>>> Have you noticed how many *.py files are in the Ada_Drivers_Library?
>>
>> For those who don't have the time to check, there are 11 Python files
>> in Ada_Drivers_Library vs ~800 in Ada (~1300 SLOC vs 166096)...
> 
> I make it 12! (as of afbe837)
> 
That's a lot of SLOC! How can we show that the Python code isn't 
inserting something into gnat that doesn't belong there? It's been done 
before.

Re: Ada in command / control systems

[fabien.chouteau]

On Friday, March 1, 2019 at 10:19:18 PM UTC+1, russ lyttle wrote:
> That's a lot of SLOC!

It is a lot of Ada SLOC indeed, we have been working hard on this project. That being said a good portion of it is generated by SVD2Ada.

> How can we show that the Python code isn't 
> inserting something into gnat that doesn't belong there? It's been done 
> before.

What are you talking about? 

Re: Ada in command / control systems

[russ lyttle]

On 3/1/19 5:32 PM, fabien.chouteau@gmail.com wrote:
> On Friday, March 1, 2019 at 10:19:18 PM UTC+1, russ lyttle wrote:
>> That's a lot of SLOC!
> 
> It is a lot of Ada SLOC indeed, we have been working hard on this project. That being said a good portion of it is generated by SVD2Ada.
> 
>> How can we show that the Python code isn't
>> inserting something into gnat that doesn't belong there? It's been done
>> before.
> 
> What are you talking about?
> 
There have been incidents where vulnerabilities in a deployed 
application were caused by unnecessary code inserted by the compiler. 
At least one was to insert a deliberate backdoor. Some were Easter eggs, 
most simple errors. Windows has lots of Easter Eggs that can be used for 
virus insertion. If the Python code can't do anything that would cause 
gnat to insert erroneous code into the application, great. Otherwise, 
the interpreter and all the modules used by the Python code must be 
qualified to prove that Python does not insert bad code. C compilers 
have been qualified many times. Some Ada compilers have been qualified. 
To my knowledge, Python interpreters have not.

Re: Ada in command / control systems

[Jesper Quorning]

On Monday, February 25, 2019 at 9:24:33 AM UTC+1, Dmitry A. Kazakov wrote:

> Because the PLC marked is dominated by vendors pushing their vendor-lock 
> solutions, e.g. Siemens.

Siemens is the Apple of the industrial world. They have to lock the hardware to keep up the quality of service.

> Another reason is the customers lacking elementary programming and 
> software design skills. They are usually technicians and electrical or 
> mechanical engineers.

I would say that software engineering is not about knowing everything about programming. it is more about not doing things which is outside your competences until you are competent enough to use the feature.

Concurrency has been done with single CPU since forever with finite state machines (FSM) and cyclic executing. The PLC is not at primitive beast. It is a platform with logs, priority scheduling, interrupt handling functionality on nearly everything from program errors to hardware errors, communication errors and you can inspect the program states on the fly (online debugging). Safety is very important as the lives and economic interests of humans are at stake.


        Jesper.

Re: Ada in command / control systems

[Maciej Sobczak]

> I would say that software engineering is not about knowing everything about programming. it is more about not doing things which is outside your competences until you are competent enough to use the feature.

This is one of the best statements I have seen.

Moreover, after spending some time in the mixed SW/HW environment, I would never assume engineers from other domains to be less competent than software engineers. On the contrary, I'm happy they they actually do not share our anti-practices and general disregard to work rigor, of which I have seen too much in software already.
Note also that software engineering world, especially in the industrial and critical domains, is slowly (?) drifting towards model-based techniques. Not only in some sense we are catching up with the culture that our colleagues from other domains cultivated long before us, but it actually makes the advantages of Ada increasingly irrelevant. The choice will be no longer between C and Ada, but rather between Python (or similar) and Simulink (or similar - I'm referring to mindsets, not the actual products).

> The PLC is not at primitive beast. [...]

I very much prefer properly designed PLC solution than some random crap disguised as source code, even in the best of languages.

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-26 10:28, Maciej Sobczak wrote:

> Note also that software engineering world, especially in the industrial and critical domains, is slowly (?) drifting towards model-based techniques.

Hmm, it was that way for 20 years.

  Not only in some sense we are catching up with the culture that our 
colleagues from other domains cultivated long before us, but it actually 
makes the advantages of Ada increasingly irrelevant. The choice will be 
no longer between C and Ada, but rather between Python (or similar) and 
Simulink (or similar - I'm referring to mindsets, not the actual products).

Not at all. Tools like Simulink reached their limit of handling 
complexity of the software. It is not scalable, not maintainable etc.

The software designed this way is not verifiable, non-testable. It is a 
huge business propped by the ways certification and validation is done. 
If you use a code generator you basically can skip most of validation if 
the generator is kind of "certified". The trick works because the model 
is not considered code.

This will end sooner or later. One can fool other people but not the 
reality.

>> The PLC is not at primitive beast. [...]
> 
> I very much prefer properly designed PLC solution than some random crap disguised as source code, even in the best of languages.

Good luck with that...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> > Note also that software engineering world, especially in the industrial and critical domains, is slowly (?) drifting towards model-based techniques.
> 
> Hmm, it was that way for 20 years.

And for 30 years the ecosystem of programming languages did not make any substantial progress, either. What is bothering me is that these mechanisms, even though acting slowly, can or already are crossing the threshold of critical mass.

> Tools like Simulink reached their limit of handling 
> complexity of the software.

This is an interesting observation. But it assumes that banging out code is an approach that did not reach such limits. Yet the notion of "big freeze" means that we have hit some limits one way or another.

> It is not scalable, not maintainable etc.

In what way it is not scalable?

> The software designed this way is not verifiable, non-testable.

I disagree. I do not see any fundamental obstacles for testing such software. There are requirements, there are inputs and there are outputs. There is nothing missing.

> If you use a code generator you basically can skip most of validation if 
> the generator is kind of "certified". The trick works because the model 
> is not considered code.

No, there is no trick. You can generate code from requirements expressed in other ways, too (and models are considered requirements for this purpose). There is nothing special in MBD that allows to skip any verification, at least with regard to DO-178C, all objectives need to be achieved.

> This will end sooner or later.

Probably. But the end of MBD will not mean coming back to coding by hand. Even if we forget about technical merits, there is just no business incentive to do so. People expect compilers to be free (like in free beer), whereas the same people still accept being charged for model-based tools. So there is no coming back.

> > I very much prefer properly designed PLC solution than some random crap disguised as source code, even in the best of languages.
> 
> Good luck with that...

I guess there are more buggy programs than dysfunctional PLCs.
I'm not sure if there are more bug-free programs than well-working PLCs.
No hard data, though, just intuition. :-)

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-26 22:25, Maciej Sobczak wrote:
>>> Note also that software engineering world, especially in the industrial and critical domains, is slowly (?) drifting towards model-based techniques.
>>
>> Hmm, it was that way for 20 years.
> 
> And for 30 years the ecosystem of programming languages did not make any substantial progress, either. What is bothering me is that these mechanisms, even though acting slowly, can or already are crossing the threshold of critical mass.

I have been expecting a collapse for a long time as more and more 
programmers were required. That should eventually bring the economy 
down. But it seems that so far things are kept in balance as other parts 
of the economy are bled to pay for software development.

>> Tools like Simulink reached their limit of handling
>> complexity of the software.
> 
> This is an interesting observation. But it assumes that banging out code is an approach that did not reach such limits. Yet the notion of "big freeze" means that we have hit some limits one way or another.

I think that problem-specific languages must necessarily have more 
problems than general purpose ones because of the problem space 
boundaries. One tinny step out and you are lost.

>> It is not scalable, not maintainable etc.
> 
> 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? Add here lack of any modularity and abstraction. 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?

>> The software designed this way is not verifiable, non-testable.
> 
> I disagree. I do not see any fundamental obstacles for testing such software. There are requirements, there are inputs and there are outputs. There is nothing missing.

How do you merge or decide if two graphs are equivalent? Complexity 
escalates as you move from simple text language, to a formatted text 
language, to a graphical language.

>> If you use a code generator you basically can skip most of validation if
>> the generator is kind of "certified". The trick works because the model
>> is not considered code.
> 
> No, there is no trick. You can generate code from requirements expressed in other ways, too (and models are considered requirements for this purpose). There is nothing special in MBD that allows to skip any verification, at least with regard to DO-178C, all objectives need to be achieved.

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.

>> This will end sooner or later.
> 
> Probably. But the end of MBD will not mean coming back to coding by hand. Even if we forget about technical merits, there is just no business incentive to do so. People expect compilers to be free (like in free beer), whereas the same people still accept being charged for model-based tools. So there is no coming back.

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

> I guess there are more buggy programs than dysfunctional PLCs.
> I'm not sure if there are more bug-free programs than well-working PLCs.
> No hard data, though, just intuition. :-)

Your intuition is correct, but that is because existing PLCs are 
incredibly primitive when compared with most simple programs. That ends 
and ends soon. A typical production line cannot be designed as a bunch 
of brain-dead PLCs anymore. Individual controllers become 
interconnected, integrated into larger enterprise subsystems. Management 
require cloud services, even more outrageously stupid ideas are in the 
pipeline. When PLC will awake from its vegetative sleep we will see.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-27 21:46, Maciej Sobczak wrote:

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

You can build blocks out of blocks. In terms of software development 
this is trivial aggregation. Modern languages have a lot more under the 
belt. How about user-defined types of edges? Groups of edges used 
together? How about parametrized blocks? Substitutability of blocks upon 
connection with other blocks and polymorphism of blocks and edges? 
Interfaces of blocks constraining implementations of?

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

Alas these solutions do not really work with networks of blocks.

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

We had a project where the customer required the HMI designed in a 
graphical language like Simulink. Once the diagram became impossible to 
read and even less to understand. We stopped using it. The biggest 
problem was missing edges. If a block misses an input how to find the 
block providing it among thousands of blocks?

Instead we took the internal representation of the diagram. It was a 
file with sections describing blocks, edges and their connections. So we 
edited that file directly!

Remember an anecdote about OS 360 which allegedly lacked most of its 
source code because people simply patched the object code instead of the 
sources? (:-))

That was our case exactly. When the patched file got loaded, it was 
rendered as an utter mess of overlapping blocks and edges leaving 
nowhere, piercing the diagram like cosmic rays. Naturally our manual 
editing destroyed the layout! The automatic rearranging tool indignantly 
crashed when faced proud results of our creativity. The diagram worked 
but nobody could see it. Nice to feel yourself IBM!

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

OK, but if you have a block of N inputs and M outputs which is supposed 
to implement some part of controller activity. In order to test it, you 
must know what kind of analytical function it represents. Engineers 
designing these blocks rather feel this stuff based on their experience 
than test like we used to test normal software.

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

So if Ada were used to generate Simulink blocks, the roles would change?

In my view the level is determined not by artifacts of software design 
process but by the abstraction level and closeness to the domain in the 
sense how many errors can slip through. If the language of the model is 
less safe/obvious than the object language then it makes no sense to use 
it, because it is effectively lower level then.

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

SPARK rules!

> But nobody cares. Get ready for MBD.

Always ready! MBD was a hype already in late 90's. Remember OOA&D? Code 
generated from class diagrams? This wave will not be that big. 
Especially because there are rivals on the market of snake oil sellers, 
the AI is back! I expect mission critical software written in the form 
of trained NN! (:-))

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

Yes, for a while. But you and I have suspicion that this is not really 
sustainable.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> You can build blocks out of blocks. In terms of software development 
> this is trivial aggregation. Modern languages have a lot more under the 
> belt.

And a lot of coding and design standards saying what not to use. :-)

> How about user-defined types of edges? [...]

This is thinking in terms of solution, not in terms of a problem.
Why would I care about features that are borrowed from code-based programming languages in a model-based tool, without a particular problem to solve?

> Groups of edges used 
> together? How about parametrized blocks? Substitutability of blocks upon 
> connection with other blocks and polymorphism of blocks and edges? 
> Interfaces of blocks constraining implementations of?

I don't see any reason why a model-based tool should not have them. But I also don't see any reason to have them unless I have a problem where they are needed.

> We had a project where the customer required the HMI designed in a 
> graphical language like Simulink. Once the diagram became impossible to 
> read and even less to understand. We stopped using it.

Yet, that will not prevent the same customer asking for it again. Guess how do I know.

> The biggest 
> problem was missing edges. If a block misses an input how to find the 
> block providing it among thousands of blocks?

Which is exactly the same problem as with source code. If the information is missing, you have to figure out where to get it from (among thousands of source modules, of course, no less).

> Instead we took the internal representation of the diagram. It was a 
> file with sections describing blocks, edges and their connections. So we 
> edited that file directly!

Yes, Tcl makes it possible. Which might be actually a proof that model-based approach can be a safe choice if such a rescue option exists.
Having said that, I have also seen a tool that used XML as an underlying format, where everything was "linked" by means of UUID identifiers, woven as attributes in absolutely every entity. I think that character-wise, these UUIDs made a majority of the file content. Even though it was formally still a text file, modifications by hand were just impossible. So, it all depends on the tool vendor. But this is certainly something to look into at tool evaluation time.

> When the patched file got loaded, it was 
> rendered as an utter mess of overlapping blocks and edges leaving 
> nowhere, piercing the diagram like cosmic rays. Naturally our manual 
> editing destroyed the layout! The automatic rearranging tool indignantly 
> crashed when faced proud results of our creativity. The diagram worked 
> but nobody could see it.

Interesting story about a particular low-quality tool, saying nothing whatsoever about the approach as a whole. There are anecdotes about buggy compilers and incomprehensible sources as well.

> OK, but if you have a block of N inputs and M outputs which is supposed 
> to implement some part of controller activity. In order to test it, you 
> must know what kind of analytical function it represents.

And in what way is it worse from source code?

> So if Ada were used to generate Simulink blocks, the roles would change?

For the sake of argument, you might also generate Ada source from assembly.
But I doubt it would impress the actual stakeholders.

> In my view the level is determined not by artifacts of software design 
> process but by the abstraction level

Yes, and this is determined by the fact that you can provide *various* lower-level implementations/refinements of higher-level requirements, thus leaving some space for engineering work and decision making on the way. As long as models don't constrain the underlying implementation (source) in a way that would make them 1:1 equivalent, they are considered to be higher-level than source. This is how models are used, although there is also a place and market for visualization tools that generate diagrams from code.

> Always ready! MBD was a hype already in late 90's. Remember OOA&D?

Yes, and it didn't go anywhere.
Or maybe the enterprise folks, who where fond of UML at that time are now all gone "agile". But in general, OOA&D is still alive and kicking, especially in the industrial applications.

> Code 
> generated from class diagrams?

Yep.

> Especially because there are rivals on the market of snake oil sellers, 
> the AI is back! I expect mission critical software written in the form 
> of trained NN! (:-))

Yes, let's fasten our seatbelts. But in the context of this discussion, this is not a rival, it is *another*, *additional* reason to forget about hand-coded sources. It's not like MBD will lose. It's really one more reason for companies not to write source code. The source code will lose, because there will be even more ways not to write it.

> Yes, for a while. But you and I have suspicion that this is not really 
> sustainable.

In a sense you are right, it's all pile of shit. But still, there is no coming back. People are really determined to invent all kind of necessary shit, as long as it saves them from writing code. And this is what bothers me.

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-28 14:12, Maciej Sobczak wrote:
> 
>> You can build blocks out of blocks. In terms of software development
>> this is trivial aggregation. Modern languages have a lot more under the
>> belt.
> 
> And a lot of coding and design standards saying what not to use. :-)
> 
>> How about user-defined types of edges? [...]
> 
> This is thinking in terms of solution, not in terms of a problem.
> Why would I care about features that are borrowed from code-based programming languages in a model-based tool, without a particular problem to solve?

How would I pass a complex input to a block, a matrix, user credentials?

>> Groups of edges used
>> together? How about parametrized blocks? Substitutability of blocks upon
>> connection with other blocks and polymorphism of blocks and edges?
>> Interfaces of blocks constraining implementations of?
> 
> I don't see any reason why a model-based tool should not have them. But I also don't see any reason to have them unless I have a problem where they are needed.

The problem is software decomposition and reuse. Simulink's is an ultra 
low-level language, lower than assembler, IMO. All its constructs are 
used literally.

>> The biggest
>> problem was missing edges. If a block misses an input how to find the
>> block providing it among thousands of blocks?
> 
> Which is exactly the same problem as with source code. If the information is missing, you have to figure out where to get it from (among thousands of source modules, of course, no less).

That is why the general purpose languages support modules, packages 
scoping, visibility and lots of other means Simulink does not have. It 
was a long way from global variables and gotos to the techniques used in 
modern language. Simulink is in the square one.

>> Instead we took the internal representation of the diagram. It was a
>> file with sections describing blocks, edges and their connections. So we
>> edited that file directly!
> 
> Yes, Tcl makes it possible. Which might be actually a proof that model-based approach can be a safe choice if such a rescue option exists.

Any approach would be safe from this point view.

> Having said that, I have also seen a tool that used XML as an underlying format, where everything was "linked" by means of UUID identifiers, woven as attributes in absolutely every entity. I think that character-wise, these UUIDs made a majority of the file content. Even though it was formally still a text file, modifications by hand were just impossible. So, it all depends on the tool vendor. But this is certainly something to look into at tool evaluation time.

Yes, you need a finer measure instrument to judge complexity.

>> When the patched file got loaded, it was
>> rendered as an utter mess of overlapping blocks and edges leaving
>> nowhere, piercing the diagram like cosmic rays. Naturally our manual
>> editing destroyed the layout! The automatic rearranging tool indignantly
>> crashed when faced proud results of our creativity. The diagram worked
>> but nobody could see it.
> 
> Interesting story about a particular low-quality tool, saying nothing whatsoever about the approach as a whole.

You mean Simulink has a better diagnostics? The diagnostics is as good 
as the language is. Ada has better diagnostics than C because of the 
language properties.

>> OK, but if you have a block of N inputs and M outputs which is supposed
>> to implement some part of controller activity. In order to test it, you
>> must know what kind of analytical function it represents.
> 
> And in what way is it worse from source code?

I can have specifications and can decompose a problem into testable 
units. Methods used in control, like process identification, are very 
different. If you don't believe in OO analysis you would agree that 
there is more than one method to model reality. The general purpose 
language offers much more freedom of modeling the problem space entities 
through language constructs than the domain-specific ones.

>> In my view the level is determined not by artifacts of software design
>> process but by the abstraction level
> 
> Yes, and this is determined by the fact that you can provide *various* lower-level implementations/refinements of higher-level requirements, thus leaving some space for engineering work and decision making on the way. As long as models don't constrain the underlying implementation (source) in a way that would make them 1:1 equivalent, they are considered to be higher-level than source.

That is not enough to be higher level. The variance must have some 
meaning to the problem space and to the implementation. Otherwise you 
could always reverse roles of the meta and object languages. This 
(abstraction inversion) happens all the time, e.g. when an application 
level protocol is used as a transport etc.

> Yes, and it didn't go anywhere.
> Or maybe the enterprise folks, who where fond of UML at that time are now all gone "agile". But in general, OOA&D is still alive and kicking, especially in the industrial applications.

In my experience OOA&D is dead and buried. None of our customers 
mentioned in for more than a decade. As for "agile", yes, it is still a 
hype. Though it degraded to rather a formality, void of its original 
malice. If you have nightly builds, you are "agile" and everybody is happy.

> Yes, let's fasten our seatbelts. But in the context of this discussion, this is not a rival, it is *another*, *additional* reason to forget about hand-coded sources. It's not like MBD will lose. It's really one more reason for companies not to write source code. The source code will lose, because there will be even more ways not to write it.

But the point is that source code is still there. They only pretend that 
there is none and reality check is around the corner.

>> Yes, for a while. But you and I have suspicion that this is not really
>> sustainable.
> 
> In a sense you are right, it's all pile of shit. But still, there is no coming back. People are really determined to invent all kind of necessary shit, as long as it saves them from writing code. And this is what bothers me.

They can keep on inventing more and more bizarre forms of "non-code" to 
write, that will not make it work.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> How would I pass a complex input to a block, a matrix, user credentials?

I think it has aggregate signals (or buses), even with multiple levels of nesting. That is, what looks like a single line on the screen can be an aggregate of multiple values, even other aggregates.

> The problem is software decomposition and reuse. Simulink's is an ultra 
> low-level language, lower than assembler, IMO.

Then let's stop talking about Simulink. Since the beginning, I'm stressing that it's not Simulink vs. Ada, it's rather MBD vs. source code. That is, don't argue that MBD does not work just because Simulink does not have your pet feature.

> You mean Simulink has a better diagnostics?

You have complained that it crashed after you have hacked its files by hand. Well, I can imagine that some of its later versions might not crash after such abuse. Or that some other tool would not crash. If your argument against MBD depends on some particular tool version crashing, then it's a poor argument. I have crashed compilers, too.

> In my experience OOA&D is dead and buried. None of our customers 
> mentioned in for more than a decade.

Good to know.

> They can keep on inventing more and more bizarre forms of "non-code" to 
> write, that will not make it work.

Then they will keep inventing. Compilers, libraries and frameworks are now free, which makes them kind of hobby thing. There is no business incentive to come back to source code, so companies will do their best to keep us from writing it.

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-01 10:22, Maciej Sobczak wrote:
>> How would I pass a complex input to a block, a matrix, user credentials?
> 
> I think it has aggregate signals (or buses), even with multiple levels of nesting. That is, what looks like a single line on the screen can be an aggregate of multiple values, even other aggregates.

The problem is with the operations. You might be able to aggregate but 
not operate these aggregates as entities of the corresponding semantics.

And of course there is an even larger problem on the horizon: the code 
generator. You need to put down and numerically solve a system of 
differential equations corresponding to the diagram.

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

>> The problem is software decomposition and reuse. Simulink's is an ultra
>> low-level language, lower than assembler, IMO.
> 
> Then let's stop talking about Simulink. Since the beginning, I'm stressing that it's not Simulink vs. Ada, it's rather MBD vs. source code. That is, don't argue that MBD does not work just because Simulink does not have your pet feature.

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. My suspicion is that 
there cannot be such thing as a unified model language, in some strong 
fundamental way.

>> You mean Simulink has a better diagnostics?
> 
> You have complained that it crashed after you have hacked its files by hand. Well, I can imagine that some of its later versions might not crash after such abuse. Or that some other tool would not crash. If your argument against MBD depends on some particular tool version crashing, then it's a poor argument. 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 have to break out of the 
model abstraction and write a lot around it in order to make that puny 
model work.

>> They can keep on inventing more and more bizarre forms of "non-code" to
>> write, that will not make it work.
> 
> Then they will keep inventing. Compilers, libraries and frameworks are now free, which makes them kind of hobby thing. There is no business incentive to come back to source code, so companies will do their best to keep us from writing it.

There is no any business involved because the software product itself is 
"free". But there is a strong trend to end this. Companies cannot claim 
software free of any liability anymore. Even giants like Facebook and 
Amazon get charged. 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> 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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-04 08:03, Maciej Sobczak wrote:

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

Rather incompleteness and/or lack of usability.

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

Nothing of these could not be written in Ada in a better and safer way. 
Simulink is a different case. And remember that the starting point of 
the discussion was not merits of a given language. Ada and C share same 
paradigm. C and Simulink is a paradigm change.

> Actually, Ada would be dead already if this possibilities did not exist. Same with modeling.

It would not be Ada if it could not this.

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

Everything has its limits, the difference is where these limits are.

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

You have a huge system integration problems caused by language 
impedance, which becomes impossible when you have to connect models from 
different paradigms. You must break out of one model go to a reasonable 
language and then re-enter into yet another model.

Better. This debunks the whole argument about pseudo-requirements. How 
can you write requirements in a model language bounds of which 
applicability and the role in the whole system is unknown? You must have 
another set of requirements at least to tell which parts of the system 
to be modeled in which modeling language and then what about all the 
places in-between?

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

The original problem was not crashing but maintainability. It was 
impossible to modify the diagram and fix errors in it. Crashing came later.

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

Python in GPS is a GPS issue. I don't use Python, I use Ada. The point 
was that you could not use Simulink for most of elementary programming 
tasks. Whatever Python can, Ada can better.

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

You compare dynamically typed interpreters with domain-specific 
languages. I compare general purpose languages with domain-specific 
ones. Nothing is broken when you call C from Ada, except for special 
cases which illustrate the point. E.g. if you used C for handling Ada 
exceptions or Ada's protected types. Then you would face model breaking 
and all consequences of. And no, this is not normal practice to do. 
Otherwise you are within the model.

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

MathWorks does not sell planes. In this scenario if a vendor (e.g. 
Airbus) will be made liable, if tools will offer no legal protection, it 
will likely reconsider deployment of these. Presently tools play a huge 
role in avoiding liability.

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

They do not believe, they know for sure that certain tools are an easy 
path to certification. And my observation is that the West moves away 
from legalism. Whatever law and norms may say, people and companies are 
made liable. So the safety might be imaginary.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> Rather incompleteness and/or lack of usability.

But why do you expect a single tool to be complete, if we can get completeness from the combination of tools? From what G.B. wrote in a sibling post, it looks like source code alone is not complete and usable in some contexts, either.

> > Actually, Ada would be dead already if this possibilities did not exist. Same with modeling.
> 
> It would not be Ada if it could not this.

But nobody would like to do it. So everybody accepts technology mixes for the sake of work efficiency. That's why nobody complains about s-functions, it just looks like any other mix.

> You have a huge system integration problems caused by language 
> impedance

No. This integration happens at a lower scale, so it is not a system problem. I can call s-function written in C (or Ada!) form the Simulink model without much concern about language impedance. I think that calling Ada functions from Python is more involved, even though they share paradigms.

> which becomes impossible when you have to connect models from 
> different paradigms. You must break out of one model go to a reasonable 
> language and then re-enter into yet another model.

And what can prevent me from doing it? If I call C functions from Ada, the integration is actually happening at the object level (by linker, not by compiler), because these languages do not much care about each other. So I need to go outside to glue things together. That is, if I need to stitch things at a level that is outside of my normal area of operation, then why I should worry about doing exactly the same with models? It is the same thing.

> Better. This debunks the whole argument about pseudo-requirements. How 
> can you write requirements in a model language bounds of which 
> applicability and the role in the whole system is unknown?

Making this judgement is the responsibility of person doing tool evaluation. Experience with previous projects helps.

> Presently tools play a huge 
> role in avoiding liability.

This is also a good reason why they are not likely to disappear. Again, there is no coming back to source code.

> And my observation is that the West moves away 
> from legalism. Whatever law and norms may say, people and companies are 
> made liable. So the safety might be imaginary.

This is an interesting observation, and perhaps related to the bigger notion of change that is slowly happening. But still, it has nothing to do with model-based engineering.

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-05 10:33, Maciej Sobczak wrote:
>> Rather incompleteness and/or lack of usability.
> 
> But why do you expect a single tool to be complete, if we can get completeness from the combination of tools?

Because the tool is claimed to state the "requirements". There can be 
nothing above that.

> From what G.B. wrote in a sibling post, it looks like source code alone is not complete and usable in some contexts, either.

The source code is complete per definition, otherwise you could not 
compile and build the solution from it.

> But nobody would like to do it. So everybody accepts technology mixes for the sake of work efficiency.

My point was that the technology is basically same.

> That's why nobody complains about s-functions, it just looks like any other mix.

Apart from the issue of being "requirement" rather than code, the 
difference is technical impossibility to implement things in Simulik on 
one side and mere reuse of existing components on another.

>> You have a huge system integration problems caused by language
>> impedance
> 
> No. This integration happens at a lower scale, so it is not a system problem. I can call s-function written in C (or Ada!) form the Simulink model without much concern about language impedance.

There are lots of concerns when calling s-function, e.g. when the block 
containing this function is in the feedback loop. Models are extremely 
fragile. Using s-functions is like throwing arbitrary assembler 
insertions into Ada code. When you couple two models from two different 
frameworks what would be the effect? Programming languages have means 
for proper encapsulation and insulation the side effects. 
Domain-specific languages have nothing of this sort.

> I think that calling Ada functions from Python is more involved, even though they share paradigms.
> 
>> which becomes impossible when you have to connect models from
>> different paradigms. You must break out of one model go to a reasonable
>> language and then re-enter into yet another model.
> 
> And what can prevent me from doing it? If I call C functions from Ada, the integration is actually happening at the object level (by linker, not by compiler), because these languages do not much care about each other.

It is the same paradigm and after a half of century we more or less know 
how to write reusable components in C and Ada.

>> Better. This debunks the whole argument about pseudo-requirements. How
>> can you write requirements in a model language bounds of which
>> applicability and the role in the whole system is unknown?
> 
> Making this judgement is the responsibility of person doing tool evaluation. Experience with previous projects helps.

I am talking about the architecture. The requirement telling not to 
implement the client DB in Simulink are written in Simulink?

> This is an interesting observation, and perhaps related to the bigger notion of change that is slowly happening. But still, it has nothing to do with model-based engineering.

It has to do with how much of free space is left for using garbage 
paradigms that have no technical merits.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> Because the tool is claimed to state the "requirements". There can be 
> nothing above that.

What do you mean "nothing above that"? There can be many levels of requirements. Simulink (and such) is typically used at the level called Low Level Requirements (LLR for short). There is *a lot* above that. There might be even other models above that. And Simulink might not be the only thing used at its level, or not for all artifacts.
The notion that the model is still at the level of requirements comes from the fact that a programmer might pick the model and write code from it, contributing perhaps from his experience and technical expertise. The fact that there are people who don't understand the source code but are still comfortable looking at the diagram means that there is some abstraction in it ("useful lie" - a very good term). The fact that Simulink can generate code automatically is actually not important here, because that functionality need not be used - which, interestingly, makes your arguments about s-functions irrelevant. The s-functions might be just dummy blocks and as long as the programmer understands what should be provided in their place, the diagram as a whole is still useful. It might be even used for formal reasoning about some of the system properties.
Of course, the concept can be also misused. Which might even happen more often than we would like. But this would not be an argument against models, rather against our lack of skills in using them.

> The source code is complete per definition, otherwise you could not 
> compile and build the solution from it.

Which also means that it is the lowest level representation of the system that we should care about. The question is, whether it is the only representation that we need. If we need something above that, what it should be?

> There are lots of concerns when calling s-function, e.g. when the block 
> containing this function is in the feedback loop.

Sure, and there are concerns about source code being reentrant or not, or being thread-safe or not, or being exception-safe or not, or being recursive when it should not be, and so on. It's not like source is concern-free.

> Models are extremely 
> fragile.

So is source. So much that people believe it makes sense not to write it.

> Programming languages have means 
> for proper encapsulation and insulation the side effects. 
> Domain-specific languages have nothing of this sort.

Why? I see no reason why they should not have it.

> It is the same paradigm and after a half of century we more or less know 
> how to write reusable components in C and Ada.

And you have the whole libraries (built-in and COTS) of reusable modules or operators in Simulink (and similar), too. People just drag'n'drop filters, amplifiers, counters, and whatever other stuff they need into their projects and it seems to work. Why should they come back to source?

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-06 10:05, Maciej Sobczak wrote:
>> Because the tool is claimed to state the "requirements". There can be
>> nothing above that.
> 
> What do you mean "nothing above that"? There can be many levels of requirements. Simulink (and such) is typically used at the level called Low Level Requirements (LLR for short). There is *a lot* above that. There might be even other models above that. And Simulink might not be the only thing used at its level, or not for all artifacts.

Thus it is simply code in some mostly declarative language. As such it 
must undergo testing, verification, validation etc.

> The fact that Simulink can generate code automatically is actually not important here,

It is a key feature allowing to circumvent normal software quality 
assertion and developing process.

> because that functionality need not be used - which,

I don't think there are many people who could write code from a 
non-trivial Simulink diagram. It is far more difficult than writing 
assembler code from Ada program.

>> The source code is complete per definition, otherwise you could not
>> compile and build the solution from it.
> 
> Which also means that it is the lowest level representation of the system that we should care about. The question is, whether it is the only representation that we need. If we need something above that, what it should be?

The question is the purpose of? For example, the purpose of writing pay 
checks for the developers team. Certainly you might have something 
useful for that. Or something more close, getting the top managers off 
the back of developers. Some PPT presentation would be of great help. 
You should state the purpose first.

>> There are lots of concerns when calling s-function, e.g. when the block
>> containing this function is in the feedback loop.
> 
> Sure, and there are concerns about source code being reentrant or not, or being thread-safe or not, or being exception-safe or not, or being recursive when it should not be, and so on. It's not like source is concern-free.

This is not comparable. When writing code in a normal language 
programmers know the limitation of the mental model they use, e.g. 
single thread of control, ignored side effects on the CPU, on memory, on 
peripheral states, time sharing etc. There are lots of red lines and 
alarm bells each competent programmer knows. With Simulink models and 
black boxes of s-functions nobody knows anything. Moreover, nobody is 
competent as the proclaimed purpose of all exercise was: any moron can 
design quality software in Simulink knowing nothing about programming. 
But that is a blatant lie. One must know everything about programming, 
control, about numeric methods, and about domain-space problem in order 
to use Simulink en large.

>> Programming languages have means
>> for proper encapsulation and insulation the side effects.
>> Domain-specific languages have nothing of this sort.
> 
> Why? I see no reason why they should not have it.

Because they do not focus on software design, but rather on the domain. 
General-purpose languages address software design problems and design 
artifacts as well as second-order problems arising from solutions of the 
first-order ones. These issues are absent in the problem space. There is 
no way to map the problem space into a finite state machine with a full 
load of other constraints. If we could we would not need programmers at all.

>> It is the same paradigm and after a half of century we more or less know
>> how to write reusable components in C and Ada.
> 
> And you have the whole libraries (built-in and COTS) of reusable modules or operators in Simulink (and similar), too. People just drag'n'drop filters, amplifiers, counters, and whatever other stuff they need into their projects and it seems to work. Why should they come back to source?

Because a large software system cannot be built this way. It is way too 
low-level. The filter corresponds to an algorithm like bubble sort. You 
come nowhere with only that sort of things in a normal language without 
a huge language machinery of all sorts of polymorphism, substitutability 
checks, modularity support etc.

BTW. A classic example with filters is changing filter parameters. You 
do it in Simulink and the roller dynamometer goes to the ground, race 
condition.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> > What do you mean "nothing above that"? There can be many levels of requirements. [...]

> Thus it is simply code in some mostly declarative language. As such it 
> must undergo testing, verification, validation etc.

No, it's not code. It's requirements. Yes, in undergoes verification. Which is actually good - I don't understand, are you now criticizing models for them being verified?

> > The fact that Simulink can generate code automatically is actually not important here,
> 
> It is a key feature allowing to circumvent normal software quality 
> assertion and developing process.

I don't understand this statement (maybe we are running out of fuel in this discussion). Models are used to express ideas and expectations. Whether there is a code generation involved is a secondary issue. You might as well say that automatic soldering of electronics elements from electric diagrams is a key feature of the modeling tool. Yet I have never seen it happen (nor even attempted).

> I don't think there are many people who could write code from a 
> non-trivial Simulink diagram.

Great, we are now focusing on some added value. So let's remove Simulink from the process and we have what? The customer asking for a product. How is that any better? Are there many people who could write code from a non-trivial customer expectation? The models exist to replace that single long jump with two (or more) smaller jumps, presumably easier to follow, trace, and verify. Even if the model is used only to shake out and improve the original requirements, without any code involved on the way, that's already good.

> It is far more difficult than writing 
> assembler code from Ada program.

Then maybe the intellectual gap is still too wide. And that only confirms my previous statements: source code is the lowest-level artifact we should care about (assembler can be written by a machine). Moving from requirements to source requires intellectual contribution from the expert and automating that part is not necessarily easy or desired (but still interesting).

> The question is the purpose of? For example, the purpose of writing pay 
> checks for the developers team. Certainly you might have something 
> useful for that. Or something more close, getting the top managers off 
> the back of developers. Some PPT presentation would be of great help. 
> You should state the purpose first.

I did. The purpose is to reduce the gap that is to be covered by a single engineering activity. Writing source code while listening to the customer over the phone does not work, so let's try to create something intermediary to provide opportunity to verify that our understanding of the high-level requirements are correct and that there is an idea for actual implementation that is feasible and has desired properties. This is exactly the purpose of the low-level model.

> This is not comparable. When writing code in a normal language 
> programmers know the limitation of the mental model they use

I've seen evidence for the contrary. And I've also seen perfect programs that do not fulfill the original requirements, and were therefore useless. So there is something missing.

> There are lots of red lines and 
> alarm bells each competent programmer knows.

I presume that a competent modeler knows a thing, too.

> Moreover, nobody is 
> competent as the proclaimed purpose of all exercise was: any moron can 
> design quality software in Simulink knowing nothing about programming.

I have never said anything like this. Actually, I believe that the effective use of modeling requires expertise that a typical coder does not have.
 
> One must know everything about programming, 
> control, about numeric methods, and about domain-space problem in order 
> to use Simulink en large.

So Simulink is bad, because you have to be competent? That's a really poor criticism of modeling.
I'm asking whether the process can benefit from the presence of such tools. I'm ready to acquire the competencies that I lack, if needed.

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-07 08:02, Maciej Sobczak wrote:
>>> What do you mean "nothing above that"? There can be many levels of requirements. [...]
> 
>> Thus it is simply code in some mostly declarative language. As such it
>> must undergo testing, verification, validation etc.
> 
> No, it's not code. It's requirements. Yes, in undergoes verification. Which is actually good - I don't understand, are you now criticizing models for them being verified?
> 
>>> The fact that Simulink can generate code automatically is actually not important here,
>>
>> It is a key feature allowing to circumvent normal software quality
>> assertion and developing process.
> 
> I don't understand this statement (maybe we are running out of fuel in this discussion). Models are used to express ideas and expectations.

A model is an object representing another object usually from another 
space so, that the former has the features of interest of the latter.

> Whether there is a code generation involved is a secondary issue.

It was your thesis that people want to avoid writing code, which I agree 
with. Remove that and the bureaucratic incentives, and nobody would ever 
use it.

>> I don't think there are many people who could write code from a
>> non-trivial Simulink diagram.
> 
> Great, we are now focusing on some added value. So let's remove Simulink from the process and we have what?

I never proposed that. Simulink has its place in engineering.

BTW, we are actually talking about the real-time workshop, Simulink 
generates no code, it does off-line simulation.

The discussion was about the place and whether the paradigm of using a 
domain-specific language to express models of the software system (note 
the difference) may work. It cannot.

>> It is far more difficult than writing
>> assembler code from Ada program.
> 
> Then maybe the intellectual gap is still too wide. And that only confirms my previous statements: source code is the lowest-level artifact we should care about (assembler can be written by a machine). Moving from requirements to source requires intellectual contribution from the expert and automating that part is not necessarily easy or desired (but still interesting).

You ignore here software design. The problem and the point is that the 
software systems (and models of) are far more complex than the models of 
physical processes these systems are supposed to control/automate. Tools 
and ideas like Simulink come from the era when it was the opposite. Then 
you had a 8-bit microcontroller with a few soldered in AD/DC converters. 
That was all. You had a nice way to design, test and deploy a control 
loop. That time is gone.

> I did. The purpose is to reduce the gap that is to be covered by a single engineering activity. Writing source code while listening to the customer over the phone does not work, so let's try to create something intermediary to provide opportunity to verify that our understanding of the high-level requirements are correct and that there is an idea for actual implementation that is feasible and has desired properties. This is exactly the purpose of the low-level model.

This is not a purpose, it is a desired feature of the code writing 
process. The purpose is fulfilled by writing the code. You want to write 
the code in a different language? Fine, but do not tell me you are 
writing no code.

>> One must know everything about programming,
>> control, about numeric methods, and about domain-space problem in order
>> to use Simulink en large.
> 
> So Simulink is bad, because you have to be competent?

No, Simulink is bad when you try to use it where it does not belong, 
i.e. for software development.

> That's a really poor criticism of modeling.

BTW, the customers I know do not deploy the code generated by the 
real-time workshop. The code (in C) is manually rewritten and reviewed. 
Yes, one must have the worst from both worlds!

> I'm asking whether the process can benefit from the presence of such tools. I'm ready to acquire the competencies that I lack, if needed.

It cannot. Any extra layer of languages increases complexity 
exponentially. Argumentation that these language are not for code, but 
for requirements etc is bogus. BTW, if Simulink et al were used as SPARK 
is used, I would have no objection.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> A model is an object representing another object usually from another 
> space so, that the former has the features of interest of the latter.

So is this good or bad?

> > Whether there is a code generation involved is a secondary issue.
> 
> It was your thesis that people want to avoid writing code, which I agree 
> with. Remove that and the bureaucratic incentives, and nobody would ever 
> use it.

Not really. I see it being used both ways. There are two interesting cases to consider:

1. You want to save your programmers from writing code. Generating code from models is a possible way to do it.

2. You want to (or are obliged to) introduce something in between the high-level requirements and the actual implementation, for validation of design assumptions. There is no need to generate code to achieve this, but if the domain is appropriate, why not.

I've seen both, in their good and bad versions. I'm interested in the good ones.

> The discussion was about the place and whether the paradigm of using a 
> domain-specific language to express models of the software system (note 
> the difference) may work. It cannot.

I don't see why it cannot, but we might be using different definitions of "domain-specific". For me Simulink is not domain-specific. Neither is UML or state diagrams or whatever. These notations are perspective-specific (and not every perspective is useful for every system), not domain-specific.
I don't see why using a notation that focuses for example on state transitions cannot work for expressing some aspects of the software system. Maybe we have a terminology mismatch here.

> You ignore here software design. The problem and the point is that the 
> software systems (and models of) are far more complex than the models of 
> physical processes these systems are supposed to control/automate. Tools 
> and ideas like Simulink come from the era when it was the opposite. Then 
> you had a 8-bit microcontroller with a few soldered in AD/DC converters. 
> That was all. You had a nice way to design, test and deploy a control 
> loop. That time is gone.

This is an interesting observation, but nothing forces me to use Simulink to cover the whole system. I can use it to model some chosen aspect or function, using some other notation for expressing design at a different level or perspective.

> This is not a purpose, it is a desired feature of the code writing 
> process. The purpose is fulfilled by writing the code. You want to write 
> the code in a different language? Fine, but do not tell me you are 
> writing no code.

Good, this is valid observation, but I can still want to do it. The reason is that different languages might introduce different challenges (who new?) and I might want to pick the language that is more effective with regard to team competencies and the problem at hand. That is, by using a different language/notation engineers can avoid some types of problems. You know, - the same argument that Ada is better than C might also work between Simulink and C. And if Simulink (or whatever else) can prevent coders from making array overruns or memory leaks, then this is the added value.
You would say it is still writing code (and in this context I would agree). But managers will say that it is not writing code (and in the context of not writing bugs in C, they would be right, too). In either case, there is added value in not writing bugs in C, so everybody is right here. :-)

> No, Simulink is bad when you try to use it where it does not belong, 
> i.e. for software development.

Tool evaluation is an important part of project planning.

And what if software development is actually not needed to achieve the project's goals? Maybe, you know, it's our affinity to source code that suggests us that whatever we need to do, there must be software development involved? Our perception can be distorted by our personal passions - if the only thing you know is a hammer... this kind of thing. But what if we are just wrong?
Writing source code for fun is not necessarily what the customer wants to pay for.

What if my client wants something that can be done in Simulink? The argument that Simulink cannot be used for software development is then irrelevant, even if software development itself could be (and perhaps frequently is) abused to do the work.

That is, I can do everything in software, but it does not mean that I should.

> BTW, the customers I know do not deploy the code generated by the 
> real-time workshop. The code (in C) is manually rewritten and reviewed. 
> Yes, one must have the worst from both worlds!

Yes. Still, there can be added value here: the simulations allowed to validate the design ideas. Then the coding follows the path that is already verified to be safe.

> Any extra layer of languages increases complexity 
> exponentially.

I disagree. The extra layer can guide the choices at another layer, thus reducing the space at that other layer.
And, if you need to have something at an intermediary level to understand what you are doing, then it means that the complexity is part of the problem and cannot be reduced.

> BTW, if Simulink et al were used as SPARK 
> is used, I would have no objection.

Then, with all the lessons learned from past projects, let's do it.

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-08 08:19, Maciej Sobczak wrote:
>> A model is an object representing another object usually from another
>> space so, that the former has the features of interest of the latter.
> 
> So is this good or bad?

It is how it is.

>>> Whether there is a code generation involved is a secondary issue.
>>
>> It was your thesis that people want to avoid writing code, which I agree
>> with. Remove that and the bureaucratic incentives, and nobody would ever
>> use it.
> 
> Not really. I see it being used both ways. There are two interesting cases to consider:
> 
> 1. You want to save your programmers from writing code. Generating code from models is a possible way to do it.

If you have adequate software models, you could. Unfortunately there are 
no better models of this kind than the constructs offered by 
higher-level programming languages. Nothing of that is relevant to 
Simulink, which is to model a narrow class physical objects.

> 2. You want to (or are obliged to) introduce something in between the high-level requirements and the actual implementation, for validation of design assumptions.

Why introducing another language between the language of requirements 
and the language of software implementation could validate anything?

> There is no need to generate code to achieve this, but if the domain is appropriate, why not.

There always is. Any language translates into some code. You want to say 
that there is no any material or usable code to generate from that. 
Well, I would agree. The language of requirements generates code in the 
heads of people reading the requirements. So long the code is immaterial 
all this is more or less literary exercise.

> I don't see why using a notation that focuses for example on state transitions cannot work for expressing some aspects of the software system. Maybe we have a terminology mismatch here.

Because "some aspects" is not enough. In order to design software the 
language must express all important aspects.

> ... nothing forces me to use Simulink to cover the whole system. I can use it to model some chosen aspect or function, using some other notation for expressing design at a different level or perspective.

Then it is not software design in capital letters, just an 
implementation of some minor sub-component. We could spare all that 
model-based software design nonsense talk for managers.

> I might want to pick the language that is more effective with regard to team competencies and the problem at hand. That is, by using a different language/notation engineers can avoid some types of problems. You know, - the same argument that Ada is better than C might also work between Simulink and C. And if Simulink (or whatever else) can prevent coders from making array overruns or memory leaks, then this is the added value.

It is very very old idea, you know. It was in the air long before Ada 
Let's have a [domain-]specific language for each problem. E.g. LISP was 
considered a language to manipulate lists. SNOBOL was for string 
processing. FORTRAN for scientific calculations. COBOL for business 
software. JCL for batch processing etc. The idea proved to be wrong, 
which is why PL/1 and Ada were designed. It is still a wrong idea, just 
every new generation is damned to repeat errors of their fathers.

> And what if software development is actually not needed to achieve the project's goals? Maybe, you know, it's our affinity to source code that suggests us that whatever we need to do, there must be software development involved? Our perception can be distorted by our personal passions - if the only thing you know is a hammer... this kind of thing. But what if we are just wrong?

I don't see how it could be otherwise. The factors precluding 
abstraction the code away are:

1. Complexity of the software
2. Size of the software
3. Diversity of the target hardware

> Writing source code for fun is not necessarily what the customer wants to pay for.

If there is a programmable system, there must be a program.

> What if my client wants something that can be done in Simulink? The argument that Simulink cannot be used for software development is then irrelevant, even if software development itself could be (and perhaps frequently is) abused to do the work.

We discussed that already. There are simply no projects which could be 
designed solely in Simulink. A typical customer would require a HTTP 
server, cloud, integration with the ERP, data logging and reporting, 
software upgrade service and so on. Simulink is about 1% of things to be 
done.

>> BTW, the customers I know do not deploy the code generated by the
>> real-time workshop. The code (in C) is manually rewritten and reviewed.
>> Yes, one must have the worst from both worlds!
> 
> Yes. Still, there can be added value here: the simulations allowed to validate the design ideas. Then the coding follows the path that is already verified to be safe.

Simulink is used to build a model of the physical process and/or of 
control. Real-time workshop implements a numeric approximation of these 
models in C.

Yes, engineers can use Simulink models to communicate their ideas. 
However it also limits possible implementations, because there are 
things outside these models and also things in the models that cannot be 
faithfully implemented by a discrete machine in finite time.

>> Any extra layer of languages increases complexity
>> exponentially.
> 
> I disagree. The extra layer can guide the choices at another layer, thus reducing the space at that other layer.

If you are not satisfied with the language, why introducing a new one 
leaving the first in place? The only valid reason is mathematical 
impossibility to have a single language, like in the case of Ada and 
SPARK. That is not the case for the pair Ada/Simulink. I believe if 
somebody invested half of time invested in Simulink one could come up 
with a numeric Ada library, which would be easier to use than Simulink, 
even for engineers.

There is no need to invent reasons. It is much simpler. Nobody ever 
evaluates tools and languages. They just take what they know and what 
they have heard of. More the better. For each real or imaginary problem 
there must be a tool to buy. If the tool is crap, let's install another 
one on top of it.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> If you have adequate software models, you could. Unfortunately there
> are no better models of this kind than the constructs offered by
> higher-level programming languages. Nothing of that is relevant to
> Simulink, which is to model a narrow class physical objects.

Why this obsession with Simulink?

I doubt there's much call for Simulink when you're building an air
traffic control system. Or a library management system. Or a (sub)system
that decides when to fire a missile against a target, and when the first
missile has missed and another go is needed (I know something about the
last of those).

You're certainly going to partition systems like that into domains
(you're not going to mix the business logic with the database accesses
for the library or the control algorithms for the tracker radar). And
it's not unreasonable that you might use different, appropriate, tools
for the different domains: Simulink for the tracker radar control, for
example, or a tool which supports data modelling and statecharts for the
business logic of library management.

And if the tools can generate code, so much the better. Of course
there's a verification issue; but the system engineers will (at least
initially) validate the model.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-08 18:00, Simon Wright wrote:

> You're certainly going to partition systems like that into domains
> (you're not going to mix the business logic with the database accesses
> for the library or the control algorithms for the tracker radar). And
> it's not unreasonable that you might use different, appropriate, tools
> for the different domains: Simulink for the tracker radar control, for
> example, or a tool which supports data modelling and statecharts for the
> business logic of library management.

I am skeptical about that approach in general. For example attempts to 
use tools and specialized languages for GUI design. It does not work 
well. I think difficulties to glue the system together outweigh possible 
advantages.

> And if the tools can generate code, so much the better. Of course
> there's a verification issue; but the system engineers will (at least
> initially) validate the model.

Good luck maintaining and supporting that mess.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[G. B.]

Maciej Sobczak <see.my.homepage@gmail.com> wrote:
>.
> People are really determined to invent all kind of necessary shit, as
> long as it saves them from writing code. And this is what bothers me.

Software production based on source text still seems far from proper
engineering in many places. For any product P, “why does it not work?” may
be met with a shrug... Programmers reinvent wheels. Managers cannot see
what programmers do. But if there is a presentable pictogram of a software
product, it creates a different idea. 

So, things to do to prove that source text is better than pictures is to
(a) be able to answer, from source, questions satisfactorily and (b)
extract, from source, a pictorial representation with which people can
work.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-05 08:18, G. B. wrote:

> Managers cannot see what programmers do.

Need they to? I think the established view is that [mis]management is a 
discipline of its own. A manager can manage a diary farm company or a 
software house just same...

> But if there is a presentable pictogram of a software
> product, it creates a different idea.
> 
> So, things to do to prove that source text is better than pictures is to
> (a) be able to answer, from source, questions satisfactorily and (b)
> extract, from source, a pictorial representation with which people can
> work.

There is nothing to prove. Pictures are to convey a general idea or 
concept. It is the best way to impress but also to fool an incompetent 
manager, customer, buyer. But it is no way to analyze, design implement 
things. You compare incomparable: marketing and engineering.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> > Managers cannot see what programmers do.
> 
> Need they to? I think the established view is that [mis]management is a 
> discipline of its own. A manager can manage a diary farm company or a 
> software house just same...

I think that the two statements above explain a lot. If managers have no idea what we do and we have no idea what they do, how can we expect software engineering to be a mature discipline? :-D

> Pictures are to convey a general idea or 
> concept. It is the best way to impress but also to fool an incompetent 
> manager, customer, buyer. But it is no way to analyze, design implement 
> things.

I think electrical and hardware engineers (and just about every other engineer) would disagree. Everybody relies on pictures and the general consensus is that you cannot do proper engineering without them. So there is nothing strange if people expect pictures in software engineering, too. If we cannot do them right, it does not mean that the idea itself is wrong. Maybe (yes, it's difficult to admit) we are just bad engineers and we try to hide our incompetence behind ever larger amounts or incomprehensible and unmanageable source code.
Just thinking. :-)

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

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-05 10:51, Maciej Sobczak wrote:
>>> Managers cannot see what programmers do.
>>
>> Need they to? I think the established view is that [mis]management is a
>> discipline of its own. A manager can manage a diary farm company or a
>> software house just same...
> 
> I think that the two statements above explain a lot. If managers have no idea what we do and we have no idea what they do, how can we expect software engineering to be a mature discipline? :-D

It is not about discipline, it is about the maximum size of a 
project/company/organization when things stop working no matter what.

>> Pictures are to convey a general idea or
>> concept. It is the best way to impress but also to fool an incompetent
>> manager, customer, buyer. But it is no way to analyze, design implement
>> things.
> 
> I think electrical and hardware engineers (and just about every other engineer) would disagree.

Maybe they would.

> Everybody relies on pictures and the general consensus is that you cannot do proper engineering without them. So there is nothing strange if people expect pictures in software engineering, too. If we cannot do them right, it does not mean that the idea itself is wrong. Maybe (yes, it's difficult to admit) we are just bad engineers and we try to hide our incompetence behind ever larger amounts or incomprehensible and unmanageable source code.
> Just thinking. :-)

People tried block diagrams in 60's. Somehow it did not work. Maybe 
general consensus is not same as objective truth? Usually consensus is 
only general when wrong... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Randy Brukardt]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:q5m7bc$1mf2$1@gioia.aioe.org...
> On 2019-03-05 10:51, Maciej Sobczak wrote:
>>>> Managers cannot see what programmers do.
>>>
>>> Need they to? I think the established view is that [mis]management is a
>>> discipline of its own. A manager can manage a diary farm company or a
>>> software house just same...
>>
>> I think that the two statements above explain a lot. If managers have no 
>> idea what we do and we have no idea what they do, how can we expect 
>> software engineering to be a mature discipline? :-D
>
> It is not about discipline, it is about the maximum size of a 
> project/company/organization when things stop working no matter what.

This is an interesting point. When an organization gets big enough to need 
managers, my contention is that it is already too big. For most human 
endevours, there is a size of group beyond which very little progress will 
occur regardless of numbers. Because once you start adding layers of 
management, interactions become fossilized and incremental progress goes 
down. Brooks law applies to pretty much everything!

Clearly there are some projects that need to be large (infrastructure like 
roads and utilities come to mind), but the more that can be minimized the 
better.

Otherwise, smaller is almost always better. Small organizations also have 
the advantage that they can be allowed to fail, so the true power of 
capitalism actually can bear on them. People aren't trapped in terrible jobs 
because there are plenty of other similar places that they could work. And 
so on.

And in such cases, fancy "engineering" isn't necessary. Simply use Ada to 
get your stuff right in the first place; no need to impress managers or 
other people that aren't adding anything to society.

                          Randy.

Re: Ada in command / control systems

[Niklas Holsti]

On 19-03-05 11:51 , Maciej Sobczak wrote:
   ...
> Everybody relies on pictures and the general consensus is that you
> cannot do proper engineering without them. So there is nothing
> strange if people expect pictures in software engineering, too.

Anecdote regarding the importance of pictures:

A colleague of mine was working on some on-board satellite SW 
(ultimately) for ESA. At the SW Requirements Review, the customer's 
representative (that is, the main reviewer) rejected the SW Requirements 
Specification (the object of the review) as "poor" and demanded that it 
be "rewritten" -- a very unusual level of criticism.

After some close questioning the reviewer admitted that he had only 
glanced at the document and decided to reject it because it contained no 
pictures or diagrams. He had not read enough to have found any specific 
errors or shortcomings.

Fortunately, the other reviewers had a better opinion of the document 
(having actually read it) and the review passed with only the usual 
amount of corrections required. End of anecdote.

I'm not sure which side -- if either -- of the present argument this 
anecdote supports, but I tend to agree with Dmitry on the limitations of 
the graphically oriented model-based-design tools. When the model and 
design are devised and shown at so high a level as to be easily 
comprehensible, the model usually becomes approximate, which means that 
running code cannot be generated from the model.

The design pictures that are really useful for understanding a piece of 
SW are almost always abstractions and simplifications and could be 
called "useful lies". Unfortunately this means that the pictures must be 
manually created, and manually maintained as the SW evolves.

It may be possible to make the model-based design tools encompass more 
levels of abstraction and detail, and perhaps separate aspects of the 
design so that different aspects could be designed and illustrated by 
different diagrams, with the tool able to "weave" all aspects into the 
generated code. The several types of diagrams defined in UML may be an 
attempt in this direction. However, AIUI current model-based tools are 
each based on a single kind of "model" -- say, state-charts -- and then 
Dmitry's criticism applies.

-- 
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
       .      @       .

Re: Ada in command / control systems

[Simon Wright]

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> However, AIUI current model-based tools are each based on a single
> kind of "model" -- say, state-charts -- and then Dmitry's criticism
> applies.

The ones I know of support class and state modelling. I don't see how
you can get away with just the one.

Re: Ada in command / control systems

[G. B.]

Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:

> The design pictures that are really useful for understanding a piece of 
> SW are almost always abstractions and simplifications and could be 
> called "useful lies". Unfortunately this means that the pictures must be 
> manually created, and manually maintained as the SW evolves.

I like to think that there are “almost-pictures”. When I want to understand
a concurrent Ada program, then this may require knowing the communications
while keeping in mind the shared resources. For understanding
communications, Ada offers some visual(!) clues: e.g., the control
structure of a task body together with „accept“ and “requeue”. There may be
“select” at the other end. These appear(!) in predictable places, shaped by
syntax and style(!). That’s the start of a picture . And it’s abstraction,
since presumably I shouldn’t need to study most of the details in between
the visual clues. Call the result semantic folding that focuses on
communications.

I think that pictures can outline these kinds of structure. They document
the participating objects and their interactions. So, maybe the UML, say,
can serve a purpose here, if we manage to link broad ideas (pictures) and
detailed implementation (source) mechanically.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-06 08:26, G. B. wrote:
> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
> 
>> The design pictures that are really useful for understanding a piece of
>> SW are almost always abstractions and simplifications and could be
>> called "useful lies". Unfortunately this means that the pictures must be
>> manually created, and manually maintained as the SW evolves.
> 
> I like to think that there are “almost-pictures”. When I want to understand
> a concurrent Ada program, then this may require knowing the communications
> while keeping in mind the shared resources. For understanding
> communications, Ada offers some visual(!) clues: e.g., the control
> structure of a task body together with „accept“ and “requeue”. There may be
> “select” at the other end. These appear(!) in predictable places, shaped by
> syntax and style(!). That’s the start of a picture . And it’s abstraction,
> since presumably I shouldn’t need to study most of the details in between
> the visual clues. Call the result semantic folding that focuses on
> communications.

You refer more or less the UML sequence diagram here.

The problem with this sort of pictures is its literality. They represent 
an instance of task communication and not communication in its entirety 
as an abstraction of multitude of possible communication instances.

This is one method to convey an idea: the picture illustrates some case, 
the details are supposed to be worked out later. The implementation is 
focused on the details.

And as every programmer knows the idea might be great but alas not 
working because of some minor case like the index out of the array bounds...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On 2019-03-06 08:26, G. B. wrote:
>> Niklas Holsti <niklas.holsti@tidorum.invalid> wrote:
>>
>>> The design pictures that are really useful for understanding a piece
>>> of SW are almost always abstractions and simplifications and could
>>> be called "useful lies". Unfortunately this means that the pictures
>>> must be manually created, and manually maintained as the SW evolves.
>>
>> I like to think that there are “almost-pictures”. When I want to
>> understand a concurrent Ada program, then this may require knowing
>> the communications while keeping in mind the shared resources. For
>> understanding communications, Ada offers some visual(!) clues: e.g.,
>> the control structure of a task body together with „accept“ and
>> “requeue”. There may be “select” at the other end. These appear(!) in
>> predictable places, shaped by syntax and style(!). That’s the start
>> of a picture . And it’s abstraction, since presumably I shouldn’t
>> need to study most of the details in between the visual clues. Call
>> the result semantic folding that focuses on communications.
>
> You refer more or less the UML sequence diagram here.
>
> The problem with this sort of pictures is its literality. They
> represent an instance of task communication and not communication in
> its entirety as an abstraction of multitude of possible communication
> instances.

I once bought "System Design with Ada", R J A Buhr, Prentice Hall 1984,
for a lot of money (at the time), which I deeply regretted. He had a
diagrammatic notation for every possible mode of operation of a task
entry or a select statement. And more. The thing was, you might as well
have read/written the Ada.

Re: Ada in command / control systems

[G. B.]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On 2019-03-06 08:26, G. B. wrote:

>> That’s the start of a picture . And it’s abstraction,
>> since presumably I shouldn’t need to study most of the details in between
>> the visual clues. Call the result semantic folding that focuses on
>> communications.
> 
> You refer more or less the UML sequence diagram here.

Not so much, sequence diagrams might impose their sequence aspect on the
picture.

> The problem with this sort of pictures is its literality. They represent 
> an instance of task communication and not communication in its entirety 
> as an abstraction of multitude of possible communication instances.

They can show all instances, but these pictures do not represent a theory
of abstracting multiple possibilities of abstraction if they represent
communications, which the designing programmer chose to be their purpose.
However, if you can make yourself pick a picture type that shows only
participants and messages, then you even avoid the possibility of
introducing your problem of modeling only a single instance of
communication.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-07 08:35, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

>> The problem with this sort of pictures is its literality. They represent
>> an instance of task communication and not communication in its entirety
>> as an abstraction of multitude of possible communication instances.
> 
> They can show all instances,

There is an continuum instances, considering time axis real-valued. One 
need some mathematical framework to judge equivalence of such diagrams 
according to the sets of cases a given diagram would cover.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> Anecdote regarding the importance of pictures:
[...]

Oh, sure, I have some horror stories, too. But I have horror stories about everything and if the only conclusion from this is that we should stop doing SW, then it's the conclusion I don't want to make.

> The design pictures that are really useful for understanding a piece of 
> SW are almost always abstractions and simplifications and could be 
> called "useful lies". Unfortunately this means that the pictures must be 
> manually created, and manually maintained as the SW evolves.

This is interesting. The question is - is this manual maintenance a cost that outweighs the gains (if there are any)? Another question - is it possible to automate some part of this process to reduce this cost?

For example, even if we don't generate source from models, a tool that tells whether the (possibly hand-written) source is a refinement of the model would be very useful already.

> However, AIUI current model-based tools are 
> each based on a single kind of "model" -- say, state-charts

Which makes them useful at some particular level of the software process. I don't expect a single tool to fill the whole gap between the client and the final product. Criticizing the tool that it is useful only to a limited extent is not very convincing - because I'm still interested in reaping the benefits (if there are any) in this limited scope.

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

Re: Ada in command / control systems

[russ lyttle]

On 3/5/19 12:55 PM, Niklas Holsti wrote:
> On 19-03-05 11:51 , Maciej Sobczak wrote:
>    ...
>> Everybody relies on pictures and the general consensus is that you
>> cannot do proper engineering without them. So there is nothing
>> strange if people expect pictures in software engineering, too.
> 
> Anecdote regarding the importance of pictures:
> 
> A colleague of mine was working on some on-board satellite SW 
> (ultimately) for ESA. At the SW Requirements Review, the customer's 
> representative (that is, the main reviewer) rejected the SW Requirements 
> Specification (the object of the review) as "poor" and demanded that it 
> be "rewritten" -- a very unusual level of criticism.
> 
> After some close questioning the reviewer admitted that he had only 
> glanced at the document and decided to reject it because it contained no 
> pictures or diagrams. He had not read enough to have found any specific 
> errors or shortcomings.
> 
> Fortunately, the other reviewers had a better opinion of the document 
> (having actually read it) and the review passed with only the usual 
> amount of corrections required. End of anecdote.
> 
> I'm not sure which side -- if either -- of the present argument this 
> anecdote supports, but I tend to agree with Dmitry on the limitations of 
> the graphically oriented model-based-design tools. When the model and 
> design are devised and shown at so high a level as to be easily 
> comprehensible, the model usually becomes approximate, which means that 
> running code cannot be generated from the model.
> 
> The design pictures that are really useful for understanding a piece of 
> SW are almost always abstractions and simplifications and could be 
> called "useful lies". Unfortunately this means that the pictures must be 
> manually created, and manually maintained as the SW evolves.
> 
> It may be possible to make the model-based design tools encompass more 
> levels of abstraction and detail, and perhaps separate aspects of the 
> design so that different aspects could be designed and illustrated by 
> different diagrams, with the tool able to "weave" all aspects into the 
> generated code. The several types of diagrams defined in UML may be an 
> attempt in this direction. However, AIUI current model-based tools are 
> each based on a single kind of "model" -- say, state-charts -- and then 
> Dmitry's criticism applies.
> 

Which brings up a recurring debate. If there is a conflict between two 
diagrams, which takes precedence?

IANAL, but generally written word takes precedence over diagrams and 
more detailed diagrams take precedence over less detailed diagrams.
Using UML as an example, which would take precedence: A Timing Diagram 
or a State Machine Diagram? Does pseudo-code take precedence over all 
Diagrams?  Suppose one diagram shows a bell, a second diagram shows a 
whistle, and a third diagram nothing at all. What is to be provided?
I know contracting officers like pretty pictures in requirements 
document. However, the cost of a project seems to be at least O(N^2) 
with N being the number of diagrams in the requirements document.

Re: Ada in command / control systems

[Simon Wright]

russ lyttle <lyttlec@removegmail.com> writes:

> Which brings up a recurring debate. If there is a conflict between two
> diagrams, which takes precedence?

Neither, in my view (as a purist): there's a contradiction which needs
to be resolved.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-09 09:16, Simon Wright wrote:
> russ lyttle <lyttlec@removegmail.com> writes:
> 
>> Which brings up a recurring debate. If there is a conflict between two
>> diagrams, which takes precedence?
> 
> Neither, in my view (as a purist): there's a contradiction which needs
> to be resolved.

A more interesting question is how do you detect if there is any?

Usually things flow in one direction, from diagrams down to the code. 
This is why people attempt to promote diagrams to requirements. Because 
otherwise you have comebacks, like:

1. Find all diagrams related to procedure Foo?

2. If specification of parameters Foo change, what changes on the 
diagram A45-34E?

Now, as a purist, you must say, OK, if something felt wrong in Foo, I 
ditch all the code, modify diagrams I suspect responsible for the mess 
and then write the code all new...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[russ lyttle]

On 3/9/19 3:59 AM, Dmitry A. Kazakov wrote:
> On 2019-03-09 09:16, Simon Wright wrote:
>> russ lyttle <lyttlec@removegmail.com> writes:
>>
>>> Which brings up a recurring debate. If there is a conflict between two
>>> diagrams, which takes precedence?
>>
>> Neither, in my view (as a purist): there's a contradiction which needs
>> to be resolved.
> 
> A more interesting question is how do you detect if there is any?
> 
> Usually things flow in one direction, from diagrams down to the code. 
> This is why people attempt to promote diagrams to requirements. Because 
> otherwise you have comebacks, like:
> 
> 1. Find all diagrams related to procedure Foo?
> 
> 2. If specification of parameters Foo change, what changes on the 
> diagram A45-34E?
> 
> Now, as a purist, you must say, OK, if something felt wrong in Foo, I 
> ditch all the code, modify diagrams I suspect responsible for the mess 
> and then write the code all new...
> 
Write some checks and repeat as needed.

I find diagrams very helpful, but only as a visualization aid. Not as a 
deliverable in the contract. And the last diagram is developed from the 
code.

Re: Ada in command / control systems

[G.B.]

On 09.03.19 09:59, Dmitry A. Kazakov wrote:
> On 2019-03-09 09:16, Simon Wright wrote:
>> russ lyttle <lyttlec@removegmail.com> writes:
>>
>>> Which brings up a recurring debate. If there is a conflict between two
>>> diagrams, which takes precedence?
>>
>> Neither, in my view (as a purist): there's a contradiction which needs
>> to be resolved.
> 
> A more interesting question is how do you detect if there is any?

When the questions is about errors in a model, one answer can
mention that a modeling tool uses formal models or meta-models,
to store manifestations of design ideas. Not just diagrams,
Model store and diagrams are based on a modeling language.
The use of a modeling language (notation) implies syntax,
semantics, and checking. Some modeling errors will be found
just because they are ungrammatical. So, pitures have grammar
and more.

In addition to the rules that are built-in, some tools will
accept and apply user-written rules for validation.

This seems familiar, to me, when compared to Ada tools. Compilers
will handle input according to the standard Ada language model,
and other tools use rules for inspecting additional properties
of an Ada program  (SPARK, AdaControl, CodePeer, ...).

The general situation is not changed, only the abstractions
are different. Both add to engineering.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-09 21:06, G.B. wrote:
> On 09.03.19 09:59, Dmitry A. Kazakov wrote:
>> On 2019-03-09 09:16, Simon Wright wrote:
>>> russ lyttle <lyttlec@removegmail.com> writes:
>>>
>>>> Which brings up a recurring debate. If there is a conflict between two
>>>> diagrams, which takes precedence?
>>>
>>> Neither, in my view (as a purist): there's a contradiction which needs
>>> to be resolved.
>>
>> A more interesting question is how do you detect if there is any?
> 
> When the questions is about errors in a model, one answer can
> mention that a modeling tool uses formal models or meta-models,
> to store manifestations of design ideas. Not just diagrams,
> Model store and diagrams are based on a modeling language.
> The use of a modeling language (notation) implies syntax,
> semantics, and checking. Some modeling errors will be found
> just because they are ungrammatical. So, pitures have grammar
> and more.
> 
> In addition to the rules that are built-in, some tools will
> accept and apply user-written rules for validation.
> 
> This seems familiar, to me, when compared to Ada tools. Compilers
> will handle input according to the standard Ada language model,
> and other tools use rules for inspecting additional properties
> of an Ada program  (SPARK, AdaControl, CodePeer, ...).
> 
> The general situation is not changed, only the abstractions
> are different. Both add to engineering.

Similarity is superficial. SPARK and code quality assurance tools deal 
with correctness of the program at hand. Models in model-based design 
are implementation. One could even try to invent something like SPARK 
for Simulink models and surely an equivalent of AdaControl.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[russ lyttle]

On 3/9/19 3:16 AM, Simon Wright wrote:
> russ lyttle <lyttlec@removegmail.com> writes:
> 
>> Which brings up a recurring debate. If there is a conflict between two
>> diagrams, which takes precedence?
> 
> Neither, in my view (as a purist): there's a contradiction which needs
> to be resolved.
> 
It's resolving the contradiction that is the problem. If I'm the 
software engineer, I will claim neither is required and the buyer will 
have to pay more if he wants either. If I'm the buyer I will claim the 
contract requires both and no extra money is due.

I've had to deal with several contractors who would find such instances 
and underbid to get the contract. They would then try to "get well" by 
demanding more money to fix the problem. One guy I had to deal with only 
had lawyers on staff. He hired temp software developers if needed.

Diagrams are much more difficult to maintain than text. During the life 
of the project, they tend to fall more and more out of synch. How does 
your automated requirements tracker diff two diagrams?

Re: Ada in command / control systems

[Simon Wright]

russ lyttle <lyttlec@removegmail.com> writes:

> Diagrams are much more difficult to maintain than text. During the
> life of the project, they tend to fall more and more out of synch. How
> does your automated requirements tracker diff two diagrams?

Hence your remark about text > diagrams.

We had a code generator, which was also capable of outputting
documentation in HMTL. We could diff the old & the new HTML in Word,
made life very straightforward.

Of course a requirements diagram is going to be much more handwavy.

Re: Ada in command / control systems

[lyttlec]

On 3/9/19 2:28 PM, Simon Wright wrote:
> russ lyttle <lyttlec@removegmail.com> writes:
> 
>> Diagrams are much more difficult to maintain than text. During the
>> life of the project, they tend to fall more and more out of synch. How
>> does your automated requirements tracker diff two diagrams?
> 
> Hence your remark about text > diagrams.
> 
> We had a code generator, which was also capable of outputting
> documentation in HMTL. We could diff the old & the new HTML in Word,
> made life very straightforward.
> 
> Of course a requirements diagram is going to be much more handwavy.
> 

Code-to-diagram generators do make life easier! Especially for maintenance.
Speaking of which, is there a good one for Ada? I have a couple for
C/C++ but not Ada.

Re: Ada in command / control systems

[Simon Wright]

lyttlec <lyttlec@removegmail.com> writes:

> Code-to-diagram generators do make life easier! Especially for
> maintenance.  Speaking of which, is there a good one for Ada? I have a
> couple for C/C++ but not Ada.

The trouble with code-to-diagram generators is that it's only really
possible to make a useful diagram if it hides some aspect of the
code, and if the code is created by humans (even just one human!) there
won't be the architectural consistency to achieve that. For example,
there may be many ways of representing the notion that one Target may be
being engaged by one or more Missiles_In_Flight, but that a
Missile_In_Flight is engaging precisely one Target.

In rather the same way that it must be quite hard to convert an
optimised binary back to the Ada source code it was generated from.

That said, I wonder whether you meant diagram-to-code generators? In
that case, the relationship I described above would be straightforward
to specify in a UML class diagram, and the architectural decisions made
in the specific code generator would mean that you would know exactly
how to navigate the model: the function call

   Is_Engaged_By (The_Target)

would return a possibly-empty list of Missile_In_Flight.

Modelling/code generators for the sort of project that's appropriate to
model in UML (probably not e.g. FADEC, but certainly the business logic
of a railway signalling system) include

* Rational Rhapsody,
  https://www.ibm.com/uk-en/marketplace/rational-rhapsody

* Bridgepoint, https://xtuml.org

* xUML, https://abstractsolutions.co.uk/our-services/executable-uml/

* my ColdFrame, https://simonjwright.github.io/coldframe/

Re: Ada in command / control systems

[russ lyttle]

On 3/11/19 4:56 AM, Simon Wright wrote:
> lyttlec <lyttlec@removegmail.com> writes:
> 
>> Code-to-diagram generators do make life easier! Especially for
>> maintenance.  Speaking of which, is there a good one for Ada? I have a
>> couple for C/C++ but not Ada.
> 
> The trouble with code-to-diagram generators is that it's only really
> possible to make a useful diagram if it hides some aspect of the
> code, and if the code is created by humans (even just one human!) there
> won't be the architectural consistency to achieve that. For example,
> there may be many ways of representing the notion that one Target may be
> being engaged by one or more Missiles_In_Flight, but that a
> Missile_In_Flight is engaging precisely one Target.
> 
> In rather the same way that it must be quite hard to convert an
> optimised binary back to the Ada source code it was generated from.
> 
> That said, I wonder whether you meant diagram-to-code generators? In
> that case, the relationship I described above would be straightforward
> to specify in a UML class diagram, and the architectural decisions made
> in the specific code generator would mean that you would know exactly
> how to navigate the model: the function call
> 
>     Is_Engaged_By (The_Target)
> 
> would return a possibly-empty list of Missile_In_Flight.
> 
> Modelling/code generators for the sort of project that's appropriate to
> model in UML (probably not e.g. FADEC, but certainly the business logic
> of a railway signalling system) include
> 
> * Rational Rhapsody,
>    https://www.ibm.com/uk-en/marketplace/rational-rhapsody
> 
> * Bridgepoint, https://xtuml.org
> 
> * xUML, https://abstractsolutions.co.uk/our-services/executable-uml/
> 
> * my ColdFrame, https://simonjwright.github.io/coldframe/
> 
No, I meant code-to-diagram as last step with the "as-built" documents.
I've used Rational Rhapsody in conjunction with DOORS several times. 
Each time the UML diagrams were generated early in the project included 
in high-level requirements as objects in DOORS, and used to create a 
code framework. Managers want to start billing the coding team against 
the project, so they started filling in the blanks and committing code. 
A year later and 2 levels down a bug was discovered and fixed. No one 
ever changed the original UML diagrams to reflect the change. Either as 
an oversight or because they didn't want to go through the whole process 
of changing a high level requirement.
Big mess at the end.

I like using the diagrams as an engineering aid. Just not including them 
in the requirements documents. Requirements are (should be) fixed and 
unchangeable. The diagrams need to be dynamic and always reflect the 
current status of the code.

Re: Ada in command / control systems

[Simon Wright]

russ lyttle <lyttlec@removegmail.com> writes:

> I like using the diagrams as an engineering aid. Just not including
> them in the requirements documents.

Completely agree that models to be automatically converted into code
[even frameworks] can't be part of the requirements, they're part of the
solution.

> Requirements are (should be) fixed and unchangeable.

Hollow laughter :-)

> The diagrams need to be dynamic and always reflect the current status
> of the code.

Well, if your process requires that the model is updated first and the
code regenerated, that will happen automatically. We did that.

Re: Ada in command / control systems

[russ lyttle]

On 3/11/19 1:01 PM, Simon Wright wrote:
> russ lyttle <lyttlec@removegmail.com> writes:
> 
>> I like using the diagrams as an engineering aid. Just not including
>> them in the requirements documents.
> 
> Completely agree that models to be automatically converted into code
> [even frameworks] can't be part of the requirements, they're part of the
> solution.
> 
>> Requirements are (should be) fixed and unchangeable.
> 
> Hollow laughter :-)
That line is always good for a few chuckles.
> 
>> The diagrams need to be dynamic and always reflect the current status
>> of the code.
> 
> Well, if your process requires that the model is updated first and the
> code regenerated, that will happen automatically. We did that.
> 

I've had projects where that happened. And many more where it didn't 
happen. The main stumbling block was that to change a high-level 
requirement required re-negotiating and amending the contract. Then the 
change has to trickle down through all the documentation and process'. I 
can recall one instance where that process took a year.

Re: Ada in command / control systems

[russ lyttle]

On 3/5/19 4:28 AM, Dmitry A. Kazakov wrote:
> On 2019-03-05 08:18, G. B. wrote:
> 
>> Managers cannot see what programmers do.
> 
> Need they to? I think the established view is that [mis]management is a 
> discipline of its own. A manager can manage a diary farm company or a 
> software house just same...
> 
I have to disagree with the last statement. If the manager isn't skilled 
in a field, he can't manage it. For example, staffing a software company 
and a dairy farm are completely different. Having done both, I suggest 
looking up Watts S.Humpherey books for some thoughts.
I once heard him say "It takes five years to go from CMM level 1 to 
level 5, and one day to go from level 5 to level 1. My personal 
experience confirms that. My MBA classes taught that the first thing a 
company should do to cut cost and increase profit is to lay off 
personnel. At the dairy farm, I could staff up and lay off pretty much 
at will. It wasn't difficult to find people to shovel up behind cows. So 
the first thing the manager of a ball team should do to increase profit 
is lay off the players. Same thing at a software company. I have some 
good horror stories about trying to staff software personnel. Staffing 
the dairy farm usually involved painting "Help Wanted" on a sheet of 
plywood by the road.

>> But if there is a presentable pictogram of a software
>> product, it creates a different idea.
>>
>> So, things to do to prove that source text is better than pictures is to
>> (a) be able to answer, from source, questions satisfactorily and (b)
>> extract, from source, a pictorial representation with which people can
>> work.
> 
> There is nothing to prove. Pictures are to convey a general idea or 
> concept. It is the best way to impress but also to fool an incompetent 
> manager, customer, buyer. But it is no way to analyze, design implement 
> things. You compare incomparable: marketing and engineering.
> 

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-05 12:59, russ lyttle wrote:

> At the dairy farm, I could staff up and lay off pretty much 
> at will. It wasn't difficult to find people to shovel up behind cows. So 
> the first thing the manager of a ball team should do to increase profit 
> is lay off the players. Same thing at a software company. I have some 
> good horror stories about trying to staff software personnel. Staffing 
> the dairy farm usually involved painting "Help Wanted" on a sheet of 
> plywood by the road.

I though the diary farm's staff are the cows... Sorry, could not resist 
(:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[lyttlec]

On 3/5/19 1:18 PM, Dmitry A. Kazakov wrote:
> On 2019-03-05 12:59, russ lyttle wrote:
> 
>> At the dairy farm, I could staff up and lay off pretty much at will.
>> It wasn't difficult to find people to shovel up behind cows. So the
>> first thing the manager of a ball team should do to increase profit is
>> lay off the players. Same thing at a software company. I have some
>> good horror stories about trying to staff software personnel. Staffing
>> the dairy farm usually involved painting "Help Wanted" on a sheet of
>> plywood by the road.
> 
> I though the diary farm's staff are the cows... Sorry, could not resist
> (:-))
> 
There is some debate about that. The farmer has to get up when the cows
want to be milked. If they don't like how it's done, they kick over the
bucket.  The cows can't be fired. They are fed what they like on their
schedule. Other than that they stand around chewing their cud. So who is
smarter?

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-03-06 03:01, lyttlec wrote:
> On 3/5/19 1:18 PM, Dmitry A. Kazakov wrote:
>> On 2019-03-05 12:59, russ lyttle wrote:
>>
>>> At the dairy farm, I could staff up and lay off pretty much at will.
>>> It wasn't difficult to find people to shovel up behind cows. So the
>>> first thing the manager of a ball team should do to increase profit is
>>> lay off the players. Same thing at a software company. I have some
>>> good horror stories about trying to staff software personnel. Staffing
>>> the dairy farm usually involved painting "Help Wanted" on a sheet of
>>> plywood by the road.
>>
>> I though the diary farm's staff are the cows... Sorry, could not resist
>> (:-))
>>
> There is some debate about that. The farmer has to get up when the cows
> want to be milked. If they don't like how it's done, they kick over the
> bucket.  The cows can't be fired. They are fed what they like on their
> schedule. Other than that they stand around chewing their cud. So who is
> smarter?

Yeah, the old joke about one lab monkey saying to another, "see, if I 
press this button, the guy in the white coat will give me a banana." (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> Moreover, after spending some time in the mixed SW/HW environment, I
> would never assume engineers from other domains to be less competent
> than software engineers.

It was a long time ago, and they may have learnt from terrible
programmers, but I've seen some really bad boot code implemented by
hardware guys. 

Re: Ada in command / control systems

[Maciej Sobczak]

> > Moreover, after spending some time in the mixed SW/HW environment, I
> > would never assume engineers from other domains to be less competent
> > than software engineers.
> 
> It was a long time ago, and they may have learnt from terrible
> programmers, but I've seen some really bad boot code implemented by
> hardware guys.

And yet the same guys went through some well-defined process designing their hardware. They made diagrams, they calculated everything before actually implementing anything (so they used formal methods even without referring to this process this way), they planned they physical aspects and carefully designed the layout, they cared about traceability and made sure nothing got lost on the way, they validated all connections top-down and bottom-up and even made the bill of material for production. Considering the high cost of errors, they have put a lot of effort not to make any.

And then they went to coding the crappy boot loader that works only by chance.

What I'm interested in is how this is possible. Of course, it is easy for us (and self-flattering, right?) to just assume that they are simply incompetent, but I see some deeper problem here.
I think that during the last decades we have made it possible to produce crappy software. It's too cheap to fix to bother to make it right. This is the comfort that other domains do not have and this is what makes the difference in how engineering in different domains is practiced.

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

Re: Ada in command / control systems

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> I think that during the last decades we have made it possible to
> produce crappy software. It's too cheap to fix to bother to make it
> right. This is the comfort that other domains do not have and this is
> what makes the difference in how engineering in different domains is
> practiced.

Which is not the case if you're developing automotve control software,
for example; it's not cheap to fix when you have hundreds of thousands
of examples out in the field.

I suppose we know how to estimate the costs to design the hardware
properly. Not sure that we even know how to design the software
properly, let alone how much it'll cost.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-26 23:45, Simon Wright wrote:

> I suppose we know how to estimate the costs to design the hardware
> properly. Not sure that we even know how to design the software
> properly, let alone how much it'll cost.

Exactly. It's the economy, stupid. The software is taken for granted as 
an add-on to the "real" bright and shiny thing. Even the smartphone, 
which is probably 99% software and 1% hardware is treated this way. What 
has no price has no value.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Maciej Sobczak]

> Which is not the case if you're developing automotve control software,
> for example; it's not cheap to fix when you have hundreds of thousands
> of examples out in the field.

https://www.tesla.com/support/software-updates

"Tesla cars regularly receive over-the-air software updates [...]"

So why care about quality? If you have the comfort to fix everything later, then time to market wins over quality hands down.

> I suppose we know how to estimate the costs to design the hardware
> properly. Not sure that we even know how to design the software
> properly, let alone how much it'll cost.

Right. But why?
In any case, this justifies my earlier statement: I do not consider engineers from other domains to be less competent than me. Actually, it's us who seem to be lacking skills to do our own homework. Right?

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

Re: Ada in command / control systems

[Simon Wright]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

>> Which is not the case if you're developing automotve control software,
>> for example; it's not cheap to fix when you have hundreds of thousands
>> of examples out in the field.
>
> https://www.tesla.com/support/software-updates
>
> "Tesla cars regularly receive over-the-air software updates [...]"
>
> So why care about quality? If you have the comfort to fix everything
> later, then time to market wins over quality hands down.
>
>> I suppose we know how to estimate the costs to design the hardware
>> properly. Not sure that we even know how to design the software
>> properly, let alone how much it'll cost.
>
> Right. But why?
> In any case, this justifies my earlier statement: I do not consider
> engineers from other domains to be less competent than me. Actually,
> it's us who seem to be lacking skills to do our own homework. Right?

Yes.

Re: Ada in command / control systems

[Dmitry A. Kazakov]

On 2019-02-27 22:26, Simon Wright wrote:
> Maciej Sobczak <see.my.homepage@gmail.com> writes:

>> In any case, this justifies my earlier statement: I do not consider
>> engineers from other domains to be less competent than me. Actually,
>> it's us who seem to be lacking skills to do our own homework. Right?
> 
> Yes.

Software developing is not engineering. Software developers are more 
like artisans. Nevertheless, there are good artisans and bad ones.

I fancied an idea of post-apocalyptic scenario when humans would loose 
most of the technology but retain management and social structure. 
Imagine a modern bureaucratic organization governing a cobblers guild. 
That would be an equivalent of software house. (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Ada in command / control systems

[Jesper Quorning]

On Tuesday, February 26, 2019 at 10:28:18 AM UTC+1, Maciej Sobczak wrote:


> Moreover, after spending some time in the mixed SW/HW environment, I would never assume engineers from other domains to be less competent than software engineers. On the contrary, I'm happy they they actually do not share our anti-practices and general disregard to work rigor, of which I have seen too much in software already.
> Note also that software engineering world, especially in the industrial and critical domains, is slowly (?) drifting towards model-based techniques. Not only in some sense we are catching up with the culture that our colleagues from other domains cultivated long before us, but it actually makes the advantages of Ada increasingly irrelevant. The choice will be no longer between C and Ada, but rather between Python (or similar) and Simulink (or similar - I'm referring to mindsets, not the actual products).

Engineers are conservative and have other priorities than fast and fancy  programs. Personal and environmental conserns are very important. 

Your cusotomer do not like at wind turbine to crash [2] or a power plant to core dump [3].

Software engineering is a relative new engineering disipline. Civil engineering has been around for thousands of years. When you build a bridge it has to be standing at first try [4].

And yes; 1 MB is 1_000_000 Byte [1].


        Jesper.


[1]: https://en.wikipedia.org/wiki/Kibibyte
[2]: https://youtu.be/wfzgIxMEo8g
[3]: https://youtu.be/nemYBeT4aQY
[4]: https://youtu.be/nFzu6CNtqec