Du C ou du Java dans les systèmes embarqués automobile ?

Marc Boyer a écrit :

On 2009-07-06, Sylvain SF <sylvain@boiteaspam.info> wrote:

tu estimes que "les" exemples de la NASA ou du DoD peuvent
créer "un effet d'entraînement", je note que l'industrie
connaît une toute autre dynamique (ou entraînement),
celle, puisque l'on parle d'embarqué, de Java(Card).

L'industrie est une entité vague. C'est vrai que j'aurais
pu préciser "l'industrie de l'embarqué critique".
Je n'ai pas connaissance d'application JavaCard embarqués
critique (critique au sens où l'erreur logicielle coute
des millions de $/¤ ou des vies humaines).
Après, oui, il y a un fremissement autour de Java Temps
Réel (RTSJ). Après, je ne sais pas si ce sera un raz
de marée, un flop, ou un succès d'estime.
J'avais beaucoup cru en Ada par exemple.

Et je maintiens que, dans la communauté de l'embarqué
critique, la NASA et le DoD sont des acteurs importants,
et que leur comportement est un exemple fort.


Marc Boyer

Tout à fait et, sans ironie aucune, pour moi le NASA Systems
Engineering Handbook est un modèle du genre :
(http://www.ap233.org/ap233-public-information/reference/20080008301_2008008500.pdf/view)

On peut citer aussi les différents volumes du NC3-TA
(http://194.7.80.153/website/home_volumes.asp?menuid)

ainsi que DoDAF (DoD Architecture Framework) :
http://fr.wikipedia.org/wiki/DoDAF : l'intro de Wikipedia, pas trop mal
faite.
http://www.architectureframework.com/dodaf/

On 7 juil, 14:46, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:

Michael Doubez <michael.dou...@free.fr> writes:

| On 6 juil, 16:56, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| > Michael Doubez <michael.dou...@free.fr> writes:
| >
| > [...]
| >
| > | AMA, il y a encore du chemin à parcourrir:
| > |  - pour l'avionique, les compilateurs C++ DO178B ne courent pas l es
| > | rues (J'en connais un seul).
| > |  - et pour l'automobile, MISRA C++ est trop récent (~1 an) pour que ça
| > | ait un impact sur l'utilisation de C++.
| >
| > MISERABLE C++ est effectivement récent, mais pas mal de gens préf èrent
| > s'en passer.  As-tu parcouru la liste que j'ai donnée.
|
| La liste sur le site de B.S. ?

Oui.

| Oui mais je me méfie de ce genre de liste.
| Python est aussi utilisé dans à la Nasa, ça veut pas dire qu'ils
| envoient du code Python dans l'espace.

Quel est le rapport avec la liste dont je parle ?

Que veux tu démontrer avec la liste ?

Par exemple:
Boeing 787 software. Entirely written in C++, using STL.

Il vole pas encore :) Bientôt peut être.

Et le software de quoi ? Du réseau interne ?

<quote>
La FAA, autorité de l’administration de l’aviation civile US, est bie n
ennuyée de voir que ce Boeing va avoir un réseau informatique ouvert à
ses passagers. Jusque là, ce serait plutôt une bonne nouvelle qui
annoncer plein de solutions réseau en vol (mail, web, IM, etc.) mais
Boeing a fait une grosse bourde : le réseau public n’est pas isolé du
réseau de bord. Dès lors, la FAA a bien peur de voir les passagers
semer (volontairement ou pas) la pagaille dans les instruments de
l’avion.
</quote>

--
Michael

Marc Boyer, le 07/07/2009 a écrit :

[...]

L'industrie est une entité vague.

Ben non...

C'est vrai que j'aurais
pu préciser "l'industrie de l'embarqué critique".

Là, ce n'est plus vague du tout du tout, effectivement.

Je n'ai pas connaissance d'application JavaCard embarqués
critique (critique au sens où l'erreur logicielle coute
des millions de $/¤ ou des vies humaines).

Il existe malheureusement des applications /embarquées critiques/ dans
lesquelles la perte de vies humaines n'est pas le résultat d'un bug,
mais simplement *le but*.

--
Pierre Maurette

Michael Doubez <michael.doubez@free.fr> writes:

| On 7 juil, 14:46, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| > Michael Doubez <michael.dou...@free.fr> writes:
| >
| > | On 6 juil, 16:56, Gabriel Dos Reis <g...@cs.tamu.edu> wrote:
| > | > Michael Doubez <michael.dou...@free.fr> writes:
| > | >
| > | > [...]
| > | >
| > | > | AMA, il y a encore du chemin à parcourrir:
| > | > |  - pour l'avionique, les compilateurs C++ DO178B ne courent pas les
| > | > | rues (J'en connais un seul).
| > | > |  - et pour l'automobile, MISRA C++ est trop récent (~1 an) pour que ça
| > | > | ait un impact sur l'utilisation de C++.
| > | >
| > | > MISERABLE C++ est effectivement récent, mais pas mal de gens p réfèrent
| > | > s'en passer.  As-tu parcouru la liste que j'ai donnée.
| > |
| > | La liste sur le site de B.S. ?
| >
| > Oui.
| >
| > | Oui mais je me méfie de ce genre de liste.
| > | Python est aussi utilisé dans à la Nasa, ça veut pas d ire qu'ils
| > | envoient du code Python dans l'espace.
| >
| > Quel est le rapport avec la liste dont je parle ?
|
| Que veux tu démontrer avec la liste ?

Tu disais

Python est aussi utilisé dans à la Nasa, ça veut pas dir e qu'ils
envoient du code Python dans l'espace.

Je voulais savoir le rapport qut tu vois avec la liste.

| Par exemple:
| Boeing 787 software. Entirely written in C++, using STL.
|
| Il vole pas encore :) Bientôt peut être.

Donc ?

| Et le software de quoi ? Du réseau interne ?

Tu peux demander à Bjarne -- au cas où tu as des doutes sur ce qu 'il
dit, je suis persuadé qu'il te répondra.

Je suppose que ce n'est pas exprès que tu as passé sous le silenc e le
rese de la liste...

| <quote>
| La FAA, autorité de l’administration de l’aviation c ivile US, est bien
| ennuyée de voir que ce Boeing va avoir un réseau informatique o uvert à
| ses passagers. Jusque là, ce serait plutôt une bonne nouvelle q ui
| annoncer plein de solutions réseau en vol (mail, web, IM, etc.) mais
| Boeing a fait une grosse bourde : le réseau public n’est pas isolé du
| réseau de bord. Dès lors, la FAA a bien peur de voir les passag ers
| semer (volontairement ou pas) la pagaille dans les instruments de
| l’avion.
| </quote>

Donc ?

-- Gaby

Gabriel Dos Reis <gdr@cs.tamu.edu> writes:

Lucas Levrel <lucas.levrel@univ-paris12.fr> writes:

[...]

| Disons qu'il y a 60 millions de Français. Ça fait 864 ¤ par tête.

par tête travailleuse, ou juste par tête.

Notez que je ne vois pas d'inconvénient à faire payer les familles au
prorata du nombre de leurs membres. Mais j'allouerai le droit de vôte
des mineurs aux parents (ou tuteurs). En fait, avec un passage
progressif, entre 7 et 18 ans de la voix entre les parents et le
mineur.

Ainsi, une famille avec trois enfants de 6, 8 et 12 ans aurait 5 voix
aux élections, réparties comme suit:

enfant 6 ans: 0 voix
enfant 8 ans: (8-7)/(18-7) = 1/11 voix
enfant 12 ans: (12-7)/(18-7) = 5/11 voix
mère: 1 + (1 + (18-8)/(18-7) + (18-12)/(18-7))/2 = 49/22 voix
père: 1 + (1 + (18-8)/(18-7) + (18-12)/(18-7))/2 = 49/22 voix
----------------------------------------------------------------------
5 voix

Ce qui les motiverait plus et leur permettrait de pèser plus pour
élire des députés motivés à réduire les impôts...

--
__Pascal Bourguignon__

Marc Boyer a écrit :

L'industrie est une entité vague. C'est vrai que j'aurais
pu préciser "l'industrie de l'embarqué critique".

pour plagier Pierre, on y voit bcp plus clair.

Je n'ai pas connaissance d'application JavaCard embarqués
critique (critique au sens où l'erreur logicielle coute
des millions de $/¤ ou des vies humaines).

peut être parce que tu envisages l'aspect "critique" uniquement
selon certains critères principalement lié à la rareté de
l'évènement en jeu (tel un lancement de vol habité, ou un
système (satellite, sonde, ...) très coûteux) ou à la
médiatisation de la vie humaine en jeu (qui coûte chère
quand elle passe à CNN et rien à l'autre bout de la planète).

d'autres "systèmes embarqués" ont un coût unitaire faible
(de 5 à 50 euros) mais sont déployés en millions d'exemplaires
(un passeport ou une carte d'identité) ou encore pourrait
causer des pertes (cumulées) en millions d'euros si l'appli
était défaillante (cartes bancaires ou GSM).

Après, oui, il y a un fremissement autour de Java Temps
Réel (RTSJ). Après, je ne sais pas si ce sera un raz
de marée, un flop, ou un succès d'estime.

je ne parlais pas forcément de "temps réel", le traitement
des infos d'un gyroscope demande une réactivité instantanée,
le système d'un rover martien pas du tout.

Et je maintiens que, dans la communauté de l'embarqué
critique, la NASA et le DoD sont des acteurs importants,
et que leur comportement est un exemple fort.

je n'en doute pas et c'est heureux que de tels prescripteurs
(commanditaires) se donnent les moyens d'imposer en interne
et externe des cahiers des charges très stricts; pour autant
si cela créé un exemple de ce qu'il est possible d'atteindre
je ne suis pas sur que cela soit obligatoirement ce qui doit
être systématiquement atteint - de nombreux domaines de
l'industrie (soft pur, domotique, électronique grand public,
etc) continueront avec "raison économique" à faire du code
plus crade et plus risqué (ie prompt à planter).

en ce sens je dirais que leur comportement est une référence
forte, pas nécessairement un exemple (à suivre) fort.

Sylvain.

Sylvain SF, le 07/07/2009 a écrit :

[...]

je ne parlais pas forcément de "temps réel", le traitement
des infos d'un gyroscope demande une réactivité instantanée,

Pas tant que ça. Les infos d'un gyroscope varient - normalement - comme
la position dans l'espace du mobile auquel il est lié. Très lent en
général, si on compare avec les possibilités de réactivité de n'importe
quel système vaguement informatique.

le système d'un rover martien pas du tout.

Encore que face à un petit bonhomme vert et face au problème de la
boucle avec la Terre, il faudra bien réagir intelligemment et
rapidement. Mais effectivement à une autre échelle temporelle...

--
Pierre Maurette

Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :

Je n'ai pas connaissance d'application JavaCard embarqués
critique (critique au sens où l'erreur logicielle coute
des millions de $/¤ ou des vies humaines).

Un terminal de paiement, ça peut couter des millions si ça se troue...

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

Gabriel Dos Reis a écrit :

| Par exemple:
| Boeing 787 software. Entirely written in C++, using STL.

| Et le software de quoi ? Du réseau interne ?

Tu peux demander à Bjarne -- au cas où tu as des doutes sur ce qu'il
dit, je suis persuadé qu'il te répondra.

le point n'a jamais été: faut-il douter de qu'il dit (écrit!).
il introduit d'ailleurs lui-même cette liste par un "j'ai pas
vérifié moi-même".

l'argument me semble plus ici être la valeur comme référence
des cas donnés. même sous cet angle, c'est une critique biaisée
car Bjarne n'affirme pas que ces codes soient pertinents parce
qu'ils ont été écrits en C++ - Boeing a peut être fait une annerie
en mélangeant ses réseaux, qu'importe grâce à C++ ils ont fait
cela efficacement (à nouveau il n'y a aucune ironie).

Je suppose que ce n'est pas exprès que tu as passé sous le silence
le reste de la liste...

il faut faire une revue de la liste ?
en extirper un exemple où des erreurs (de logiques sans rapport
avec l'implémentation) ont peut être commisses ne remet pas en
cause la liste, d'autres exemples qui n'auraient aucun défaut
n'ajoute rien à cette liste.

de fait, bien au delà de l'histoire individuelle des cas cités
c'est l'existence même de cette liste qui m'interpelle.
as-tu discuté de celle-ci avec Bjarne pour pouvoir nous résumer
sa motivation ?
en 2009, je penserais naïvement qu'une liste des sociétés écrivant
de très gros codes en autre chose que C++ pourrait être pertinente
pour rire un peu de leur archaïsme car on s'attend plutôt à ce que
tous les éditeurs utilisent un compilo C++ (oui, oui, hormis les cas
très "critiques" où ils n'ont pas le choix).

en clair, il y a 10+ ans j'aurais compris la motivation d'une telle
liste comme un témoignage de "ils ont cru en nous (notre langage,
nos règles, ...) et nous ont suivi voici leur success-story", mais
en 2009 ?!...

Sylvain.

Sylvain SF <sylvain@boiteaspam.info> writes:

| Gabriel Dos Reis a écrit :
| >
| > | Par exemple:
| > | Boeing 787 software. Entirely written in C++, using STL.
|
| > | Et le software de quoi ? Du réseau interne ?
| >
| > Tu peux demander à Bjarne -- au cas où tu as des doutes sur c e qu'il
| > dit, je suis persuadé qu'il te répondra.
|
| le point n'a jamais été: faut-il douter de qu'il dit (écri t!).

Je crois qu'on peut faire l'hypotrhèse qu'il est honnête et que s 'il y a
une erreur de sa part, il la corrigera, et que si la personne qui lui
fournit l'information lui a menti (à son insue) il n'y peut rien.

Et comme il le dit lui même, il n'a pas vérifié par lui mà ªme *toutes* les
informations qui lui ont été communiquées -- cela ne veut pa s dire qu'il
n'en a vérifié aucun.

En ce qui concerne les informations sur JPL (Mars Rover), ou JSF
C++ Rules, il est relativement safe de supposer qu'il les as vérifià ©es
d'une manière ou d'une autre.
On peut noter par exemple, qu'il travaille sur des projets en commun
avec les gens de la NASA directement impliqués dans certains de ces
softs.

* Damian Dechev, Nicolas Rouquette, Peter Pirkelbauer, and Bjarne
Stroustrup: Programming and Validation Techniques for Reliable
Goal-driven Autonomic Software. Book Chapter in Autonomic
Communication, Vasilakos, A.; Parashar, M.; Karnouskos, S.;
Pedrycz, W. (Eds.), ISBN: 978-0-387-09752-7, Springer, May 2009.

http://www.research.att.com/~bs/autonomics09.pdf

* Damian Dechev, Peter Pirkelbauer, Nicolas Rouquette, and Bjarne
Stroustrup: Semantically Enhanced Containers for Concurrent
Real-Time Systems. Proc. 16th Annual IEEE International Conference
and Workshop on the Engineering of Computer Based Systems (IEEE
ECBS). April 2009.

http://www.research.att.com/~bs/sec09.pdf

* Damian Dechev and Bjarne Stroustrup: Reliable and Efficient
Concurrent Synchronization for Embedded Real-Time
Software. Proc. 3rd IEEE International Conference on Space Mission
Challenges for Information Technology (IEEE SMC-IT). To appear July
2009.

[...]

| > Je suppose que ce n'est pas exprès que tu as passé sous le si lence
| > le reste de la liste...
|
| il faut faire une revue de la liste ?

pas forcément, mais si tu vas à pêche de choses comme la 78 7 (« ça ne
vole pas encore »), il faudrait aussi signaler le reste -- ne serait-ce
que pour indiquer une certaine bonne foi.

| en extirper un exemple où des erreurs (de logiques sans rapport
| avec l'implémentation) ont peut être commisses ne remet pas en
| cause la liste, d'autres exemples qui n'auraient aucun défaut
| n'ajoute rien à cette liste.
|
| de fait, bien au delà de l'histoire individuelle des cas cités
| c'est l'existence même de cette liste qui m'interpelle.
| as-tu discuté de celle-ci avec Bjarne pour pouvoir nous résumer
| sa motivation ?

Cela fait partie de nos sujets de discussion. Une des motivations est
de mettre fin à certaines FUD qui ont la vie dure (on en vue dans le
thread mère.). Je peux te dire qu'il n'augmente pas la liste juste
comme ça parce que quelqu'un lui a dit qu'il a un soft en C++. (Essaie
voir :-). En fait, il est très concient qu'elle va attirer des gens qui
seront à la recherche du moindre petit détail pour remettre le to ut en
question. Donc, tu peux imaginer qu'il fait un grand effort personnel
pour s'assurer que ce qu'il écrit correspond à la réalità © (telle qu'il
pouvait la déterminer.)

| en 2009, je penserais naïvement qu'une liste des sociétés écrivant
| de très gros codes en autre chose que C++ pourrait être pertine nte
| pour rire un peu de leur archaïsme car on s'attend plutôt à   ce que
| tous les éditeurs utilisent un compilo C++ (oui, oui, hormis les cas
| très "critiques" où ils n'ont pas le choix).

En fait , le but n'est pas de lister de grosses boîtes comme cela (qui
pourrait y voir une occasion de publicité gratuite). Je crois qu'il
essaie d'expliquer cela dans l'introduction.

| en clair, il y a 10+ ans j'aurais compris la motivation d'une telle
| liste comme un témoignage de "ils ont cru en nous (notre langage,
| nos règles, ...) et nous ont suivi voici leur success-story", mais
| en 2009 ?!...

Les FUDs ont la vie dure -- c'est pour cela.

-- Gaby