INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
Le dispositif de contrôle 140 peut comprendre un premier module de contrôle 141 apte à générer des premiers signaux de contrôle pour réaliser la fonction primaire du dispositif principal 120 par le contrôle de l’actionneur 130. La génération de premiers signaux de contrôle par le premier module 141 peut être mise en œuvre sur la base de données d’au moins un capteur 150.1 du véhicule 10. Le véhicule 10 peut comprendre n capteurs 150.1, 150.2 à 150.n, n pouvant être un entier supérieur ou égal à 1.
Aucune restriction n’est attachée au type de capteur 150.1 du véhicule 10. Par exemple, le véhicule peut comprendre : - un accéléromètre ; - un radar et/ou lidar ; - un capteur de proximité ; - une caméra ; - un capteur de température ; et/ou - tout capteur apte à acquérir des données d’environnement du véhicule 10 ou de fonctionnement du véhicule 10, tels que des valeurs de consignes d’accélération ou de freinage par exemple.
Les premiers signaux de contrôle peuvent ainsi être générés en fonction de premiers paramètres estimés à partir des données de l’au moins un capteur. Lorsque le dispositif principal 120 est de type AGS réalisant une fonction thermique de refroidissement, les premiers paramètres peuvent être : - la température du véhicule 10 ; - la puissance moteur estimée, par exemple en fonction de consignes d’accélération du conducteur ; - la vitesse du véhicule 10 ; - la température de l’air.
Ces paramètres sont issus de plusieurs capteurs distincts. A partir de ces paramètres, le premier module de contrôle 141 peut déterminer un signal de contrôle correspondant au flux d’air requis pour refroidir le moteur.
L’actionneur 130 est ainsi contrôlé par le premier module de commande 141 pour la réalisation de la fonction primaire par le dispositif principal 120. Selon l’invention, le dispositif de projection en champ proche 110 est agencé de manière à ce que l’action mécanique de l’actionneur 130 sur le dispositif principal 120 induise une variation du faisceau lumineux projeté sur le sol par le dispositif de projection lumineuse en champ proche 110. A cet effet, le dispositif de projection lumineuse en champ proche 110 est agencé de manière à ce que l’action mécanique de l’actionneur 130 soit apte à faire varier la position d’au moins un élément du dispositif de projection lumineuse en champ proche 110.
Il est ainsi rendu possible de faire varier la projection lumineuse en champ proche sans induire d’encombrement additionnel ni de coût supplémentaire, puisqu’une partie de l’action mécanique appliquée par l’actionneur 130 est prélevée pour faire varier la projection lumineuse au sol du dispositif de projection lumineuse en champ proche 110.
illustre schématiquement un dispositif de traitement configuré pour aider la mise à jour d’au moins un logiciel comme illustré en figures 1-9, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention ; et
illustre un diagramme de différentes étapes d’un procédé de traitement d’au moins un logiciel de véhicule comme illustré en figures 1-2, selon au moins un exemple de réalisation particulier et non limitatif de la présente invention.
Description des exemples de réalisation Un procédé et un dispositif de contrôle d’un véhicule vont maintenant être décrits dans ce qui va suivre en référence conjointement aux figures 1-11. Sauf indications contraires, les éléments communs ou analogues à plusieurs figures portent les mêmes signes de référence et présentent des caractéristiques identiques ou analogues, de sorte que ces éléments communs ne sont généralement pas à nouveau décrits par souci de simplicité.
Les termes « premier(s) » (ou première(s)), « deuxième(s) », etc.) sont utilisés dans ce document par convention arbitraire pour permettre d’identifier et de distinguer différents éléments (tels que des opérations, des programmes d’ordinateur, des versions de logiciel, etc.) mis en œuvre dans les modes de réalisation décrits ci-après.
Comme précédemment indiqué, l’invention vise notamment un procédé de traitement mis en œuvre par un dispositif de traitement pour aider (ou simuler, ou ou permettre, ou faciliter) la mise à jour d’au moins un logiciel implémentable (ou implémenté) dans un groupe d’au moins un véhicule, tels que des véhicules de type automobile ou autre, ou plus généralement dans des véhicules de type véhicule terrestre motorisé.
Selon un exemple particulier et non limitatif de réalisation, le procédé de traitement de la présente invention comprend : - détermination d’un nombre N de versions possibles que peut présenter ledit au moins un logiciel, N étant un entier au moins égal à 2, les N versions étant organisées selon un ordre chronologique depuis une version la plus ancienne jusqu’à une version la plus à jour ; - détermination d’une profil P de mise à jour définissant au moins une condition à respecter par une mise à jour dudit au moins logiciel depuis une version initiale vers une version cible dudit logiciel ; et - détermination, à partir du nombre N et du profil P, d’un indice de complexité C représentatif d’une complexité dudit au moins logiciel ; et - évaluation d’une capacité à mettre à jour ledit au moins un logiciel par comparaison de l’indice de complexité C avec une valeur de référence.
Comme indiqué précédemment, il a été observé que la capacité de maintenance et d'évolution des logiciels embarqués dans des véhicules est étroitement dépendante de la complexité des logiciels concernés. L’invention repose donc en particulier sur une solution rapide et efficace pour évaluer la complexité d’un ou d’une pluralité de logiciels de véhicule, afin d’aider à mettre à jour ces logiciels. Cette solution implique notamment l’introduction d’une nouvelle métrique représentative de la complexité d’un ou plusieurs logiciels de véhicule. Cette nouvelle métrique, dite indice de complexité (ou indice de complexité logicielle), capable d’être déterminée rapidement et à faible coût en ressources, permet de représenter de façon fiable la complexité d’un code logiciel pour véhicule et/ou la complexité d’une plateforme technologique associée (par exemple de type OTA).
A partir de cette indice de complexité, on peut ainsi évaluer une capacité à mettre à jour le ou les logiciels concernés. Pour ce faire, une comparaison est réalisée entre l’indice de complexité et une valeur de référence dont la nature peut varier selon le cas. Il est par exemple possible, à partir du résultat de cette comparaison, de détecter ou anticiper des risques ou problèmes liés à une mise à jour ou encore de concevoir ou adapter ladite mise à jour avant son application sur le ou les logiciels concernés.
La illustre schématiquement un dispositif de traitement 10 configuré pour aider ou faciliter la mise à jour d’au moins un logiciel PG1 implémentable dans un groupe 3 d’au moins un véhicule 2. Le dispositif 10 et le groupe 3 d’au moins un véhicule 2 forme ensemble un système SY1.
Ce dispositif de traitement (dit aussi dispositif de modélisation ou dispositif) 10 vise en premier lieu à aider ou faciliter la mise à jour du ou des logiciels PG1 destinées à être implémentés dans les véhicules 2. Le dispositif 10 peut ainsi simuler ou modéliser la ou les mises à jour à réaliser sur ces logiciels PG1. De cette manière, on peut notamment détecter des situations critiques et/ou adapter une stratégie de mise à jour. Comme décrit plus en détail ultérieurement, le dispositif 10 peut éventuellement être en outre configuré pour réaliser les mises à jour elles-mêmes.
Comme illustré en , on considère ici un groupe (ou parc) 3 d’une pluralité de véhicules 2, bien que l’invention soit également applicable pour un seul véhicule 2. Autrement dit, l’invention peut s’appliquer plus généralement à un groupe 3 d’au moins un tel véhicule 2.
Le type et les caractéristiques des véhicules 2 peuvent être adaptés selon le cas. Les véhicules 2 sont par exemple de type automobile ou équivalent. En variante, chaque véhicule 2 peut être un car, un bus, un camion, un véhicule utilitaire ou une motocyclette, ou plus généralement un véhicule de type véhicule terrestre motorisé, voire un véhicule maritime (ou fluvial) ou aérien.
Chaque véhicule 2 du groupe 3 embarque au moins un logiciel PG1 implémenté dans au moins un dispositif embarqué 4. On considère par la suite à titre d’exemple que les véhicules 2 embarquent chacun au moins un calculateur 4 configuré pour implémenter un logiciel PG1. A noter toutefois que le nombre de calculateurs et de logiciels PG1 implémentés peuvent varier selon le cas.
On suppose par la suite que chaque calculateur 4 est configuré pour implémenter un même logiciel PG1, ce logiciel pouvant éventuellement comprendre une pluralité de logiciels ou sous-logiciels. Comme décrit ci-après, la version du logiciel PG1 implémenté dans chaque véhicule 2 peut toutefois varier.
Chaque véhicule 2 peut par exemple comprendre un ou une pluralité de calculateurs 4. Selon un exemple particulier, les véhicules 2 comprennent un calculateur central 4 coopérant avec au moins un autre calculateur secondaire 4.
Selon une caractéristique de l’invention, le serveur informatique est configuré pour calculer au moins une évolution relative aux sons cardiaques et/ou à une période de prééjection et/ou à une fréquence respiratoire et/ou à une fréquence cardiaque au moyen des données collectées par l’implant sous-cutané.
Selon une caractéristique de l’invention, l’accéléromètre est apte à calculer des accélérations linéaires selon trois axes orthogonaux, le serveur informatique étant configuré pour calculer les évolutions d’au moins un paramètre hémodynamique et/ou respiratoire sur la base notamment d’une donnée de l’accéléromètre relative à au moins l’un desdits axes.
Selon une caractéristique alternative de l’invention, l’accéléromètre est un accéléromètre simple, configuré pour détecter une accélération linéaire selon un unique axe, le serveur informatique étant configuré pour calculer les évolutions d’au moins un paramètre hémodynamique et/ou respiratoire sur la base notamment d’une donnée acquise sur un axe par l’accéléromètre.
Selon une caractéristique de l’invention, un algorithme est implémenté sur le serveur informatique, ledit algorithme étant configuré pour analyser les données acquises et transmises par l’implant sous-cutané de sorte à évaluer le risque de survenance d’un épisode de décompensation de l’insuffisance cardiaque.
L’invention porte également sur un procédé de communication pour un système de surveillance tel qu’évoqué précédemment, le procédé de communication mettant en œuvre : - au moins une première étape au cours de laquelle le relais de communication scanne l’espace environnant pour détecter l’implant sous-cutané, - au moins une première étape additionnelle au cours de laquelle l’implant sous-cutané génère un signal d’avertissement précisant que des données relatives au fonctionnement du cœur sont aptes à être échangées avec le serveur informatique, - au moins une deuxième étape au cours de laquelle des données ou des instructions de commande sont échangées entre l’implant sous-cutané et le serveur informatique par l’intermédiaire du relais de communication, le réseau de communication sans fil, à basse consommation, mis en œuvre pour la communication entre l’implant sous-cutané et le relais de communication étant distinct du réseau de communication sans fil, à haut débit, mis en œuvre pour la communication entre le relais de communication et le serveur informatique.
Le relais de communication est apte à scanner l’espace environnant sur un rayon d’environ 5 mètres autour du relais de communication à la recherche d’un signal émis par l’implant sous-cutané. Une telle distance de détection du relais de communication limite la possibilité à des dispositifs étrangers de se connecter au relais de communication.
Selon une caractéristique de l’invention, le procédé de communication met en œuvre au moins une deuxième étape auxiliaire intervenant avant la deuxième étape et au cours de laquelle le relais de communication détecte l’implant sous-cutané et envoie au serveur informatique une requête d’identification de l’implant sous-cutané, le serveur informatique traitant ladite requête d’identification en envoyant à l’implant sous-cutané, via le relais de communication, une clé de chiffrement spécifique audit implant sous-cutané et une requête de récupération de données et/ou une instruction de commande.
On entend que le serveur informatique « traite » la requête d’identification dans la mesure où le serveur informatique est configuré pour, au moyen de la requête d’identification, identifier l’implant sous-cutané et choisir l’action à réaliser en fonction de cette identification de l’implant sous-cutané. Lorsque le serveur informatique a reconnu l’implant sous-cutané via la requête d’identification, le serveur informatique peut ainsi décider qu’aucune action n’est nécessaire, par exemple qu’une remontée de données depuis l’implant n’est pas nécessaire, de sorte que la communication n’est pas établie entre l’implant et le serveur informatique. Une information en ce sens peut être envoyée à l’implant via le relais de communication. Lorsque le serveur informatique a reconnu l’implant sous-cutané via la requête d’identification, le serveur informatique peut décider qu’une remontée de données acquises par l’implant est nécessaire ou bien que l’envoi de nouveaux paramètres de fonctionnement à destination de l’implant est nécessaire. Le serveur informatique est alors configuré pour transmettre, outre l’instruction de récupération de données et/ou l’instruction de commande, une clé de chiffrement unique et spécifique à l’implant pour que celui-ci puisse reconnaitre que la communication provient bien d’un serveur informatique autorisé et ne consiste pas en une tentative de piratage de données.
L’instruction de commande envoyée à l’implant sous-cutané peut contenir des instructions visant à modifier les paramètres de fonctionnement de l’implant sous-cutané, par exemple la fréquence d’acquisition de données.
Il convient de noter que la requête d’identification émise par l’implant sous-cutané comprend des informations qui sont spécifiques à cet implant sous-cutanée. Par exemple, la requête d’identification peut comporter le numéro de série de l’implant sous-cutané et l’adresse MAC de la connexion BLE mise en œuvre par l’implant sous-cutané. Cette requête d’identification permet au serveur informatique de reconnaitre l’implant sous-cutané qui a été détecté par le relais de communication, et d’adapter l’envoi d’informations à destination de l’implant sous-cutané, telles que les instructions de commande et/ou une requête de récupération de données, en fonction de l’implant sous-cutané qui a été reconnu.
Dans une version du procédé de communication, les données collectées par l’implant sous-cutané transitent par le relais de communication, c'est-à-dire que ces données ne sont pas conservées dans le relais de communication. En d’autres termes, on comprend que le relais de communication permet, dans cette version du procédé de communication, de faire transiter les données collectées par l’implant sous-cutané entre ledit implant sous-cutané et le serveur informatique et qu’il n’opère pas de traitement desdites données collectées par l’implant-sous-cutané. Ceci présente un avantage en termes de sécurité des données puisque le relais de communication n’a pas à être protégé aussi efficacement que doit l’être, par exemple, le serveur informatique.
Selon une caractéristique de l’invention, le relais de communication est configuré pour pouvoir conserver de façon temporaire les données en provenance de l’implant sous-cutané En d’autres termes, dans un mode de fonctionnement standard, c’est-à-dire sans dysfonctionnement du réseau de communication entre le relais de communication et le serveur informatique et sans dysfonctionnement de la connexion BLE entre le relais de communication et l’implant sous-cutané, le relais de communication ne stocke pas les données, tandis que dans un mode de fonctionnement dégradé, avec un dysfonctionnement potentiel ou avéré des moyens de communication, le relais de communication stocke temporairement les données jusqu’à ce que les moyens de communication soient rétablis.
On comprend que dans cette version du procédé de communication, le relais de communication est apte à conserver les données collectées par l’implant sous-cutané dans l’éventualité où le serveur informatique est indisponible et donc dans l’éventualité où le transfert d’informations du relais de communication vers le serveur informatique est impossible. Une telle version du procédé de communication permet de s’assurer que les données collectées par l’implant sous-cutané ne sont pas perdues en cas d’indisponibilité du serveur informatique.
Selon une autre caractéristique de l’invention, le relais de communication est apte à conserver temporairement au moins des informations transmises par le serveur informatique comprenant une instruction de commande et une clé de chiffrement spécifique à un implant sous-cutané, permettant au relais de communication de se connecter à cet implant sous-cutané.
Par « temporairement », on entend que le relais de communication conserve les informations transmises par le serveur informatique jusqu’à la prochaine connexion entre le relais de communication et l’implant sous-cutané.
Dans ce mode de réalisation, on comprend que lorsque le relais de communication détecte la présence de l’implant sous-cutané et que ledit implant sous-cutané signale qu’il a des données à transmettre, le relais de communication est en capacité d’établir la connexion avec l’implant sous-cutané sans l’intermédiaire du serveur informatique.
est un agrandissement d’une partie de la vue en perspective représentée sur la ;
illustre schématiquement une variante de réalisation de l’ensemble composé du support de câble et du support intermédiaire, déjà représentés sur les , et ;
illustre schématiquement et en perspective un assemblage de supports de câble sur un même support intermédiaire, selon un mode de réalisation ;
illustre schématiquement des moyens de fixation d’un support de câble sur un support intermédiaire, selon un mode de réalisation ;
est une vue partielle des supports représentés sur la et illustre des détails des moyens de fixation entre un support de câble et un support intermédiaire ; et,
illustre un aéronef comprenant un support de câble ou un ensemble support de câble, selon un mode de réalisation.
La est une représentation schématique d’un ensemble 1 de support de câble (au sens de conducteur électrique) configuré pour supporter un ou plusieurs câbles. L’ensemble support de câble comprend un support de câble 1a ainsi qu’un support intermédiaire 1b faisant office de piètement pour le support de câble 1a. Dans la présente description, le terme « support de câble » désigne un élément configuré pour porter, maintenir, fixer, guider ou positionner un ou plusieurs câbles selon un placement prédéfini ou encore pour porter, maintenir, fixer, guider ou positionner un toron ou un faisceau (c’est-à-dire un assemblage de câble, parfois nommé « câblage », éventuellement structuré d’une certaine façon). Le terme « ensemble support de câble » désigne quant à lui un ensemble d’éléments comprenant un support de câble tel que défini ci-avant et un support intermédiaire configuré pour supporter lui-même un support de câble. Un tel ensemble peut être compris dans un kit de support de câble comprenant en outre des éléments accessoires, tels qu’un ou plusieurs colliers de serrage, de la visserie, etc. Le support intermédiaire 1b est prévu pour maintenir le support de câble 1a. Avantageusement, le support intermédiaire 1b peut servir à maintenir plusieurs supports de câble semblables au support de câble 1a. Le support intermédiaire 1b est nommé support intermédiaire en ce sens qu’il opère une fonction de support de support de câble.
Selon une variante de réalisation, les mors 13 et 14 ainsi que la partie terminale 18 peuvent comprendre chacun plusieurs ouvertures configurées pour le passage d’un collier autobloquant de sorte qu’un premier collier puisse être dédié à une bonne fermeture de l’anneau ouvert 10 autour d’un câble inséré dans l’ouverture traversante 11 et un deuxième collier puisse garantir un bon maintien en position du support de câble 1a sur le support intermédiaire 1b.
Avantageusement, le mors 13 présente des cannelures sur sa face « intérieure » faisant face au mors 14 pour mieux agripper la partie terminale 18 lorsque celle-ci est insérée entre les mors 13 et 14. Avantageusement encore, la partie terminale 18 présente des cannelures de formes complémentaires aux formes des cannelures du mors 13 et/ou du mors 14 pour opérer un bon maintien en position de la partie terminale 18 entre les mors 13 et 14. Selon un mode de réalisation, chacun des mors 13 et 14 présente des cannelures et la partie terminale 18 présente des cannelures sur l’une seulement de ses faces ou encore sur ses deux faces.
Selon un mode de réalisation, les cannelures des mors 13 et 14 sont agencées perpendiculairement par rapport à la direction selon laquelle s’étendent les mors à partir de l’anneau ouvert 10 formant le corps du support de câble 1a. Selon cet exemple, les cannelures de la partie terminale 18 s’étendent perpendiculairement à la direction selon laquelle s’étend la partie terminale 18 à partir de l’extrémité de la jambe 17 opposée à l’embase 16, de sorte que les cannelures du ou des mors et les cannelures de la partie terminale 18 soient parallèles entre elles, et donc de formes complémentaires. Avantageusement, les cannelures présentent chacune un profil en forme de triangle, permettant une insertion aisée de la partie terminale 18 tout en opérant chacune un rôle de butée anti-retour pour faciliter le maintien en position lors du montage. Bien évidemment, cet exemple de réalisation n’est pas limitatif et d’autres profils de cannelures peuvent être utilisés (semi-circulaires, en créneaux, etc.).
La est une vue en perspective de l’ensemble support de câble 1 composé du support de câble 1a et du support intermédiaire 1b. L’ensemble 1 est vu ici lorsqu’un collier de serrage 12 est inséré à travers les ouvertures traversantes 13a, 14a et 18a et à travers les boucles de matière 10a et 10b, opérant à la fois une fermeture de l’anneau ouvert 10 et un verrouillage en position du support de câble 1a sur le support intermédiaire 1b. La est une vue agrandie de la portion de l’ensemble 1 illustrant de façon détaillée le positionnement de la partie terminale 18 du support intermédiaire 1b entre les mors 13 et 14 du support de câble 1a. Selon l’exemple décrit, le mors 13 présente des cannelures sur sa face intérieure faisant face au mors 14, lesquelles cannelures sont de formes complémentaires aux cannelures de la partie terminale 18. En fonction de l’écartement entre les mors 13 et 14, au regard de l’épaisseur de la partie terminale 18, les cannelures ne sont pas forcément utiles si le nombre de câbles que porte le support de câble 1a est réduit, et la illustre un exemple de réalisation où le support de câble 1a ainsi que le support intermédiaire 1b sont dépourvus de cannelures. Une telle configuration opère toutefois un maintien en position moins précis entre le support de câble 1a et le support intermédiaire 1b qu’en présence de cannelures.