ARM propose ses solutions spécialement destinées au marché des véhicules autonomes, Réactions à la publication du 27/09/2018 |
Bienvenue invité ( Connexion | Inscription )
ARM propose ses solutions spécialement destinées au marché des véhicules autonomes, Réactions à la publication du 27/09/2018 |
27 Sep 2018, 06:54
Message
#1
|
|
BIDOUILLE Guru Groupe : Admin Messages : 55 335 Inscrit : 14 Jan 2001 Lieu : Paris Membre no 3 |
Le marché des smartphones est celui qui rapporte le plus à nombre de sociétés dont ARM.
Il est le présent commercial mais le futur semble se jouer ailleurs, sur les véhicules autonomes. Tous les industriels s'y intéressent de très près. Jusqu'à maintenant ARM proposait des solutions dérivées d'autres marchés pour tenter de se faire sa place dans les voitures de demain. Elle a annoncé des développements spécifiques qui prendront la forme d'une R&D dédiée et d'un plan pluriannuel. C'est en particulier le cas pour un projet appelé Arm Safety Initiative qui vise à augmenter considérablement le niveau de sécurité de ses puces, que ce soit en fiabilité ou en renforcement de la sécurité pour éviter toute prise de contrôle. La première puce annoncée est le Cortex-A76AE, très loin de ce que l'on trouve dans un iPhone avec une consommation de 30W. Dans le futur, d'autres puces estampillées AE seront proposées. Lien vers le billet original -------------------- C'est parce que la vitesse de la lumière est plus grande que celle du son que tant de gens paraissent brillants avant d'avoir l'air con
|
|
|
27 Sep 2018, 09:08
Message
#2
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 1 844 Inscrit : 21 Jan 2010 Lieu : Vancouver BC Membre no 149 008 |
Comme le dit Cuk la paranoîa de Mojave est pénible. Comment ARM résoud cet aspect?
|
|
|
27 Sep 2018, 12:04
Message
#3
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 15 378 Inscrit : 4 Jan 2006 Lieu : dtq Membre no 52 877 |
Mouaip c'est principalement suivre des standards (bienvenu ceci dit) à tous les niveaux et la possibilité de faire fonctionner les cœurs par paire pour vérifier à chaque cycle que les résultats sont identiques, ce qui protège d'un dysfonctionnement rare (mais dans ce cas le système fait quoi puisqu'il n'y a pas de 3ème pour arbitrer?!?), mais certainement pas d'une erreur de conception bien plus courante puisque nos CPU sont truffées de bugs dû à leur complexité.
Ça me laisse perplexe, à la fois l'absence d'arbitrage pour s'assurer de la continuité de service en cas de dysfonctionnement d'un cœur dans un engin aussi critique pour la sécurité physique des personnes, mais aussi de ne pas aborder frontalement le problème de la complexité qui amène mécaniquement des bugs de conception. Ce message a été modifié par iAPX - 27 Sep 2018, 12:04. -------------------- Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
|
|
|
27 Sep 2018, 18:21
Message
#4
|
|
Adepte de Macbidouille Groupe : Membres Messages : 152 Inscrit : 20 Dec 2008 Membre no 127 788 |
Pour l’automobile, ça veut essentiellement s’assurer de respecter la norme ISO26262. On estime en général que pour un niveau d’ASIL C, il faut compter facilement +50% d’effort de R&D par rapport à un produit sans contrainte de sécurité de fonctionnement. Mais la référence de qualité de développement étant déjà relativement plus élevée dans l’industrie auto que dans l’electronique grand public, on doit certainement avoir des valeurs encore supérieures.
|
|
|
27 Sep 2018, 18:55
Message
#5
|
|
Macbidouilleur d'Or ! Groupe : Membres Messages : 15 378 Inscrit : 4 Jan 2006 Lieu : dtq Membre no 52 877 |
Pour l’automobile, ça veut essentiellement s’assurer de respecter la norme ISO26262. On estime en général que pour un niveau d’ASIL C, il faut compter facilement +50% d’effort de R&D par rapport à un produit sans contrainte de sécurité de fonctionnement. Mais la référence de qualité de développement étant déjà relativement plus élevée dans l’industrie auto que dans l’electronique grand public, on doit certainement avoir des valeurs encore supérieures. Désolé mais pour ce qui concerne les cœurs de CPU, ils sont testables tellement partiellement que c'en est presque un gag surtout depuis le passage au 64bits, sans parler même des possibilité d'incorporer des backdoors de la part de certains fondeurs dans le dos du client. Quand à avoir 2 cœurs se surveillant mutuellement c'est le plus gros gag: que se passe-t'il en cas de désaccord entre les deux? La seule solution est d'arrêter de les utiliser immédiatement en plein milieu d'un process qu'il faut donc relancer sur un couple d'autres cœurs en espérant qu'ils soient disponible?!? Ou d'arrêter le process et on en parle plus? C'est couplé au niveau des bus interne des cœurs, ou alors au niveau du bus système (au-dessus des caches L1 et L2 alors) ? Dans le premier cas ça ne détecte pas les erreurs des caches, pourtant vu leur nombre de transistors... Dans le second cas ça peut détecter une erreur longtemps après qu'elle soit commise, lors de l'éviction du cache, et s'être propagé à un autre process (partage mémoire, queue en mémoire partagée, etc.), et faire arrêter un autre process que le responsable! Tout ça est tout sauf transparent (ce que prétendu) et repose sur des systèmes sophistiqué de transactions pour réussir (NetBeans venez à mon secours! lol) Tout ça me parait plus de la poudre aux yeux que de la sécurité, puisque quand on arbitre à deux on doit basculer sur un dispositif séparé en cas de désaccord (pas sur la même CPU donc, voir pas le même module électronique), sinon il faut un arbitrage à 3, bien plus solide en cas de défaillance et non-supporté. C'est bien d'avoir une initiative, mais si elle était sérieuse on aurait des détails techniques plus pointus permettant de se faire une idée... PS: après la sécurité qu'on laisse tomber, on s'engage dans des voies totalement irrationnelles pour limiter les bugs avec des objectifs intenables (et d'ailleurs pas tenus puisque les bugs de conception passeront au travers des mailles du filet), pour finalement arriver à des dispositif s'arrêtant sur des problèmes plutôt liés à la fabrication et aux conditions d'exécution. Aucune garantie pour la sécurité physique des personnes... Ce message a été modifié par iAPX - 27 Sep 2018, 21:44. -------------------- Utilisateur de Mac depuis 1985 et possesseur de Mac depuis 2005. Utilisateur d'un PC Lenovo au travail, sous Windows, qui renforce ma passion pour les Mac!
|
|
|
28 Sep 2018, 04:39
Message
#6
|
|
Macbidouilleur d'argent ! Groupe : Membres Messages : 692 Inscrit : 13 Jul 2011 Membre no 168 785 |
Quand à avoir 2 cœurs se surveillant mutuellement c'est le plus gros gag: que se passe-t'il en cas de désaccord entre les deux? Le développeur a la main dans ce cas. C'est pas idiot en soit, c'est efficace et simple à la fois, pour un coût plutôt raisonnable. Après, l'intérêt du truc, comme toi, j'ai un peu de mal. Le truc tel que présenté va détecter une erreur de calcul ou une erreur de cache bas level. Autant dire rien. Bug de l'archi, erreur de code, erreur de mémoire sont infiniment plus probables. Tu as lâché le terme exact à mon sens: poudre aux yeux. Après, l'idée même d'utiliser des CPU généralistes en parlant de sécurité critique, c'est risible donc... |
|
|
Nous sommes le : 18th April 2024 - 02:29 |