From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,eb0daafec4ae827a X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news3.google.com!news.germany.com!news.belwue.de!kanaga.switch.ch!switch.ch!newsserver.news.garr.it!newsserver.cilea.it!docenti.ing.unipi.it!o2943499 From: Colin Paul Gloster Newsgroups: comp.lang.ada Subject: Re: High-integrity networking Date: Mon, 15 Oct 2007 19:14:36 +0200 Organization: CILEA Message-ID: <20071015182251.E5675@docenti.ing.unipi.it> References: <1191845623.383675.190820@d55g2000hsg.googlegroups.com> <20071008175356.W2321@docenti.ing.unipi.it> <1191875749.647965.104600@v3g2000hsg.googlegroups.com> Reply-To: Colin Paul Gloster NNTP-Posting-Host: docenti.ing.unipi.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: newsserver.cilea.it 1192468476 28577 131.114.28.20 (15 Oct 2007 17:14:36 GMT) X-Complaints-To: news@cilea.it NNTP-Posting-Date: 15 Oct 2007 17:14:36 GMT X-X-Sender: o2943499@docenti.ing.unipi.it In-Reply-To: <1191875749.647965.104600@v3g2000hsg.googlegroups.com> Xref: g2news2.google.com comp.lang.ada:2457 Date: 2007-10-15T17:14:36+00:00 List-Id: Hello, On Mon, 8 Oct 2007, Maciej Sobczak wrote: |--------------------------------------------------------------------------| |"On 8 Pa , 18:03, Colin Paul Gloster | |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