Re: High-integrity networking

[Colin Paul Gloster <Colin_Paul_Gloster@ACM.org>]

Hello,

On Mon, 8 Oct 2007, Maciej Sobczak wrote:

|--------------------------------------------------------------------------|
|"On 8 Pa , 18:03, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>         |
|wrote:                                                                    |
|                                                                          |
|[..]                                                                      |
|                                                                          |
|I didn't mean "design patterns", but "usage patterns" in the sense        |
|that some things are discouraged/forbidden and some others are            |
|promoted/enforced."                                                       |
|--------------------------------------------------------------------------|

Okay.

|--------------------------------------------------------------------------|
|"> A RAVENSCAR task is a process. Multiple threads inside one process are |
|> not possible in RAVENSCAR.                                              |
|                                                                          |
|Could you please throw some references? A relevant citation from the      |
|Ravescar document itself would be perfect."                               |
|--------------------------------------------------------------------------|

It is quite clear from using the index of
Alan Burns and Andy Wellings, "Real-Time Systems and Programming
Languages: Ada 95, Real-Time Java and Real-Time POSIX", third edition
(of the main title, not of the subtitle), 2001, reprint with
corrections that they consider a process to be represented in Ada (and
therefore RAVENSCAR) by a task. (It is not so quick to plainly find
in that book that they consider threads to be different from
processes, but it is what they describe elsewhere in the book.)

|--------------------------------------------------------------------------|
|"I have found *one* paragraph indicating that tasks are single-threaded   |
|and *many* paragraphs about shared variables, global data, and so on."    |
|--------------------------------------------------------------------------|

I do not typically recommend using shared variables nor global data.

|--------------------------------------------------------------------------|
|"As far as I'm concerned it does not really matter how the program is     |
|deployed on the given system - and if it's deployed on bare metal (no     |
|OS underneath), then the distinction between processes and threads        |
|does not make any sense anyway."                                          |
|--------------------------------------------------------------------------|

I disagree.

|--------------------------------------------------------------------------|
|"[..]                                                                     |
|                                                                          |
|> |----------------------------------------------------------------------||
|> |"I'm interested in patterns and solutions for high-reliability        ||
|> |networking/middleware.                                                ||
|> |                                                                      ||
|> |Just "extrapolating" Ravenscar to the distributed environment can lead||
|> |to some imaginably constrained environment where [..]                 ||
|> |[..], the types (and lengths) of messages are                         ||
|> |known up front, etc.                                                  ||
|> |There are some start-up issues with ensuring all these constraints    ||
|> |(for example, the locations of other nodes would need to be first read||
|> |from some configuration file/database before the connections can be   ||
|> |established, etc., [..]                                               ||
|> |                                                                      ||
|> |[..]"                                                                 ||
|> |----------------------------------------------------------------------||
|>                                                                         |
|> RAVENSCAR is not intrinsically specific to the packet-switching         |
|> paradigm.                                                               |
|                                                                          |
|I'm not asking about Ravenscar. I'm asking about recommended reading      |
|in the area of high-integrity networking and middleware. I have           |
|mentioned Ravenscar to give you a hint on what is the kind of document    |
|that could be the closest analogy to what I'm looking for.                |
|                                                                          |
|Any recommendations?"                                                     |
|--------------------------------------------------------------------------|

I had understood that your request was not specific to
RAVENSCAR. Packet-switching is not the only choice for high-integrity
networking. Many different requirements may be imposed on what you
consider to be important for the integrity of a particular network
deployment. E.g. instead of following the mainstream trend of reducing
power consumption, you may deem it to be acceptable to have high voltage
differences such that one of two binary digital values is less likely
to be misinterpreted as the other value. If timing is not crucial,
people do use schemes such as retransmission on wireless networks if
low power is necessary. Of course, reception of the intended value can
never be guaranteed.

In Marescaux; Corporaal, ``Introducing the SuperGT Network-on-Chip ---
SuperGT QoS: more than just GT'', Design Automation Conference it is
argued that delivering packets out of order
is undesirable for an on-chip network. I am not convinced that
this is universally true (it depends on the application, e.g. many
off-chip networks allow delivering packets out of order (e.g. the
Internet (see Page 536 of Andrew S. Tanenbaum, "Computer Networks",
international third edition, Prentice Hall, 1996) and the European
Space Agency's Packet Utilization Standard (European Space Agency,
"Packet Utilisation Standard", ESA
standard PSS-07-101, 1994,
HTTP://WWW.ESA.int/esapub/pss/ecss_web.pdf
and
European Cooperation for Space Standardization, "Ground systems and
operations --- Telemetry and telecommand packet utilization", ECSS
standard E-70-41A, 2003,
HTTP://WWW.ECSS.NL/forums/ecss/dispatch.cgi/standards/docProfile/100204/d20040512075344/No/t100204.htm
))). For designs in which out of order delivery is unacceptable, a
more robust architecture is a circuit-switched architecture as this
can never
happen (see Page 133 of the aforementioned book by Tanenbaum). Other
advantages of circuit-switched networks is that timing analysis is
easier. Misrouting could occur with a packet-switched network but much
of the network overall will survive which is why the Internet was
designed to be as it is: resilient to much of the U.S.A. being
destroyed by a nuclear attack from the U.S.S.R. So in that sense it
could be considered to be of high integrity. However, in the sense
that I would prefer to summon an ambulance by using a circuit-switched
landline telephone, it could be considered to have less desirable
characteristics. As I posted above, it depends on the requirements.

H. Pfeifer, F. von Henke, ``Modular Formal Analysis of the
Central Guardian in the Time-Triggered Architecture'', accepted for
publication in "Reliability Engineering & System Safety", Special
Issue on Safety, Reliability and Security of Industrial Computer
Systems, Elsevier Ltd., 2006,
HTTP://WWW.Informatik.Uni-Ulm.De/ki/Pfeifer/ress06.html
is another reference.

Metastability is claimed to be possible in fewer parts for the
asynchronous design in A. Sheibanyrad, I. Miro Panades and
A. Greiner, ``Systematic Comparison between the Asynchronous and
the Multi-Synchronous Implementations of a Network on Chip
Architecture'', Design for Automation and Test Europe
2007. Eliminating the risk of metastability is doubtful (consult
Freidin; Wormald; Cheney et al., ``Tell me about Metastability'',
HTTP://WWW.FPGA-FAQ.org/FAQ_Pages/0017_Tell_me_about_metastables.htm
) whereas members of the supposedly real-time community, e.g. Burns
and Wellings, do not voluntarily admit that digital electronic devices
are not proven to be suitable for real-time systems.

Regards,
Colin Paul Gloster