INPI-France/Brevets-Francais-2024-Chunked huggingface dataset:
La réponse à une requête pour joindre un peloton comprend des données de position du véhicule 10 automobile source de cette réponse. Dans un mode de réalisation, les requêtes et réponses pour joindre un peloton font partie d'un protocole de communication standardisé entre les véhicules.
Le système 1 de conduite en peloton est configuré pour déterminer, pour chaque réponse reçue, si le véhicule automobile source de cette réponse est dans une zone prédéfinie autour du véhicule 10 automobile. Plus généralement, le système 1 de conduite en peloton détecte la présence dans ladite zone prédéfinie d'un véhicule automobile source d'une réponse reçue. Dans un mode de réalisation, le système 1 de conduite en peloton détecte par géo-repérage (ou par gardiennage virtuel, plus connu sous le nom anglais « geofencing») la présence d'un véhicule automobile source d'une réponse reçue dans ladite zone prédéfinie. Cette zone s'étend sur une distance prédéfinie autour du véhicule automobile. Dans un mode de réalisation, cette zone couvre la voie de circulation du véhicule 10 automobile et la ou les voies de circulation qui lui sont adjacentes de même sens de circulation que la voie de circulation du véhicule 10 automobile. Cette zone orientée définie le périmètre dans lequel un peloton peut être proposé. Le véhicule automobile détecté par le système 1 de conduite en peloton circule donc dans le même sens de circulation que le véhicule 10 automobile et est situé à une distance inférieure à une distance seuil prédéfinie du véhicule 10 automobile (ou, de manière équivalente, se trouvant à un temps de trajet inférieur à une durée seuil prédéfinie).
Lorsqu'une pluralité de véhicules automobiles a répondu à la requête pour joindre un peloton émise par le véhicule 10 automobile, le système 1 de conduite en peloton sélectionne sur la base d'un critère prédéfini (l'inter-distance, la vitesse, le type de véhicule, la destination ou le type d'énergie par exemple) un véhicule candidat à suivre parmi ladite pluralité.
Dans un mode de réalisation, le système 1 de conduite en peloton informe le conducteur (via un écran d'affichage et/ou un message audio) du véhicule candidat sélectionné pour joindre un peloton. Ces informations comprennent, de préférence, un identifiant permettant d'identifier ce véhicule candidat (un identifiant d'immatriculation, une couleur, une marque, et/ou un type de véhicule par exemple), l'inter-distance, ou le temps nécessaire pour joindre le peloton comprenant le véhicule candidat. Dans un autre mode de réalisation, le système 1 de conduite en peloton informe le conducteur s'il s'agit d'un peloton existant ou d'un peloton à former avec le véhicule candidat.
Dans un mode de réalisation, le système 1 de conduite en peloton permet au conducteur d'accepter ou de refuser de joindre un peloton proposé. Sur confirmation du conducteur, le système 1 de conduite en peloton commande le déplacement du véhicule 10 automobile (vitesse, direction) de sorte à joindre le peloton proposé.
Pour joindre un peloton proposé, le système 1 de conduite en peloton identifie d'abord le véhicule candidat. Pour cela, des données de position et des données de proximité sont échangées entre les deux véhicules automobiles. Chacun des deux véhicules automobiles procède à une comparaison entre les données à sa disposition (données de position fournies par le module 3 de localisation et inter-distance mesurée par un capteur 4 de proximité) et les données qui lui sont communiquées via le module 2 de communication véhiculaire. Si ces données sont cohérentes, l'identification mutuelle est réussie pour le système 1 de conduite en peloton qui, de ce fait, commande le véhicule 10 automobile pour suivre le véhicule candidat dans un déplacement en convoi.
En cas d'échec de l'identification du véhicule candidat, le système 1 de conduite en peloton en déduit qu'il existe un véhicule intermédiaire entre le véhicule 10 automobile et le véhicule candidat. Dans ce cas, le système 1 de conduite en peloton détermine grâce aux données de proximité fournies par le capteur 4 de proximité si le véhicule intermédiaire circule à une vitesse inférieure à celle du véhicule 10 automobile. S'il est déterminé que le véhicule intermédiaire circule à une vitesse inférieure à celle du véhicule 10 automobile, le système 1 de conduite en peloton initie une manœuvre de dépassement du véhicule intermédiaire (lorsque le véhicule 10 automobile est entièrement automatisé) ou propose au conducteur de réaliser une manœuvre de dépassement du véhicule intermédiaire (lorsque le véhicule 10 automobile est semi-automatisé).
S'il est déterminé que le véhicule intermédiaire circule à une vitesse supérieure ou égale à celle du véhicule 10 automobile, le système 1 de conduite en peloton demande au véhicule candidat de diminuer sa vitesse en dessous d'une vitesse cible du peloton d'un premier pas prédéfini et augmente la vitesse du véhicule 10 automobile au-dessus de la vitesse cible du peloton d'un deuxième pas prédéfini (ces pas étant réglables). Ce processus est réitéré jusqu'à ce que le véhicule 10 automobile et le véhicule candidat se rapprochent l'un de l'autre et qu'aucun véhicule intermédiaire n'existe entre eux. Autrement dit, en présence d'un véhicule intermédiaire entre le véhicule 10 automobile et le véhicule candidat, une adaptation de la vitesse du véhicule 10 automobile et/ou celle du véhicule candidat permet d'écarter le véhicule intermédiaire de sorte à pouvoir établir une identification mutuelle entre le véhicule 10 automobile et le véhicule candidat et ensuite mettre en œuvre une conduite en peloton.
Dans un mode de réalisation, une fois le véhicule 10 automobile fait partie d'un peloton, le système 1 de conduite en peloton propose, dans un durée prédéfinie, au conducteur de passer de véhicule suiveur en véhicule meneur. Les véhicules du peloton passent ainsi à tour de rôle en position de véhicule meneur de façon à optimiser leur consommation énergétique de façon coopérative.
Avantageusement, les modes de réalisation décrits ci-dessus ne nécessitent pas de dispositifs supplémentaires, les capteurs de proximité (radar, lidar, caméra ou autre), les modules de localisation et/ou les systèmes de conduite en peloton étant massivement déployés dans les véhicules semi-automatisés ou entièrement automatisés. Il en résulte des faibles coûts de mise en œuvre de ces modes de réalisation qui permettent de réduire la consommation énergétique des véhicules automobiles grâce à une forte diminution de la traînée aérodynamique des véhicules automobiles du convoi.
Procédé et dispositif de contrôle d’un objet connecté La présente invention concerne les procédés et dispositifs de contrôle d’un objet connecté utilisé en association avec un véhicule, par exemple de type automobile. L’invention vise en particulier le contrôle d’un tel objet connecté pour tenir informer un utilisateur lorsque survient un évènement particulier en lien avec le véhicule.
Arrière-plan technologique Les véhicules, de type automobile ou autre, ont connus de nombreux développements et améliorations ces dernières années. Des progrès significatifs ont notamment vu le jour en ce qui concerne les systèmes de connexion, d’information et de divertissement à l’attention des utilisateurs d’un véhicule. Il est aujourd’hui courant pour les véhicules automobiles d’embarquer un système d’info-divertissement qui offre diverses fonctionnalités pour informer et divertir les occupants des véhicules.
Un système d’info-divertissement comprend généralement un écran d’affichage et un système d’exploitation apte à gérer de multiples applications, notamment des applications d’aide à la conduite (par exemple une fonction d’aide à la navigation ou fonction GPS pour « Global Positioning System »), des fonctions d’information (pour fournir par exemple des informations de circulation ou de météo) et/ou des applications de divertissement (application de musique, karaoké, service de connexion avec un téléphone mobile, jeux, etc.).
Diverses systèmes de commande sont développés par les constructeurs pour permettre un contrôle ergonomique de ces systèmes d’info-divertissement. L’usage de ces systèmes posent cependant des problèmes en pratique, notamment en termes de sécurité et d’ergonomie. Ces systèmes constituent en effet une source de distraction dangereuses pour les conducteurs, en raison notamment de la nécessité pour ces derniers de quitter la route du regard pour examiner le contenu affiché à l’écran. L’affichage répété de notifications ou l’affichage d’un quelconque contenu (de type multimédia par exemple) peut entraîner une diminution de la concentration du conducteur, être source de fatigue ou d’inconfort et engendrer des risques d’accident en raison des allers-retours répétés du regard du conducteur entre l’écran d’affichage et la route.
Ces problèmes sont amplifiés par l’accroissement des notifications et du fait que celles-ci ne sont pas toujours pertinentes pour l’utilisateur, ce qui peut susciter un désagrément pour le conducteur et limiter son expérience utilisateur.
Par ailleurs, il convient de noter que la ou les actions sélectionnées par le module 5 d’exécution peuvent être exécutées par ce dernier durant une période de temps limitée. Par exemple, le module 5 d’exécution peut, conformément à l’action ACT1, retirer l’adresse bad@IP de la liste des adresses IP pouvant être sélectionnées pour traiter les messages des équipements clients qu’il sert pendant une durée donnée désignée ici par PAUSE_TIMER. Si à l’issue de la durée PAUSE_TIMER, le module 4 de détection ne détecte plus de comportement suspect associé à l’adresse bad@IP (par exemple, il ne reçoit aucune nouvelle notification d’un système DMS ou d’un système REP_SYS portant sur cette adresse IP), dans ce cas il peut réactiver l’adresse bad@IP, autrement dit la réintégrer parmi les adresses IP de l’ensemble POOL#1 pouvant être sélectionnées pour traiter des messages parvenant à CGN#1.
Nous allons maintenant décrire plus en détail, en référence aux figures 6 et 7 , le déroulement de l’étape E50 lorsque l’action ACT3 (demande de délégation d’adresses IP à un autre NAT opérateur) est sélectionnée par le module 5 d’exécution. La illustre les étapes mises en œuvre par le NAT opérateur CGN#1 à l’origine de la demande de délégation, tandis que la illustre les étapes mises en œuvre par un NAT opérateur du système 1 recevant et acceptant cette demande de délégation (c’est-à-dire agissant en tant que deuxième dispositif au sens de l’invention). Les étapes illustrées par la correspondent à celles d’un procédé de collaboration selon l’invention. Il va de soi que bien qu’étant décrites sur la base d’un exemple illustratif, les étapes représentées dans les figures 5 à 7 s’appliquent à tous les NAT opérateur du système 1 en fonction du rôle joué par chacun d’entre eux (premier ou deuxième dispositif selon l’invention).
Dans le mode de réalisation envisagé ici, comme décrit précédemment, des canaux COGITARE ont été établis, préalablement lors de l’étape E20, par CGN#1 avec les NAT opérateurs du système 1 découverts lors de l’étape E10. Par ailleurs, lors de l’établissement de ces canaux COGITARE, CGN#1 a été informé par les NAT opérateur avec lesquels il a établi ces canaux, de leur aptitude ou non à déléguer des adresses IP à d’autres NAT opérateur du système 1. Cette information est stockée dans la table CAPA de CGN#1. Ainsi, suite à la sélection de l’action ACT3, le module 5 d’exécution de CGN#1 consulte la table CAPA et détermine à quel(s) NAT opérateur du système 1 il peut adresser sa demande de délégation d’adresses IP (il s’agit des NAT opérateur aptes à mettre en œuvre l’invention et donc susceptibles de déléguer des adresses IP, autrement dit dans l’exemple envisagé ici, ceux ayant indiqué un paramètre « delegate_resources_enable » valorisé à 1) (étape E50-1).
On note qu’en variante les étapes de découverte E10 et d’établissement E20 des canaux COGITARE peuvent être implémentées par le NAT opérateur CGN#1 après l’étape E30 de détection d’un comportement suspect associé à l’adresse bad@IP, par exemple après que le module 5 d’exécution a décidé d’exécuter l’action ACT3.
Le module 5 d’exécution de CGN#1 demande à au moins un des NAT opérateur identifiés lors de l’étape E50-1, de lui déléguer au moins une adresse IP parmi l’ensemble POOL d’adresses IP qu’il gère (étape E50-2). On note que le module 5 d’exécution peut adresser cette demande de délégation à tous les NAT opérateur identifiés lors de l’étape E50-1 ou seulement à une partie d’entre eux (il peut par exemple en choisir un aléatoirement, ou selon un critère déterminé, etc.). Par souci de simplification, on suppose ici que CGN#1 adresse sa demande de délégation à un unique NAT opérateur du système 1, à savoir au NAT opérateur CGN#2 (deuxième dispositif au sens de l’invention).
Dans le mode de réalisation envisagé ici de canaux COGITARE reposant sur le protocole QUIC, le module 5 d’exécution de CGN#1 demande une délégation d’adresses IP à CGN#2 en lui envoyant une trame QUIC, spécifiée pour les besoins de l’invention et appelée par exemple ici IP_RESOURCE_DELEGATE. Cette trame est envoyée par CGN#1 à CGN#2 via le canal COGITARE établi entre eux. Elle peut être vide (et donc ne contenir aucun paramètre), ou en variante contenir un ou plusieurs paramètres précisant la demande de CGN#1, comme par exemple un paramètre nommé ici « requested-size » indiquant une préférence concernant la taille de l’espace des adresses IP à déléguer, ou de façon équivalente un paramètre nommé ici « requested-nb » indiquant un nombre d’adresses déléguées souhaitées, un paramètre nommé ici « requested-af » indiquant le type d’adresses IP déléguées souhaitées (par exemple valorisé à 0 pour des adresses IPv4 et à 1 pour des adresses IPv6, l’absence de ce paramètre pouvant être considérée comme équivalent à une valorisation du paramètre à 0, c’est-à-dire comme désignant des adresses IPv4), etc.
Ainsi, à titre illustratif, une trame IP_RESOURCE_DELEGATE comprenant un paramètre « requested-size » valorisé à 32 (bits) et ne contenant pas de paramètre « requested-af » indique une demande de délégation d’une unique adresse IPv4 (le paramètre « requested-size » combiné à l’absence de paramètre « requested-af » indique en effet un nombre d’adresses IP déléguées souhaitées). Bien entendu, d’autres paramètres peuvent être inclus dans la demande de délégation IP_RESOURCE_DELEGATE, tels que par exemple, une durée de délégation souhaitée, etc.
En référence à la , la trame IP_RESOURCE_DELEGATE est reçue par CGN#2, par son module 9 de réception, via le canal COGITARE établi avec CGN#1 (étape F10).
Si CGN#2 accepte la demande de délégation de CGN#1 (réponse oui à l’étape test F20), il établit une liste « address-list » d’adresses IP comprenant au moins une adresse IP disponible, sélectionnée dans l’ensemble POOL#2 que CGN#2 gère et qu’il est prêt à déléguer à CGN#1 (étape F40). Il convient de noter que les adresses IP déléguées à CGN#1 sont destinées à être utilisées par celui-ci pour traiter des messages d’équipements clients qui lui sont rattachés ; elles ne doivent donc pas être utilisées pour traiter des messages échangés dans le cadre de connexions actives d’équipements clients servis par CGN#2, ni pour de futures connexions. En dehors de l’absence de trafic associé aux adresses IP de la liste « address-list », CGN#2 peut envisager d’autres critères pour sélectionner les adresses de l’ensemble POOL#2 qu’il accepte de déléguer à CGN#1 : il peut par exemple les sélectionner de façon aléatoire parmi les adresses non utilisées (c’est-à-dire qui ne sont pas actives) de l’ensemble POOL#2, ou sélectionner celles qui n’appartiennent pas à une « block-list », etc. CGN#2 peut en outre, pour établir la liste « address-list », tenir compte des préférences de CGN#1 indiquées le cas échéant dans sa demande de délégation (cf. paramètres « requested-size », « requested-nb », « requested-af », etc.). En variante, CGN#2 peut être configuré pour ignorer, lorsqu’il établit la liste « address-list », les préférences indiquées par CGN#1.
Dans le mode de réalisation décrit ici, comme détaillé davantage ultérieurement, après avoir délégué une adresse IP de l’ensemble POOL#2 à CGN#1, CGN#2 continue d’être impliqué dans la gestion du trafic destiné à ou émis en utilisant cette adresse IP. Plus particulièrement, il est configuré pour encapsuler, via son module 11 de transmission/réception, dans le canal COGITARE établi avec CGN#1, tous les paquets qu’il reçoit à destination de cette adresse IP déléguée pour les transmettre à CGN#1, et à l’inverse, désencapsuler les paquets utilisant cette adresse IP déléguée qu’il reçoit via le canal COGITARE établi avec CGN#1 pour les transmettre à leurs destinataires respectifs. Lors de ces opérations, CGN#2 est configuré pour ne pas effectuer de translation de l’adresse IP déléguée (contrairement à ce qu’il fait avec les adresses IP de l’ensemble POOL#2 dont l’usage lui est réservé, c’est-à-dire qui ne sont déléguées à aucun autre NAT opérateur). Ce mode de réalisation permet avantageusement d’éviter une mise à jour des tables de routage dans le réseau 2, puisque CGN#2 continue de gérer le trafic associé aux adresses IP qu’il délègue à d’autres NAT opérateur du système 1.
Une fois la liste « address-list » établie, CGN#2 mémorise dans une table nommée ici DELEG stockée par exemple dans sa mémoire non volatile NVM, les adresses IP de la liste « address-list » déléguées à CGN#1 en association avec un identifiant de CGN#1, par exemple son adresse IP @IP-CGN#1.
CGN#2 envoie ensuite, par le biais de son module 10 d’envoi et via le canal COGITARE établi avec CGN#1, une réponse favorable à la demande de délégation de CGN#1 incluant la liste « address-list » ainsi établie (étape F50). Dans le mode de réalisation décrit ici d’un canal COGITARE reposant sur le protocole QUIC, la réponse de CGN#2 est une trame IP_RESOURCE_DELEGATE incluant la liste « address-list ». Cette réponse peut inclure par ailleurs d’autres informations, comme par exemple un paramètre nommé ici « validity » indiquant la durée pendant laquelle les adresses IP de la liste « address-list » est déléguée à CGN#1, un paramètre nommé ici « rate-limit » représentatif du volume maximum de trafic associé à l’usage d’une adresse IP déléguée de la liste « address-list » que CGN#2 peut gérer (compte tenu du fait qu’il reste impliqué dans la gestion de ce trafic comme indiqué précédemment), etc.
La réponse IP_RESOURCE_DELEGATE de CGN#2 est reçue par CGN#1, et transmise à son module 5 d’exécution (étape E50-3). Le module 5 d’exécution enregistre alors dans une table CGN_PEERS, stockée par exemple dans la mémoire non volatile NVM, la ou les offres de délégation reçues des NAT opérateur au(x)quel(s) il a envoyé une demande de délégation à l’étape E50-2, autrement dit, dans l’exemple illustratif envisagé ici de CGN#2 (étape E50-4). Plus particulièrement, dans le mode de réalisation décrit ici, le module 5 d’exécution de CGN#1 mémorise dans la table CGN_PEERS, pour chaque NAT opérateur lui ayant délégué des adresses IP (c’est-à-dire dans l’exemple envisagé, pour CGN#2) : un identifiant du NAT opérateur (c’est-à-dire dans l’exemple envisagé, un identifiant de CGN#2) ; la liste des adresses déléguées par le NAT opérateur (c’est-à-dire dans l’exemple envisagé, la liste « address-list ») ; la durée de validité de la délégation d’adresses par le NAT opérateur (c’est-à-dire dans l’exemple envisagé, la durée indiquée par CGN#2 dans le paramètre « validity ») ; et le volume maximum de trafic associé aux adresses déléguées par le NAT opérateur pouvant être géré par celui-ci (c’est-à-dire dans l’exemple envisagé, le volume indiqué par CGN#2 dans le paramètre « rate-limit »).
Par souci de simplification ici, on suppose une même valeur de durée de validité et de volume maximum pour l’ensemble des adresses IP de la liste « address-list ». Toutefois, cette hypothèse n’est pas limitative en soi et on peut envisager des valeurs qui diffèrent en fonction des adresses IP déléguées.
Dès lors, CGN#1 est en mesure d’utiliser les adresses IP déléguées répertoriées dans la table CGN_PEERS en plus des adresses IP de l’ensemble POOL#1 (sauf celles retirées le cas échéant lors de l’exécution de l’action ACT1) pour traiter les paquets des équipements clients qu’il reçoit (étape E50-5). Ainsi, grâce à l’invention, on étend de facto l’ensemble POOL#1 dont le CGN#1 bénéficie pour traiter les paquets qui lui parviennent.
Si les adresses IP déléguées à CGN#1 sont associées à une durée de validité limitée, alors CGN#1 est configuré localement pour utiliser ces adresses IP déléguées uniquement pendant une période de temps inférieure ou égale à cette durée de validité. Si CGN#1 a besoin d’utiliser une adresse IP déléguée au-delà de la durée de validité spécifiée par CGN#2, alors CGN#1 peut être configuré pour demander à CGN#2 une extension de cette durée de validité ou pour demander à un autre NAT opérateur du système 1 la délégation d’autres adresses IP et restituer le cas échéant la ou les adresses IP déléguée dont la durée de validité a expiré à CGN#2. On note que CGN#1 peut restituer une adresse IP déléguée par CGN#2 avant l’expiration de sa durée de validité, par exemple en envoyant une trame QUIC à CGN#2 introduite pour les besoins de l’invention appelée par exemple RELEASE_RESOURCES et incluant l’adresse IP déléguée en question.
a 1 ) (C 1 -C 4 )alkyl (C 1 -C 4 )(alkyl)acrylate dans lequel le(s) groupe(s) alkyle en C 1 -C 4 sont éventuellement substitués par un ou plusieurs groupe(s) choisi(s) parmi hydroxy et (di) (alkyle en C 1 -C 4 ) amino ; et/ou
a 3 ) monomères éthyléniques comprenant un ou plusieurs groupes carboxy, anhydride, acide phosphorique, acide sulfonique ; et
b 2 ) au moins un polymère de monomères éthyléniques comprenant un ou plusieurs groupes carboxy, anhydride, acide phosphorique ou acide sulfonique.
De préférence, les monomères éthyléniques comprenant un ou plusieurs groupes carboxy, anhydride, acide phosphorique, acide sulfonique a 3 ) sont choisis parmi les monomères éthyléniques comprenant un ou plusieurs groupes carboxy, plus préférablement les acides acryliques d'alkyle en C 1 -C 4 ) tels que l’acide (méth)acrylique, en particulier l’acide acrylique. De préférence, les monomères éthyléniques de (C 1 -C 4 )alkyl (C 1 -C 4 )(alkyl)acrylate dans lesquels l'alkyle en C 1 -C 4 désigne un (méth)acrylate d'alkyle en C 1 -C 4 tel que (méth)acrylate d’éthyle ou (méthyl méth)acrylate, en particulier acrylate de méthyle et acrylate d’éthyle.
De préférence, les monomères éthyléniques de (C 1 -C 4 )alkyl (C 1 -C 4 )(alkyl)acrylate dans lesquels le ou les groupes alkyle en C 1 -C 4 sont substitués par un ou plusieurs groupes choisis parmi hydroxy, (di) (alkyle en C 1 -C 4 ) amino sont choisis parmi les monomères éthyléniques de (C 1 -C 4 ) (C 1 -C 4 ) alkyl (alkyl) acrylate substitués par un groupe hydroxy ou par un groupe (di) (alkyl en C 1 -C 4 ) amino. Selon un mode de réalisation, les monomères éthyléniques de (C 1 -C 4 ) (C 1 -C 4 ) alkyl (alkyl)acrylate dans lesquels le(s) groupe(s) alkyle en C 1 -C 4 sont substitués par un ou plusieurs groupes hydroxy, sont substitués par un groupe hydroxy tel que (méth)acrylate de 2-hydroxyéthyle, en particulier acrylate de 2-hydroxyéthyle (HEA).
Selon un autre mode de réalisation, les monomères éthyléniques de (C 1 -C 4 )alkyl (C 1 -C 4 )(alkyl)acrylate dans lesquels le(s) groupe(s) alkyle en C 1 -C 4 sont éventuellement substitués par un ou plusieurs groupe(s) choisi(s) parmi hydroxy, et (di)(alkyle en C1 -C4) amino, sont substitués par un groupe di (alkyle en C 1 -C 4 ) amino tel qu'un groupe diméthylamino tel que (méth)acrylate de 3-(diméthylamino) propyle et (méth)acrylate de 2-(diméthylamino)éthyle.
Selon un mode de réalisation particulier de la présente divulgation, les particules de noyau polymère éthylénique de la dispersion contiennent des particules A1 constituées de copolymères de monomères éthyléniques :
a 1 ) (C 1 -C 4 )alkyl (C 1 -C 4 )(alkyl)acrylate dans lequel le(s) groupe(s) alkyle en C 1 -C 4 sont éventuellement substitués par un ou plusieurs groupe(s) choisi(s) parmi hydroxy et (di) (alkyl en C1 -C4) amino ; et/ou
a 3 ) monomères éthyléniques comprenant un ou plusieurs carboxy, anhydride, acide phosphorique, acide sulfonique,