From: Dmitry A. Kazakov on
On Fri, 17 Aug 2007 15:30:32 -0700, philip_b_taylor(a)yahoo.co.uk wrote:

> Sorry perhaps I was not clear enough. There is, of course, no
> intention of using Python on the real-time platforms - the requirement is that
> Python be inter-operable within the framework used, not that it will be used on
> every host in the system. Python (and to some extent Java) will be mainly used in
> the supervisory and scripting tiers of the system. Some (soft) real-
> time hosts will use C++, perhaps Java. There will be specialist hard real-time
> processors which may have to be excluded from the framework.

But in which sense interoperable? Consider Python software being a
publisher. The things it publishes should have certain QoS (say, jitter
<5ms), so? The point is, it is very difficult to insulate an RT part from
the rest of the system. Even HMI has RT requirements. For instance, you hit
the "emergency stop" button and in 20ms it has to reach all actuators.

IMO, a quite common misunderstanding is that an RT transport layer would
automatically make the system RT. It does not. The software does.

> As regards size, I don't know, except 'large'. There should be no size
> limitations imposed by the framework.

This is in a sort of contradiction with RT requirements. Can the system be
modified on-the-fly (process variables/connections added/removed, QoS
parameters changed)? Can the system be able to estimate QoS before run?
Should the system control and optimize QoS?

> My guess is ~100 hosts and 100K+ I/O points?

Yes, this is close to the upper end of the systems we dealt with, ~30
nodes, ~300K variables.

> There's a couple of years detailed design yet to go.

I am very intrigued. If possible of course, could you tell more about the
project?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: philip_b_taylor on
Thanks for the suggestions so far - the only really new one is Ruby on
Rails, which I
I had not considered for this type of system. I know very little about
it, but the Ruby on Rails website
states "Rails is all about infrastructure so it's a great fit for
practically any type of web application Be it
software for collaboration, community, e-commerce, content management,
statistics, management." So
it never struck me as as relevant. I may be wrong.

Someone was surprised that we want to use Java, C++ and Python. Simple
reason: re-use of
legacy code and available skills. We may be introducing new languages
but don't want to add
many more, ideally reduce. Good point about C++ being older technology
than CORBA,
another reason for phasing it out...the performance hit of Java (the
main reason C++ was used) is
surely becoming a thing of the past.

As regards RT constraints on a Python-based system like 5/20 ms
jitter. We would never require
that kind of performance throughout the whole networked system.
Millisecond range stability
will be confined within single nodes or perhaps closely-coupled
subsystems. Safety-critical
systems will be separate, direct hardware/PLC interlocks for close-
down etc. As software engineers
we leave that stuff to the hardware guys :)

As regards the 2 years design - I mean that the hardware is being
designed during the next 2 years
rather than detailed software design (which yes would be unwise and
anyway premature).

Philip



From: Dmitry A. Kazakov on
On Fri, 17 Aug 2007 19:39:04 -0700, Phlip wrote:

> philip_b_taylor wrote:
>
>> There's a couple of years detailed design yet to go.
>
> Please google for "waterfall". Such a long _detailed_ design phase is
> setting you up for _assured_ disaster.

No, you can't sell TDD here.

Let me try to explain why. There are two general archetypical approaches to
design: top-down and bottom-up. What you refer as "waterfall" falls under
top-down. Your TDD is bottom-up. In OO terms moving top-down is equivalent
to specialization. You start with the most general system functionalities
and them put [implementation] constraints on them. TDD is equivalent to
generalization, you start with a minimal working set and then add new /
extend old functionalities and features.

This is why you cannot do TDD for a system having many non-functional
requirements (like QoS). This is fundamentally incompatible with the
evolutionary approach of TDD. For all, non-functional requirements are
non-testable in the sense that a successful test does not tell you anything
useful. It might work with 255 variables and collapse with 256. The
induction: it worked for n => it will work for n+1 is obviously wrong. The
reverse works, you can add constraints keeping the system working. This is
why up-front design is the only way to go for such system.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
From: Phlip on
Dmitry A. Kazakov wrote:

> No, you can't sell TDD here.
>
> Let me try to explain why.

I stopped reading here.

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax


From: Phlip on
philip_b_taylor wrote:

> another reason for phasing it out...the performance hit of Java (the
> main reason C++ was used) is
> surely becoming a thing of the past.

I'm getting a lot of "management by magazine" here. C++ is more
programmer-friendly than Java, and of course faster.

All the hype about Java being "programmer friendly" is just that - hype.
Java's speed is irrelevant if you just install more memory to avoid
thrashing. The point of Java was supposed to be "C++ without stray pointers
and index overruns. Instead, we got a language that makes you jump thru
hoops and write excessive cruft just to get anything done.

Java - the elegant simplicity of C++, the blazing speed of Smalltalk.

You need to settle on two languages. The one closest to the metal should be
compiled, deterministic, statically type, and as programmer-friendly as
possible. The one closest to the users (the soft layer) should be
interpretive, emergent, dynamically typed, and much more
programmer-friendly.

Adding Java (interpretive, deterministic, statically typed, and
programmer-hostile) will just slow you down.

> As regards the 2 years design - I mean that the hardware is being
> designed during the next 2 years
> rather than detailed software design (which yes would be unwise and
> anyway premature).

Ooookay. Why wait 2 years to start _building_ the software? Why not let
software development assist the hardware development?

There's nothing "premature" about starting as early as possible, to give you
the longest runway.

--
Phlip
http://www.oreilly.com/catalog/9780596510657/
"Test Driven Ajax (on Rails)"
assert_xpath, assert_javascript, & assert_ajax