Choose the experimental features you want to try

This document is an excerpt from the EUR-Lex website

Document C(2019)1789

    RÈGLEMENT DÉLÉGUÉ (UE) …/... DE LA COMMISSION complétant la directive 2010/40/UE du Parlement européen et du Conseil en ce qui concerne le déploiement et l’utilisation opérationnelle des systèmes de transport intelligents coopératifs

    C/2019/1789 final

    EXPOSÉ DES MOTIFS

    1.Contexte politique

    L'augmentation du volume du transport routier dans l'Union européenne représente un défi à bien des égards. La majeure partie des émissions de gaz à effet de serre et de polluants atmosphériques provenant de l’ensemble du secteur des transports est causée par le transport routier. Bien que la sécurité routière se soit améliorée dans l’UE au cours des dernières décennies, cette tendance a récemment ralenti et il est peu probable que l’Union atteigne son objectif consistant à réduire de moitié le nombre de tués sur les routes entre 2010 et 2020. De plus, les encombrements sur les routes entraînent des coûts énormes pour l’économie européenne. Il est nécessaire de mener une action coordonnée dans plusieurs domaines pour remédier à ces problèmes et éviter qu’ils ne nuisent gravement aux individus, à l’économie, à l’environnement et au climat de l’Europe.

    Les nouvelles technologies visant à améliorer l’efficacité, la sécurité et la performance environnementale du transport routier jouent un rôle important dans la réalisation des objectifs de la Commission en la matière. Parmi les domaines émergents figure celui des systèmes de transport intelligents coopératifs (ci-après les «STIC»), qui permettent aux véhicules d’interagir directement entre eux et avec l’infrastructure routière. Dans le secteur du transport routier, les STIC incluent généralement la communication de véhicule à véhicule («vehicle-to-vehicle», V2V), de véhicule à infrastructure («vehicle-to-infrastructure», V2I) et/ou d'infrastructure à infrastructure («infrastructure-to-infrastructure», I2I), ainsi que la communication de véhicule à piéton, cycliste ou tout autre usager de la route («vehicle-to-everything», V2X). Ils permettent de fournir une large gamme de services d’information et de coopération.

    Les STIC sont une catégorie de services STI qui s’appuient sur un réseau ouvert dans lequel les stations STIC peuvent établir des communications «point-à-multipoint» ou «point-à-point». Cela signifie que toutes les stations STIC, telles qu’elles sont définies dans le présent règlement, peuvent échanger des messages entre elles en toute sécurité, et que cet échange de messages ne se limite pas à une ou des stations prédéfinies. Les services STI qui fournissent des informations similaires, par exemple par l’intermédiaire de la diffusion numérique, des réseaux cellulaires ou de la radio FM, mais qui ne s’appuient pas sur les caractéristiques d’un réseau ouvert dans lequel les stations STIC peuvent établir des communications «point-à-multipoint» ou «point-à-point», ne relèvent pas du champ d’application du présent règlement.

    Les avantages des STIC sont multiples et comprennent l’amélioration de la sécurité routière, de l'efficacité des transports, de la mobilité et de la fiabilité du service, la réduction des encombrements, de la consommation d’énergie et des incidences négatives sur l’environnement, et le soutien au développement économique. Dans le même temps, des précautions doivent être prises pour éviter d'éventuels effets négatifs de ces améliorations, tels qu'une augmentation de la demande de transport, une surcharge d’informations pour les conducteurs, ou une augmentation des risques en matière de cybersécurité ou de protection de la vie privée due au partage de données supplémentaires.

    Ces dix dernières années, les technologies ont connu des nouvelles évolutions remarquables qui facilitent le développement des STIC. Les avantages potentiels que présentent ces systèmes n’ont toutefois pas encore débouché sur un déploiement à grande échelle. En 2011, les constructeurs automobiles de l’UE réunis au sein du consortium Car2Car Communication ont publié un protocole d’accord conjoint dans lequel ils déclaraient leur intention de commencer le déploiement à grande échelle de ces systèmes en 2015 au plus tard, compte tenu du fait que leur technologie serait alors au point. Il est toutefois apparu que cette ambition ne serait réalisable que si les principales parties prenantes adoptaient une approche commune concernant les aspects techniques et non techniques.

    En 2014, la Commission a pris des mesures en créant une plateforme pour le déploiement de systèmes de transport intelligents coopératifs dans l’UE (ci-après la «plateforme STIC»), un groupe d’experts au sein duquel les autorités nationales, les parties prenantes dans le domaine des STIC et la Commission pouvaient travailler de concert sur une vision commune et des solutions concrètes de mise en œuvre en vue du déploiement interopérable des STIC dans l’UE. Les résultats des vastes travaux menés par la plateforme STIC et ses groupes de travail ont été résumés dans les rapports finaux 1 relatifs à la phase I (2014-2016) et à la phase II (2016-2017).

    Grâce, d’une part, à la plateforme CROADS 2 , initiative conjointe d’États membres et d’exploitants routiers visant à expérimenter et à mettre en œuvre les services STIC dans le cadre de l’harmonisation et de l’interopérabilité transfrontalières, et, d’autre part, à d’importants investissements réalisés aux niveaux national et de l’UE (199 millions d’EUR, dont 107 millions d’EUR cofinancés au titre du mécanisme pour l’interconnexion en Europe), 16 États membres ont pu travailler avec le secteur pour harmoniser les services STIC V2I et les rendre interopérables afin, par exemple, que les messages relatifs aux travaux routiers puissent être compris de manière uniforme indépendamment des environnements géographiques et des constructeurs automobiles. La coopération entre la plateforme CROADS et le consortium Car2Car Communication a permis d’améliorer la cohérence des messages et systèmes V2V et V2I.

    En 2016, des entreprises du secteur automobile et des sociétés de télécommunications se sont réunies au sein de l’association «5G Automotive Association» afin de développer des technologies pour une mobilité connectée et automatisée, y compris pour les services STIC. Cela a entraîné la coexistence de deux technologies de communications à courte portée, qui sont arrivées à des stades d'avancement et de commercialisation différents et qui ne sont pas interopérables au niveau de l'accès radio.

    Les travaux menés par la plateforme STIC constituaient une contribution essentielle à la stratégie européenne relative aux STIC 3 , qui visait à faciliter la convergence des investissements et des cadres réglementaires dans l’UE afin que le déploiement puisse commencer dès que possible et, en particulier, que des services STIC liés à la sécurité et parvenus à leur maturité puissent être déployés dès 2019. La stratégie a mis en évidence la nécessité d’adopter un cadre juridique approprié à l’échelle de l’UE avant 2018, éventuellement par la voie d’actes délégués au titre de la directive 2010/40/UE [ci-après la «directive relative aux systèmes de transport intelligents (STI)»] 4 ou d’autres instruments juridiques.

    Le présent règlement délégué complétant la directive 2010/40/UE du Parlement européen et du Conseil a pour objectif d’élaborer des exigences légales minimales pour l’interopérabilité des STIC et de permettre le déploiement à grande échelle des systèmes et services STIC dès 2019. La directive 2010/40/UE (ci-après la «directive STI») fournit un cadre politique et juridique pour accélérer le déploiement de solutions de transport innovantes dans toute l’Europe. Elle est axée sur les systèmes de transport intelligents pour le transport routier et son interface avec d’autres modes de transport, et elle confère à la Commission le pouvoir d’adopter des actes délégués dans quatre domaines prioritaires. La définition de spécifications pour les STIC s’inscrit dans le cadre du domaine prioritaire IV de la directive.

    Le présent règlement délégué met l’accent sur les services de la liste initiale («Day 1»), c’est-à-dire les services STIC qui doivent être déployés à court terme et qui contribueront en particulier à la sécurité routière et à l’efficacité du trafic. La coopération entre un large groupe de parties prenantes du secteur et les autorités des États membres a permis d’élaborer des spécifications et des normes pour les services prioritaires interopérables de la liste initiale ainsi qu’une solution de sécurité commune.

    2.BASE JURIDIQUE, SUBSIDIARITÉ ET PROPORTIONNALITÉ

    2.1.Base juridique

    Le présent acte délégué complète la directive 2010/40/UE en conformité avec son article 7. Un règlement constitue l’instrument juridique le plus approprié, car il n’implique pas de mesures nationales de transposition et garantit ainsi une harmonisation plus poussée, un allégement de la charge administrative pour les États membres, une plus grande sécurité juridique pour les acteurs publics et privés, et une entrée en vigueur rapide.

    2.2.Subsidiarité et proportionnalité

    Selon le principe de subsidiarité (article 5, paragraphe 3, du traité sur l'Union européenne), l'UE intervient seulement lorsque les objectifs envisagés ne peuvent pas être atteints de manière satisfaisante par les seuls États membres, mais peuvent l'être mieux, compte tenu des dimensions ou des effets de l'action proposée, au niveau de l'UE.

    Alors que le déploiement de services STIC est déjà en cours dans le cadre de projets menés dans toute l’UE et dans plusieurs États membres et que de nombreux constructeurs automobiles ont indiqué leur intention de passer à un déploiement à grande échelle, nombreux sont ceux qui estiment qu'il faut disposer d’un cadre juridique au niveau de l’UE. Les travaux de normalisation à l'initiative du secteur menés par les organisations européennes de normalisation (OEN) contribuent à améliorer l’interopérabilité, mais ils sont réalisés sur une base volontaire et peuvent entraîner des formes de mise en œuvre divergentes et non interopérables. Du fait du grand nombre d’acteurs concernés et de l’importance des effets de réseau, aucune partie prenante isolée ne peut apporter de solution interopérable. De même, la définition de règles au niveau national entraverait probablement la fourniture de services continus STIC dans l’espace européen unique des transports.

    La compatibilité des solutions en matière d’infrastructure et de véhicules devra être garantie dans l’ensemble de l’UE afin de tirer tous les avantages qu’offrent les STIC. Il convient en outre d’adopter une approche plus harmonisée à l’échelle de l’UE pour assurer des synergies efficaces avec le déploiement de nouvelles technologies de sécurité et le développement d'une mobilité coopérative, connectée et automatisée («cooperative connected and automated mobility», CCAM) dans toute l’UE. Sans cadre européen inclusif et adapté aux évolutions futures, le déploiement continuerait probablement d’être fragmenté et non coordonné, empêchant ainsi la continuité géographique des services STIC dans toute l’UE et à ses frontières extérieures.

    Le respect des dispositions du présent règlement délégué ne serait obligatoire que dans les cas où des services ou stations STIC ont été déployés. Les spécifications contraignantes de l’UE, tout en exigeant que les stations STIC existantes et les nouvelles solutions technologiques leur soient adaptées, sont indispensables pour garantir l’interopérabilité des services STIC à l’échelle de l’UE, et la révision prévue offre une certaine flexibilité dans le développement de solutions technologiques. Un règlement est plus strict que des lignes directrices ou qu’une recommandation, mais les avantages directs et indirects attendus sont aussi proportionnellement plus élevés. En ce sens, le présent acte délégué est proportionnel au but recherché.

    Il aura également pour effet notable de garantir l’authenticité et l’intégrité des messages échangés entre les stations STIC, ce qui devrait faciliter l’évaluation du niveau de confiance de ces informations. Dans le même temps, l’incidence sur la vie privée des usagers de la route devrait être réduite au maximum. En conséquence, la plateforme STIC a développé une architecture de sécurité basée sur une infrastructure à clés publiques («public key infrastructure», PKI) utilisant des certificats pseudonymes fréquemment modifiés. La politique commune en matière de sécurité et de certification qui en résulte a fait l’objet d’une vaste consultation et a été approuvée par tous les acteurs concernés.

    2.3.Droits fondamentaux

    Le droit à la protection des données à caractère personnel est garanti par l’article 8 de la charte des droits fondamentaux de l’Union européenne. Lorsque les dispositions du présent règlement prévoient le traitement de données à caractère personnel, il convient que ce traitement soit effectué dans le respect de la législation de l’UE relative à la protection des données à caractère personnel, et notamment du règlement général sur la protection des données (RGPD) 5 et de la directive vie privée et communications électroniques 6 .

    Le 10 juillet 2017, dans le cadre de leurs travaux préparatoires, les services de la Commission ont consulté le sous-groupe «technologie» du groupe de travail institué en vertu de l’article 29 de la directive sur la protection des données 7 . Dans son avis (octobre 2017), le sous-groupe a énuméré un certain nombre d’actions nécessaires pour soutenir le traitement légal des données à caractère personnel dans le cadre des STIC. Il a en outre précisé que le présent règlement, étant donné qu’il ne couvre que l’échange de messages entre les stations STIC, ne saurait, à lui seul, créer la base juridique sur le fondement de laquelle les données pourront être traitées légalement. En conséquence, les obligations imposées aux responsables du traitement des données et aux sous-traitants restent pleinement applicables. Le présent règlement précise toutefois qu’en l’absence d’une base légale spécifique et appropriée, les données à caractère personnel collectées ne devraient pas être (ré)utilisées à des fins commerciales, ni en tant que nouvelle ressource pour les forces de l’ordre. De plus, les informations concernant une personne physique identifiée ou identifiable devraient être traitées en stricte conformité avec le principe de minimisation des données, uniquement aux fins énoncées dans le présent règlement, et elles ne devraient pas être conservées plus longtemps que ce qui est nécessaire. Enfin, les utilisateurs finals devraient être informés d’une manière claire et exhaustive sur la collecte des données et les modalités relatives aux délais de leur conservation.

    3.Résultats des évaluations ex post et des analyses d’impact

       Évaluations ex post/bilans de qualité de la législation existante

    Compte tenu de l’absence de législation existante dans ce domaine, aucune évaluation ex post n’a dû être réalisée.

       Obtention et utilisation d'expertise

    La Commission a utilisé les rapports finaux relatifs à la phase I et à la phase II de la plateforme STIC. Par ailleurs, la Commission a eu recours à une expertise externe en signant un contrat pour la réalisation d’une étude de soutien à l’analyse d’impact avec la société de conseil indépendante Ricardo Energy & Environment, avec le soutien de TRT et de TEPR, qui a été lancée en septembre 2017 et achevée en décembre 2018.

       Analyse d'impact

    L’initiative est étayée par une analyse d’impact qui a reçu un avis positif assorti de réserves après avoir été examinée, le 10 octobre 2018, par le comité d’examen de la réglementation (CER). Les réserves du CER portaient sur deux aspects principaux:

    ·Le CER était d’avis que le rapport ne mettait pas suffisamment en évidence la nécessité d’une approche par étapes pour atteindre les objectifs de l’initiative, avec pour conséquence que le choix de l’option privilégiée ne découlait pas clairement de l’analyse et de la présentation du rapport.

    ·Le CER a également estimé que le rapport omettait d’expliquer les raisons pour lesquelles il ne répondait pas (encore) aux préoccupations exprimées par les parties prenantes concernant la sécurité des usagers de la route vulnérables et les incidences sur l’environnement.

    Les ajouts suivants ont été effectués dans l’analyse d’impact finale afin de tenir compte de ces réserves:

    ·La distinction entre les différentes options stratégiques et les considérations qui les sous-tendent ont été réexaminées et clarifiées dans toute l’analyse d’impact, et notamment dans les sections 5.3, 7 et 8. La nécessité d’une analyse d’impact distincte pour les éventuelles mesures législatives de suivi, y compris un mandat V2V, est explicitement abordée.

    ·L’incidence des STIC sur les usagers de la route vulnérables a été précisée dans les sections 6.1 et 6.5. Il a été souligné que les services STIC spécifiques aux usagers de la route vulnérables ne sont pas encore parvenus à leur maturité et ne peuvent être inclus dans les spécifications et donc dans les options stratégiques envisagées dans l’analyse d’impact. Les préoccupations des parties prenantes ont été décrites plus en détail à l’annexe 2.

    ·En ce qui concerne les incidences, l’analyse de sensibilité présentée dans la section 6.5 a été élargie à toutes les options stratégiques, et des adaptations ont été apportées tout au long du rapport afin de mieux différencier les options stratégiques. La section 2 de l’annexe 4 a été mise à jour pour tenir compte du fait que les services de la liste initiale accordent une attention toute particulière à la sécurité et clarifier les limites de l’analyse.

    ·La section 6.4 a été ajoutée pour examiner les incidences des différentes options stratégiques sur la protection des données. L’annexe 6 a également été mise à jour à cet égard.

    L’analyse d’impact a examiné trois grandes options stratégiques (OS):

    OS1:    Intervention de faible niveau basée sur des mesures non législatives, y compris des orientations non contraignantes relatives à l’interopérabilité des services de la liste initiale, à la sécurisation des communications, à la protection des données et à l’évaluation de la conformité;

    OS2:    Intervention de niveau moyen basée sur des spécifications au titre de la directive relative aux STI. Cette option comporterait des éléments similaires à ceux de l’OS 1, mais les rendrait juridiquement contraignants par la voie d’un règlement délégué. Les États membres et le secteur resteraient toutefois libres de décider de procéder ou non au déploiement des STIC;

    OS3: Intervention de niveau élevé basée sur un mandat de véhicule à véhicule (V2V) et la mise en place d’organes de gouvernance. Cette option s’appuie sur les spécifications juridiquement contraignantes selon une approche par étapes, en veillant à ce que tous les nouveaux véhicules soient équipés de stations STIC et en augmentant considérablement leur taux d’adoption, ce qui permettrait d’atteindre beaucoup plus rapidement le seuil pour la prestation efficace des services (liée à l’effet de réseau). L’OS 3 comporte des mesures supplémentaires qui soutiennent le déploiement des STIC et ne peuvent être introduites uniquement par la voie d’un acte délégué:

    ·une mesure législative peut constituer une base juridique pour le traitement licite des données à caractère personnel relatives aux STIC. Cela renforcerait la sécurité juridique et permettrait probablement de fournir davantage de services STIC; et

    ·l’attribution de rôles de gouvernance à des entités juridiques permettra de renforcer la coordination et la supervision du déploiement des STIC, et de réduire ainsi au minimum les obstacles à l’adoption des STIC.

    L’option privilégiée est l’OS3, à savoir une approche par étapes telle que prévue par la directive relative aux STI, dans laquelle, après l’adoption de spécifications, une initiative distincte sera envisagée pour le déploiement, tout en analysant plus avant l’efficacité et la proportionnalité d’un mandat fondé sur l’évolution constante du secteur des STIC. Cette option stratégique est considérée comme étant la plus cohérente et la plus efficace; elle permet par ailleurs de réaliser les diminutions les plus significatives en termes d’accidents, d’encombrements et d’émissions de CO2.

    Les impacts attendus sont les suivants:

    ·Parmi les principaux avantages figurent une diminution des accidents et des coûts de carburant, ainsi que des gains de temps de trajet. Cette option permettrait par ailleurs de réduire légèrement les coûts externes des émissions de CO2 et des polluants atmosphériques. Le total des avantages traduits en valeur monétaire s’élève à 78,9 milliards d’EUR pour la période 2020-2035, chiffre qui passerait à 128,9 milliards d’EUR avec l’introduction d’un mandat V2V.

    ·Les principaux coûts sont liés à l’installation des STIC dans les véhicules et à l’équipement de l’infrastructure de bord de route. Les autres coûts administratifs et de mise en conformité ont fait l’objet d’une évaluation mais ils sont considérés comme mineurs par rapport aux coûts globaux. Le total des coûts traduits en valeur monétaire s’élève à 19,1 milliards d’EUR pour la période 2020-2035, chiffre qui passerait à 32,3 milliards d’EUR avec l’introduction d’un mandat V2V. Les avantages escomptés l’emportent donc largement sur les coûts escomptés.

    ·Les coûts sont liés pour 90 % à l’équipement des flottes de véhicules, mais l’équipement de l’infrastructure sera en grande partie à charge du secteur public. Les États membres demeurent toutefois libres de décider de procéder ou non au déploiement.

    4.RÉSULTAT DES CONSULTATIONS

    4.1.Réunions avec les experts désignés par les États membres

    Afin d’élaborer au niveau de l’UE des règles et des exigences visant à favoriser le déploiement de systèmes et services STIC, et notamment l’interopérabilité et la continuité, dans l’ensemble de l’Union, de services V2V et V2I, il a été nécessaire d’établir une coopération étroite entre les parties prenantes (fabricants, fournisseurs de services et autorités compétentes). Les États membres de l’UE et les pays de l’AELE ont été invités à désigner des experts pour assister à une série de 13 réunions qui se sont tenues entre le 23 mai 2017 et le 3 octobre 2018 à Bruxelles, avec les services de la Commission, et contribuer à l’élaboration du projet de règlement. Des experts du Parlement européen ont également été invités à participer et la Commission a tenu un certain nombre de réunions bilatérales avec les États membres.

    4.2.Consultation des parties intéressées

    Une consultation publique a été menée sur le site web de la Commission du 10 octobre 2017 au 12 janvier 2018 (13 semaines) et a reçu 139 réponses. La consultation publique se basait sur un questionnaire concernant les avis des parties prenantes sur les principaux éléments de l’analyse d’impact: le principal problème, ses sources, les mesures envisageables et leurs incidences potentielles, ainsi que la pertinence d’une action à l’échelle de l’UE.

    Plusieurs études de cas ont été réalisées dans le cadre d’une étude à l’appui de l’analyse d’impact:

    ·neuf de ces études ont porté sur les projets de déploiement des STIC dans l’UE; et

    ·trois d’entre elles ont porté sur le déploiement des STIC dans d’autres pays (les États-Unis, l’Australie et le Japon); ces études de cas consistaient notamment en des entretiens réalisés avec des hauts représentants entre octobre 2017 et février 2018.

    Toutes les études de cas étaient axées sur les aspects suivants du déploiement des STIC: les objectifs, les progrès accomplis, les obstacles, la collecte de données et les coûts dans le domaine concerné. Dans le cadre des études de cas relatives à l'UE, les répondants ont également été invités à donner leur avis sur la définition du problème, les mesures et options stratégiques, et le suivi et l’évaluation de la présente initiative politique.

    Un atelier a été organisé le 9 février 2018 avec les experts et les parties prenantes afin de recueillir des informations/données spécifiques ainsi que leurs avis et suggestions. Plus de 140 personnes y ont pris part, faisant de cet événement un succès.

    Le 6 septembre 2018 et le 29 janvier 2019, la Commission a présenté l’objet et le champ d’application du présent règlement aux membres de la Commission des transports et du tourisme.

    Le projet de règlement a fait l’objet d’une consultation publique disponible du 11 janvier 2019 au 8 février 2019 sur le portail «Mieux légiférer», qui a reçu 100 réponses.

    4.3.Technologies de communication des STIC

    Il est particulièrement important de recenser les technologies de communication qui peuvent être utilisées pour l’échange de messages entre les stations STIC. Ce point est en lien direct avec la nécessité de veiller à ce que tout élément soit en mesure de parler à tout élément (interopérabilité) et à ce que tout élément demeure en mesure de parler à tout élément (compatibilité).

    Pour pouvoir maximiser les bénéfices, il convient d'exploiter les avantages distincts que présentent des technologies différentes mais complémentaires. L’approche dite de «communications hybrides» combine deux types de technologies:

    ·les technologies de communications à courte portée, qui fonctionnent dans une bande de fréquences dédiée de 5,9 GHz et sont les plus pertinentes pour les services à caractère urgent. La technologie «ITSG5» a été développée spécifiquement à cette fin; elle est arrivée à maturité, a été soumise à l’essai et est déjà déployée; et

    ·les technologies de communications à plus longue portée, qui exploitent la couverture des réseaux existants et permettent de connecter des zones étendues, mais qui sont surtout pertinentes pour des services V2I au caractère moins urgent. Les réseaux 3G/4G cellulaires sont des technologies matures qui offrent déjà une bonne couverture dans une grande partie de l’UE.

    La mise en œuvre pratique de l’approche de communications hybrides, conjuguée à la nécessité d’assurer l’interopérabilité et la continuité des services, impose de faire des choix technologiques. Ceux-ci sont reflétés dans un ensemble minimal d’exigences fonctionnelles et techniques s’appliquant à l’échange interopérable de messages entre les stations STIC. Étant donné qu'il convient de ne pas faire obstacle à l’innovation, le présent règlement veille à ce que les technologies de demain puissent être intégrées dans le bouquet de communications hybrides.

    Une clause de révision facilitera l’intégration de plusieurs technologies émergentes, telles que la norme LTE-V2X (une technologie de communications à courte portée basée sur la technologie cellulaire) et la 5G, l’ensemble des technologies utilisées pour les réseaux cellulaires de nouvelle génération. La Commission examinera, de manière ouverte et transparente, les éventuelles modifications à apporter au présent règlement délégué avec un groupe d’experts et l’informera régulièrement des progrès accomplis et des prochaines étapes envisageables. Les parties prenantes qui ont déjà mis en service des stations STIC devraient coopérer de bonne foi dans ce processus, conformément au droit de la concurrence de l’Union et des États membres, afin de garantir des conditions de concurrence équitables entre différentes technologies, sans pour autant entraver le développement de nouvelles technologies. Afin de permettre les évolutions futures dans ce domaine, ces parties prenantes devraient également préparer leurs produits à intégrer les technologies de demain.

    5.INCIDENCE BUDGÉTAIRE

    Le présent règlement a quelques incidences sur le budget de l’Union.

    Pour garantir le bon fonctionnement du réseau STIC, certaines tâches doivent être accomplies par des entités centrales avant que le cadre complet de gouvernance ne puisse être établi. En attendant la mise en place de telles entités, la Commission exécutera une partie des tâches – principalement celles liées au système de l’UE pour la gestion des authentifiants de sécurité des services STIC, le cadre de l’Union européenne applicable aux STIC pour la fourniture de communications sécurisées et de confiance moyennant une PKI.

    Il est important de veiller à ce que les stations STIC puissent être inscrites dans le système pour la gestion des authentifiants de sécurité avant leurs mises en service et en fonction. À cette fin, les tâches du point de contact central, du gestionnaire de la liste de confiance et de l’autorité de politique de certification des STIC seront réalisées par la Commission, avec la contribution du JRC et de la DG MOVE.

    Le partage de ces tâches n’aura aucune incidence en termes de ressources humaines, puisque le JRC et la DG MOVE feront appel à leur personnel ou procéderont à des redéploiements, selon les besoins. Le JRC bénéficie en outre de l’action de soutien «architecture de sécurité pour les infrastructures et les véhicules connectés en Europe» dans le cadre de la décision d’exécution C(2016) 1966 de la Commission 8 , qui prévoit 4 millions d’EUR pour la mise en œuvre de la phase I du système pour la gestion des authentifiants de sécurité (2018-2021). Si nécessaire, des actions de soutien supplémentaires peuvent être financées au titre du mécanisme pour l’interconnexion en Europe.

    RÈGLEMENT DÉLÉGUÉ (UE) …/... DE LA COMMISSION

    du 13.3.2019

    complétant la directive 2010/40/UE du Parlement européen et du Conseil en ce qui concerne le déploiement et l’utilisation opérationnelle des systèmes de transport intelligents coopératifs

    (Texte présentant de l'intérêt pour l'EEE)

    LA COMMISSION EUROPÉENNE,

    vu le traité sur le fonctionnement de l’Union européenne,

    vu la directive 2010/40/UE du Parlement européen et du Conseil du 7 juillet 2010 concernant le cadre pour le déploiement de systèmes de transport intelligents dans le domaine du transport routier et d’interfaces avec d’autres modes de transport 9 , et notamment son article 6, paragraphe 3, en liaison avec l'article 7,

    considérant ce qui suit:

    (1)Conformément à l’article 2, paragraphe 1, de la directive 2010/40/UE, le lien entre le véhicule et les infrastructures de transport constitue le domaine prioritaire IV pour l’élaboration et l’utilisation de spécifications et de normes. Cela englobe, entre autres, le développement et la mise en œuvre de systèmes coopératifs (système de véhicule à véhicule, système de véhicule à infrastructure et vice-versa dans lequel les messages peuvent être émis par le véhicule et/ou par l’infrastructure, et système d'infrastructure à infrastructure) fondés sur: la facilitation des échanges de données ou d’informations entre véhicules, entre infrastructures, et entre véhicules et infrastructure; l’utilisation d’un format de message type pour l’échange de données ou d’informations entre véhicules et infrastructure; et la définition d’une infrastructure de communication pour l’échange de données ou d’informations entre véhicules, entre infrastructures, et entre véhicules et infrastructure.

    (2)Les systèmes de transport intelligents coopératifs (STIC) utilisent des technologies qui permettent aux véhicules routiers de communiquer entre eux et avec l’infrastructure de bord de route, y compris les panneaux de signalisation. Les services STIC sont une catégorie de services STI qui s’appuient sur un réseau ouvert dans lequel les stations STIC peuvent établir des communications «point-à-multipoint» ou «point-à-point». Cela signifie que toutes les stations STIC, telles qu’elles sont définies par le présent règlement, peuvent échanger des messages entre elles en toute sécurité, et que cet échange de messages ne se limite pas à une ou des stations prédéfinies. Les stations STIC ne nécessitent pas d’exigences supplémentaires telles que: l’utilisation d’un même logiciel ou la nécessité de posséder un compte auprès de la même entité (même constructeur automobile, autorité routière ou fournisseur de services) ou d’avoir une relation contractuelle avec cette même entité.

    (3)La stratégie européenne relative aux STIC 10 a mis en lumière un risque de fragmentation du marché intérieur dans le domaine des STIC et une nécessité de définir des exigences minimales pour les services STIC afin de garantir la coordination et la cohérence de leur déploiement. Dans ce contexte, la Commission a annoncé son intention, le cas échéant, d’utiliser son mandat au titre de la directive 2010/40/UE pour adopter un ou des actes délégués d’ici à 2018 afin d’assurer la compatibilité, l’interopérabilité et la continuité du déploiement et de l’utilisation opérationnelle de services STIC à l’échelle de l’Union sur la base de communications sécurisées et de confiance.

    (4)Afin d’encourager et de maximiser tous les avantages qu’offrent les services STIC en termes de sécurité routière et d’efficacité du trafic, les spécifications énoncées dans le présent règlement devraient s’appliquer à l’ensemble du réseau de transport routier, y compris à ses interfaces avec les autres modes de transport pertinents pour la sécurité routière ou l’efficacité du trafic, comme les passages à niveau, les zones portuaires, etc.

    (5)Les spécifications énoncées dans le présent règlement devraient s’appliquer à tous les services STIC, sans préjudice des spécifications particulières adoptées dans d’autres actes au titre de la directive 2010/40/UE, et notamment les règlements délégués (UE) nº 886/2013 11 et (UE) 2015/962 12 de la Commission.

    (6)La directive (UE) 2016/1148 du Parlement européen et du Conseil du 6 juillet 2016 concernant des mesures destinées à assurer un niveau élevé commun de sécurité des réseaux et des systèmes d'information dans l'Union 13 («directive SRI») met en place des exigences concernant les moyens nationaux dans le domaine de la cybersécurité, établit des mécanismes visant à faciliter la coopération stratégique et opérationnelle entre les États membres et introduit des obligations en matière de mesures de sécurité et de notification d’incidents dans l’ensemble des secteurs. Étant donné que la directive SRI mentionne les exploitants de systèmes de transport intelligents au sens de l'article 4, point 1, de la directive 2010/40/UE comme des opérateurs potentiels de services essentiels, l’application de la directive SRI et des exigences imposées en vertu du présent règlement peut être, dans certains cas, complémentaire.

    (7)La décision 2008/671/CE 14 de la Commission harmonise les conditions pour la mise à disposition et l’utilisation efficace de la bande de fréquences 5 875-5 905 MHz pour les applications des STI liées à la sécurité dans l’Union.

    (8)Dans le cadre du mandat de normalisation M/453 15 , les organisations européennes de normalisation (OEN), à savoir l’Institut européen de normalisation des télécommunications (ETSI) et le Comité européen de normalisation (CEN), ont élaboré des normes communes pour le déploiement des services STIC, auxquelles le présent règlement renvoie. Ces normes constituent la base sur laquelle repose la fourniture efficace de services STIC prioritaires, lesquels permettent aux gestionnaires du trafic routier de prendre des mesures appropriées et préparent le terrain pour une automatisation plus sûre sur les routes de l’UE. Les travaux de normalisation se poursuivront, notamment pour intégrer d’autres technologies et renforcer encore les STIC. Les organisations de normalisation concernées et toutes les parties prenantes devraient par conséquent poursuivre les travaux réalisés dans le cadre du mandat de normalisation M/453 et élaborer ensemble des solutions qui soutiennent l’interopérabilité et permettent à toutes les technologies de jouer leur rôle.

    (9)Afin de garantir l’interopérabilité, chaque station STIC nécessite une configuration spécifique des normes («profil de système») qui détermine la mise en œuvre de différentes normes facultatives. Le profil de système décrit les interfaces externes nécessaires pour que les stations STIC puissent communiquer entre elles. Chaque station STIC doit respecter les dispositions de la directive 2014/53/UE du Parlement européen et du Conseil 16 . La coopération entre le secteur et les autorités des États membres a permis d’élaborer des profils de système harmonisés pour les stations STIC de véhicule et les stations STIC de bord de route qui communiquent dans la bande de fréquences 5 855-5 925 MHz. Pour que tous les services STIC puissent être fournis sans discontinuité dans l’ensemble de l’Union, il y a lieu d’adopter une approche dite de «communications hybrides», c’est-à-dire une approche qui combine des technologies de communication complémentaires. Compte tenu de la vitesse à laquelle les technologies évoluent, le secteur et les États membres sont encouragés à mettre au point – et à harmoniser dans l’ensemble de l’Union – d’autres technologies et profils de système complémentaires et compatibles avec d’autres types de stations STIC. Avant d’utiliser ces nouveaux profils ou technologies, il convient d’en informer la Commission afin qu’elle puisse envisager de mettre à jour sans tarder le présent règlement. Ces mises à jour sont préparées en étroite collaboration avec les États membres.

    (10)Compte tenu de la nature coopérative des STIC, il convient que chaque station STIC communique des informations au réseau STIC. Les stations STIC ne devraient pas interférer avec la fourniture de services STIC prioritaires, le service européen de télépéage ou le tachygraphe intelligent, ni avec le fonctionnement d’autres stations STIC.

    (11)Il importe que le secteur et les États membres mettent en œuvre des solutions techniques communes pour la fourniture des services STIC. Ces solutions devraient être élaborées notamment par les OEN, afin de faciliter l’introduction des services STIC, de garantir l’interopérabilité et la continuité des services dans toute l’Union, et de diminuer les coûts de mise en œuvre. Pour garantir la compatibilité, l’interopérabilité et la continuité des services STIC dans toute l’Union, les normes et profils de système visés dans le présent règlement devraient, le cas échéant, servir de référence pour le développement des technologies et services STIC de demain.

    (12)En ce qui concerne le déploiement, la priorité devrait être accordée aux services STIC qui contribuent à améliorer la sécurité routière et l’efficacité du trafic. Les services qui constituent des services d’informations minimales universelles sur la circulation liées à la sécurité routière au sens du règlement délégué (UE) nº 886/2013 devraient, dans la mesure du possible, être fournis en tant que service universel gratuit pour les utilisateurs finals au point d’utilisation conformément audit règlement.

    (13)Afin de garantir l’interopérabilité, chaque service STIC nécessite une configuration spécifique des normes, appelée «profil de service», qui détermine la mise en œuvre de différentes possibilités de normes. Les services STIC ne devraient pas interférer avec la fourniture de services STIC prioritaires. Les profils de service actuels pour la communication de véhicule à véhicule ont été principalement développés pour les voitures particulières. Afin de permettre le déploiement de ces services ou de services similaires pour d’autres catégories de véhicules, il pourrait s’avérer nécessaire de développer des profils de service supplémentaires ou de mettre à jour les profils de service prévus par le présent règlement.

    (14)La décision nº 768/2008/CE du Parlement européen et du Conseil 17 énonce des principes communs et des dispositions de référence conçus pour être appliqués à l'ensemble de la législation sectorielle. Elle constitue donc un cadre horizontal général pour toute nouvelle législation visant à harmoniser les conditions de commercialisation des produits. Ses dispositions de référence établissent des définitions et des obligations générales pour les opérateurs économiques, ainsi qu'une série de procédures d'évaluation de la conformité parmi lesquelles le législateur peut choisir la plus appropriée. Afin de garantir la sécurité sur le marché, elle fixe aussi les règles applicables au marquage CE et établit des dispositions de référence relatives aux procédures à suivre face à des produits présentant un risque. Étant donné que le présent règlement porte sur la mise sur le marché de stations STIC, il convient d’utiliser les dispositions de référence de l’annexe I de ladite décision en vertu desquelles il appartient au fabricant de s’assurer, entre autres, que toute la législation applicable est respectée; qu’une déclaration de conformité «UE» est établie; que le marquage de conformité est apposé et que la documentation technique requise est établie. Les rôles et les responsabilités des autres entités, telles que le mandataire, l’importateur et le distributeur, devraient également être réglementés.

    (15)Dans le présent règlement, les stations STIC embarquées dans un véhicule, utilisées en mode portatif ou installées le long de l’infrastructure routière sont considérées comme des produits qui peuvent être mis sur le marché en tant qu’ensembles autonomes ou en tant qu’éléments d’ensembles plus grands. Le degré de conformité aux exigences applicables des stations STIC destinées à être embarquées dans un véhicule peut être testé avant ou après l’installation. Dans le cas des stations STIC de bord de route, il est possible d’effectuer le test avant l’installation, de sorte que ces stations peuvent être mises sur le marché en tant que produits autonomes. S’agissant des stations STIC centrales, la situation peut être différente, car elles seront souvent intégrées dans des centres de contrôle de la circulation qui ne sont pas normalisés. Ces centres de contrôle de la circulation étant construits progressivement au rythme du développement des zones de circulation qu’ils régulent, il se peut que ces stations centrales ne puissent pas être soumises à un test complet avant d’être mises sur le marché. En tout état de cause, le niveau de sécurité et de confiance devrait être le même pour toutes les stations STIC, y compris les stations centrales.

    (16)Avant qu’une station STIC ne soit mise en service et devienne opérationnelle, il y a lieu de désigner l’entité qui vérifiera qu’elle est accompagnée d’une déclaration UE de conformité et, le cas échéant, qu’elle porte un marquage de conformité. Il convient que cette entité enregistre la station dans le système de l’UE pour la gestion des authentifiants de sécurité des STIC et veille à ce qu’elle respecte, pendant toute la durée de son utilisation, les exigences techniques qui lui sont applicables. L’entité sera l’exploitant de la station STIC et prendra en charge les relations avec l’utilisateur.

    (17)Pour bon nombre de services STIC, il est essentiel de garantir l’authenticité et l’intégrité des messages STIC contenant des informations, telles que la position, la vitesse et la direction. Dès lors, il convient d’établir un modèle de confiance européen pour les STIC commun à toutes les stations STIC (prévoyant, pour toutes les stations STIC mobiles, les mêmes exigences pour les stations de véhicule et personnelles, et, pour toutes les stations STIC fixes, les mêmes exigences pour les stations centrales et de bord de route), indépendamment des technologies de communication utilisées. Les règles et exigences applicables à ce modèle de confiance sont définies dans la politique de certification et de sécurité. Le niveau le plus élevé de l’infrastructure à clés publiques (PKI) est la liste de confiance européenne des certificats, qui contient des entrées provenant de toutes les autorités de certification racine de confiance en Europe.

    (18)Des efforts ont été réalisés dans le passé pour parvenir à une reconnaissance mutuelle des certificats de produits en Europe. L'exemple le plus marquant à cet égard est l'accord de reconnaissance mutuelle (MRA) du groupe des hauts fonctionnaires pour la sécurité des systèmes d'information (SOGIS). Même s'il est le modèle le plus remarquable en ce qui concerne la coopération et la reconnaissance mutuelle en matière de certification de sécurité, le SOGIS ne réunit qu'une partie des États membres de l'Union. Étant donné que la certification de sécurité des stations STIC constitue un élément important de la politique de certification et de sécurité des STIC, le MRA du SOGIS est appliqué à défaut d’autres systèmes européens de certification de cybersécurité équivalents dans le cadre européen pertinent en matière de cybersécurité.

    (19)Certaines stations STIC mises sur le marché avant la date d’application du présent règlement pourraient ne pas satisfaire pleinement aux exigences liées à la sécurité des STIC qui y sont énoncées, car des décisions de déploiement technique pourraient avoir déjà été prises antérieurement. Pour permettre à ces stations STIC d’intégrer le réseau STIC après la date d’application du présent règlement, une procédure devrait être prévue pour envisager l’inscription de ces stations STIC au titre du modèle de confiance STIC.

    (20)L’article 6, paragraphe 6, de la directive 2010/40/UE impose à la Commission d’adopter des spécifications conformes à une série de principes, parmi lesquels l’utilisation des infrastructures fondées sur les satellites ou toute autre technologie permettant d’atteindre des niveaux de précision équivalents aux fins des applications et des services STI qui requièrent des services de datation et de positionnement continus, précis et garantis dans le monde entier. Il y a lieu, dès lors, de garantir la compatibilité des stations STIC avec les services à valeur ajoutée fournis par les programmes Galileo et EGNOS (système européen de navigation par recouvrement géostationnaire), tels que décrits dans le règlement (UE) nº 1285/2013 du Parlement européen et du Conseil, afin d’améliorer la fiabilité des stations STIC.

    (21)La plateforme pour le déploiement des STIC dans l’Union (plateforme des STIC), mise en place en novembre 2014 et présidée par des services de la Commission, a formulé une politique commune de sécurité et de certification, qui a été approuvée par toutes les parties intéressées. Étant donné que la politique commune de sécurité et de certification devrait être actualisée en fonction du progrès technique et de l’évolution du cadre de gouvernance, la Commission devrait réexaminer le présent règlement de façon régulière dans un souci de cohérence.

    (22)Pour garantir le bon fonctionnement du réseau STIC, certaines tâches doivent être accomplies par des entités centrales avant que le cadre de gouvernance complet ne puisse être établi. Dans l’attente de la création d’entités centrales, la Commission devrait se voir confier ces tâches, y compris celles en rapport avec l’autorité chargée de la politique de certification des STIC, le gestionnaire de la liste de confiance et le point de contact STIC.

    (23)Lorsque les mesures prévues par le présent règlement impliquent le traitement de données à caractère personnel, ce traitement devrait être effectué en conformité avec le droit de l’Union en matière de protection des données à caractère personnel et de la vie privée, et en particulier le règlement (UE) 2016/679 18 et, le cas échéant, la directive 2002/58/CE 19 . Ce traitement devrait avoir une base juridique appropriée, comme le prévoit l’article 6 du règlement (UE) 2016/679, celle-ci n’étant pas fournie par le présent règlement délégué.

    (24)En l’absence d’une base légale appropriée, les données à caractère personnel collectées ne devraient être réutilisées à aucune autre fin, telle qu’une fin commerciale ou en tant que nouvelle ressource pour garantir l’application de la législation, si ce n’est sur le fondement d’une loi.

    (25)Les informations concernant une personne physique identifiée ou identifiable devraient être traitées en stricte conformité avec le principe de minimisation des données, uniquement aux fins précisées dans le présent règlement, et elles ne devraient pas être conservées plus longtemps que ce qui est nécessaire. Les exigences de sécurité relatives à la pseudonymisation qui sont prévues dans le présent règlement contribuent à réduire le risque d’utilisation abusive des données.

    (26)Les utilisateurs finals devraient être informés d’une manière claire et exhaustive de tous les aspects pertinents du traitement de leurs données personnelles conformément au règlement (UE) 2016/679.

    (27)Comme indiqué dans la politique de sécurité et de certification commune, élaborée dans le contexte de la plateforme des STIC, la gouvernance devrait reposer sur des organismes prenant la forme de comités de pilotage conjoints composés de parties prenantes, parmi lesquelles la Commission, les États membres, les exploitants d’infrastructures routières, ainsi que les fabricants et les exploitants de stations STIC. Dans l’attente de la création de tels organismes, la Commission, assistée par un groupe d’experts au sein duquel toutes les parties prenantes concernées sont représentées, devrait se voir confier les tâches correspondantes, y compris celles en rapport avec la gouvernance, la supervision et l’autorité chargée de la politique de certification des STIC. Ce groupe d’experts devrait notamment comprendre des représentants des fabricants de stations STIC et des opérateurs du réseau STIC, ainsi que d’autres parties prenantes concernées et autorités compétentes des États membres.

    (28)Le vaste processus de consultation inclusif qui a conduit au développement du cadre de la politique de sécurité et de la gouvernance ainsi que de la politique de certification (avec le soutien de tous les acteurs publics et privés concernés) devrait également présider à l’actualisation du présent règlement en fonction des progrès techniques et, le cas échéant, de l’évolution du cadre de gouvernance.

    (29)Les États membres et les autorités de certification racine devraient régulièrement fournir à la Commission des informations lui permettant de contrôler la mise en œuvre du présent règlement.

    (30)Afin de tenir compte de l’apparition de nouveaux marchés et du développement rapide des technologies et des services, comme cela a déjà été annoncé dans le programme de travail actualisé de la directive STI, il est à prévoir que le présent règlement sera modifié avant le réexamen de sa mise en œuvre, qui devrait intervenir trois ans après son entrée en vigueur.

    Cette modification devrait concerner en priorité l’intégration des réseaux 3G/4G existants pour la fourniture des services STIC prioritaires. En outre, les spécifications relatives aux technologies LTE-V2X ont été finalisées dans le cadre du 3GPP et des prototypes de mises en œuvre sont en cours de validation. Ces technologies sont en cours d’intégration dans les normes et spécifications techniques européennes, tant pour des services STIC prioritaires que pour de nouveaux services émergents. Enfin, de nouvelles technologies en évolution rapide telles que la 5G pourraient également étayer les services STIC.

    Certaines de ces avancées pourraient donner lieu à une ou plusieurs modifications du présent règlement, une fois transmis à la Commission un dossier présentant des spécifications d’une maturité technique suffisante. De telles modifications devraient ménager une approche ouverte et à l’épreuve du temps dans les normes et la législation. La Commission devrait, de manière ouverte et transparente, consulter un groupe d’experts sur les éventuelles modifications à apporter au présent règlement et informer régulièrement celui-ci des progrès accomplis et des prochaines étapes envisageables. Pour préserver la continuité des services STIC prioritaires, ces modifications devraient également garantir la compatibilité et l’interopérabilité avec les stations STIC existantes, déjà mises en service conformément au présent règlement, ou définir une trajectoire de migration appropriée tenant compte également de l’évolution du marché et des technologies.

    La Commission devrait analyser le dossier et en discuter avec le groupe d’experts dans les meilleurs délais en vue d’une éventuelle modification du présent règlement, en examinant s’il y a lieu de modifier les exigences existantes. Les parties prenantes qui ont déjà mis en service des stations STIC devraient coopérer de bonne foi dans ce processus, conformément au droit de la concurrence de l’Union et des États membres, afin de garantir des conditions de concurrence équitables entre différentes technologies, sans pour autant entraver le développement des nouvelles technologies. Afin de permettre les évolutions futures dans ce domaine, ces parties prenantes devraient également préparer leurs produits à intégrer les technologies de demain.

    (31)Le Contrôleur européen de la protection des données a été consulté conformément à l'article 28, paragraphe 2, du règlement (CE) nº 45/2001 du Parlement européen et du Conseil 20 et a rendu son avis le ....,

    A ADOPTÉ LE PRÉSENT RÈGLEMENT:

    Chapitre I

    Dispositions générales

    Article premier

    Objet et champ d'application

    1.Le présent règlement établit les spécifications nécessaires pour assurer la compatibilité, l’interopérabilité et la continuité du déploiement et de l’utilisation opérationnelle des services STIC à l’échelle de l’Union sur la base de communications sécurisées et de confiance.

    Il décrit comment les communications de véhicule à véhicule, de véhicule à infrastructure et d’infrastructure à infrastructure doivent être assurées au moyen de stations STIC et comment les stations STIC doivent être mises sur le marché et mises en service afin de permettre la fourniture de services STIC aux utilisateurs de STI.

    2.Le présent règlement s’applique à toutes les stations STIC dans le domaine du transport routier et à leurs interfaces avec d’autres modes de transport.

    3.Le déploiement des stations STIC est effectué conformément aux dispositions de l'article 5 de la directive 2010/40/CE. Les États membres choisissent la partie de leur infrastructure de réseau de transport qui est équipée de stations STIC.

    Article 2

    Définitions

    Aux fins du présent règlement, on entend par:

    (1)«systèmes de transport intelligents coopératifs» ou «STIC», des systèmes de transport intelligents permettant aux utilisateurs de STI de coopérer en échangeant des messages sécurisés et de confiance par l’intermédiaire du système de l’UE pour la gestion des authentifiants de sécurité des STIC;

    (2)«service STIC», un service STI fourni par le biais de STIC;

    (3)«station STIC», l’ensemble des composants matériels et logiciels nécessaires pour collecter, stocker, traiter, recevoir et transmettre des messages sécurisés et de confiance afin de permettre la fourniture d’un service STIC. Cela comprend les stations STI personnelles, centrales, de véhicule et de bord de route, telles que définies dans la norme EN 302 665 v. 1.1.1;

    (4)«station STIC mobile», une station STI-C embarquée dans un véhicule ou se présentant sous la forme d’un dispositif portatif personnel;

    (5)«station STIC fixe», une station STIC installée dans un système central ou sur une infrastructure de bord de route;

    (6)«station STIC centrale», un serveur central doté des capacités intégrées d’une station STIC, tel qu’un centre de gestion de la circulation;

    (7)«mise à disposition sur le marché», la fourniture d’une station STI-C destinée à être distribuée ou utilisée sur le marché de l’Union dans le cadre d’une activité commerciale, à titre onéreux ou gratuit;

    (8)«mise sur le marché», la première mise à disposition d’une station STIC sur le marché de l'Union;

    (9)«mise en service» d’une station STIC, sa première utilisation dans l’Union aux fins auxquelles elle est destinée;

    (10)«communications à courte portée», les communications dans la bande de fréquences 5 855-5 925 MHz;

    (11)«service STIC prioritaire», un service STIC qui contribue à la sécurité routière ou à l’efficacité de la circulation, et qui est décrit à l’annexe I;

    (12)«profil de système», un ensemble minimal d’exigences fonctionnelles et techniques régissant l’échange interopérable de messages entre les stations STIC;

    (13)«profil de service», un ensemble de spécifications fonctionnelles définissant des messages interopérables afin de permettre la fourniture d’un service STIC;

    (14)«système mondial de radionavigation par satellite (GNSS)», une infrastructure composée d'un ensemble de satellites et d'un réseau de stations terrestres fournissant des informations précises de temps et de géolocalisation aux utilisateurs équipés d'un récepteur adéquat;

    (15)«fabricant», toute personne physique ou morale qui conçoit et fabrique, ou fait concevoir et fabriquer, une station STIC, et qui la commercialise sous son nom ou sa marque;

    (16)«exploitant de station STIC», toute personne physique ou morale qui est responsable de la mise en service et de l’exploitation d’une station STIC conformément au présent règlement;

    (17)«mandataire», toute personne physique ou morale établie dans l’Union ayant reçu mandat écrit d’un fabricant pour agir en son nom aux fins de l’accomplissement de tâches déterminées;

    (18)«importateur», toute personne physique ou morale établie dans l’Union qui met sur le marché de l’Union une station STIC provenant d’un pays tiers;

    (19)«distributeur», toute personne physique ou morale faisant partie de la chaîne d’approvisionnement, autre que le fabricant ou l’importateur, qui met une station STIC à disposition sur le marché;

    (20)«opérateur économique», un fabricant, un mandataire, un importateur ou un distributeur;

    (21)«rappel», toute mesure visant à obtenir le retour d’une station STIC qui a déjà été mise à la disposition de l’utilisateur final;

    (22)«retrait», toute mesure visant à empêcher la mise à disposition sur le marché d’une station STIC présente dans la chaîne d’approvisionnement;

    (23)«marquage CE», le marquage par lequel le fabricant indique que le produit est conforme aux exigences applicables énoncées dans la législation de l’Union prévoyant son apposition;

    (24)«utilisateur final», la personne physique ou morale qui utilise ou est censée utiliser, en tant que destinataire ultime, une station STIC;

    (25)«autorité de surveillance du marché», l’autorité d’un État membre compétente pour la réalisation de la surveillance du marché sur son territoire;

    (26)«autorité nationale compétente», toute autorité qui est habilitée à contrôler la conformité d’une station STIC à la législation applicable;

    (27)«système de l’UE pour la gestion des authentifiants de sécurité des STIC», le cadre de l’Union européenne applicable aux STIC pour la fourniture de communications sécurisées et de confiance moyennant une infrastructure à clés publiques (PKI);

    (28)«autorité d’inscription», l’entité juridique et/ou opérationnelle qui authentifie une station STIC et lui accorde l’accès aux STIC;

    (29)«réseau STIC», l’ensemble des stations STIC opérationnelles dans l’Union.

    Article 3

    Mise à disposition sur le marché et/ou mise en service

    Seule une station STIC qui, lorsqu’elle est convenablement entretenue et utilisée aux fins prévues, satisfait aux exigences du présent règlement est mise à disposition sur le marché et/ou mise en service.

    Article 4

    Libre circulation

    Les États membres ne peuvent interdire, restreindre ou empêcher, pour les motifs visés par le présent règlement, la mise à disposition sur le marché ou la mise en service sur leur territoire de stations STIC qui sont conformes aux exigences du présent règlement.

    Chapitre II

    Exigences techniques

    Article 5

    Exigences applicables aux stations STIC

    1.Les stations STIC de véhicule conçues pour des communications à courte portée sont conformes aux exigences énoncées dans le profil de système décrit à la section 2 de l’annexe II.

    2.Les stations STIC de bord de route conçues pour des communications à courte portée sont conformes aux exigences énoncées dans le profil de système décrit à la section 3 de l’annexe II.

    3.Les stations STIC envoient des messages permettant la fourniture d’au moins un des services STIC prioritaires énumérés à l’annexe I.

    4.Les stations STIC sont compatibles avec les stations STIC qui envoient des messages pour la fourniture des services STI-C prioritaires énumérés à l’annexe I.

    5.Les stations STIC n’interfèrent pas avec le fonctionnement du service européen de télépéage visé dans la directive 2004/52/CE du Parlement européen et du Conseil 21 et dans la décision 2009/750/CE de la Commission 22 , ni avec le fonctionnement du tachygraphe intelligent visé dans le règlement (UE) nº 165/2014 du Parlement européen et du Conseil 23 .

    6.Les stations STIC sont compatibles avec les stations STIC qui sont conformes aux profils de système décrits à l’annexe II.

    7.Lorsque les stations STIC sont équipées du GNSS, elles sont compatibles avec les services de positionnement et de datation fournis par les systèmes Galileo et EGNOS. En outre, les stations STI-C peuvent être compatibles avec d’autres systèmes de navigation par satellite.

    Article 6

    Exigences applicables aux services STIC

    1.Les services STIC prioritaires énumérés à l’annexe I sont conformes aux exigences du profil de service STI-C correspondant.

    2.Chaque service STIC fonctionne sans modification avec tous les profils de service décrits à l’annexe I.

    CHAPITRE III

    Mise sur le marché des stations STIC

    Article 7

    Obligations des fabricants de stations STIC

    1.Les fabricants s’assurent, lorsqu’ils mettent leurs stations STIC sur le marché, que celles-ci ont été conçues et fabriquées conformément aux exigences énoncées à l’article 5.

    2.Les fabricants établissent la documentation technique visée à la partie A de l’annexe V et mettent ou font mettre en œuvre la procédure d’évaluation de la conformité visée à la partie A de l’annexe V.

    3.Lorsqu'il a été démontré, à l'aide de la procédure d’évaluation de la conformité visée à la partie A de l’annexe V, que les stations STIC respectent les exigences applicables, les fabricants établissent une déclaration UE de conformité et apposent le marquage CE.

    4.Les fabricants conservent la documentation technique visée à la partie A de l’annexe V et la déclaration UE de conformité pendant une durée de dix ans à compter de la mise sur le marché des stations STIC.

    5.Les fabricants s’assurent que des procédures sont en place pour que la production en série reste conforme au présent règlement.

    6.Dans un souci de protection de la santé et de la sécurité des consommateurs, lorsque cela semble approprié au vu des risques que présentent les stations STIC, les fabricants:

    (a)effectuent des essais par sondage sur les stations STIC commercialisées;

    (b)examinent les réclamations, les stations STIC non conformes et les rappels de stations STIC et, le cas échéant, tiennent un registre en la matière;

    (c)informent les distributeurs d'un tel suivi.

    7.Les fabricants s’assurent que les stations STIC qu'ils ont mises sur le marché portent un numéro de type, de lot ou de série, ou un autre élément permettant leur identification.

    8.Sur la station STIC ou, lorsque ce n’est pas possible, sur son emballage ou dans un document accompagnant la station STIC, les fabricants indiquent:

    (a)leur nom;

    (b)leur raison sociale ou leur marque déposée;

    (c)leur adresse postale, précisant un point de contact unique.

    Les coordonnées sont indiquées dans une langue aisément compréhensible par les utilisateurs finals et par les autorités de surveillance du marché.

    9.Les fabricants veillent à ce que les stations STIC soient accompagnées d’instructions et d’informations de sécurité fournies dans une langue aisément compréhensible par les utilisateurs finals, déterminée par l’État membre concerné. Ces instructions et ces informations de sécurité ainsi que tout étiquetage sont clairs, compréhensibles et intelligibles.

    10.Les fabricants qui considèrent qu'une station STIC qu'ils ont mise sur le marché n'est pas conforme au présent règlement prennent sans délai les mesures correctives nécessaires pour la mettre en conformité, la retirer ou la rappeler, si nécessaire. Lorsque la station STIC présente un risque, les fabricants en informent immédiatement les autorités de surveillance du marché des États membres dans lesquels ils l'ont mise à disposition, en fournissant des précisions, notamment, sur la non-conformité et toute mesure corrective adoptée.

    11.Sur requête motivée d’une autorité nationale compétente, les fabricants lui communiquent toutes les informations et tous les documents nécessaires, sur support papier ou par voie électronique, pour démontrer la conformité de la station STIC, dans une langue aisément compréhensible par cette autorité. Ils coopèrent, à la demande de cette autorité, à toute mesure adoptée en vue d’éliminer les risques présentés par les stations STIC qu’ils ont mises sur le marché.

    Article 8

    Mandataires

    1.Le fabricant peut désigner, par un mandat écrit, un mandataire.

    2.Le mandataire exécute les tâches indiquées dans le mandat reçu du fabricant. Le mandat doit au minimum autoriser le mandataire:

    (a)à tenir la déclaration UE de conformité et la documentation technique à la disposition des autorités nationales de surveillance du marché pendant une durée de dix ans à compter de la mise sur le marché de la station STIC;

    (b)sur requête motivée d'une autorité nationale compétente, à lui communiquer toutes les informations et tous les documents nécessaires pour démontrer la conformité d'une station STIC;

    (c)à coopérer, à leur demande, avec les autorités nationales compétentes à toute mesure adoptée en vue d’éliminer les risques présentés par les stations STIC couvertes par le mandat.

    Les obligations énoncées à l'article 7, paragraphe 1, et l'établissement de la documentation technique visé à l'article 7, paragraphe 2, ne peuvent être confiés au mandataire.

    Article 9

    Obligations des importateurs

    1.Les importateurs ne mettent sur le marché de l’Union que des stations STIC conformes.

    2.Avant de mettre une station STIC sur le marché, les importateurs s’assurent que:

    (a)le fabricant a appliqué la procédure d'évaluation de la conformité visée à l'article 7, paragraphe 2;

    (b)le fabricant a établi la documentation technique;

    (c)les stations STIC portent le marquage CE requis;

    (d)le fabricant a respecté les exigences énoncées à l’article 7, paragraphes 7 et 8.

    3.Lorsqu'un importateur considère qu'une station STIC ne satisfait pas aux exigences énoncées à l'article 5, il ne met ce produit sur le marché qu'après qu’il a été mis en conformité. Lorsque la station STIC présente un risque, l’importateur en informe le fabricant et les autorités de surveillance du marché.

    4.Sur la station STIC ou, lorsque ce n’est pas possible, sur son emballage ou dans un document accompagnant la station STIC, les importateurs indiquent:

    (a)leur nom;

    (b)leur raison sociale ou leur marque déposée;

    (c)l'adresse à laquelle ils peuvent être contactés.

    Les coordonnées sont indiquées dans une langue aisément compréhensible par les utilisateurs finals et les autorités compétentes nationales.

    5.Les importateurs veillent à ce que les stations STIC soient accompagnées d’instructions et d’informations de sécurité fournies dans une langue aisément compréhensible par les utilisateurs finals, déterminée par l’État membre concerné.

    6.Tant qu'une station STIC est sous leur responsabilité, les importateurs s'assurent que les conditions de stockage ou de transport ne compromettent pas sa conformité aux exigences énoncées à l'article 5.

    7.Dans un souci de protection de la santé et de la sécurité des consommateurs, lorsque cela semble approprié au vu des risques que présente une station STIC, les importateurs:

    (a)effectuent des essais par sondage sur la station STIC commercialisée;

    (b)examinent les réclamations, les stations STIC non conformes et les rappels de stations STI-C et, le cas échéant, tiennent un registre en la matière;

    (c)informent les distributeurs d'un tel suivi.

    8.Les importateurs qui considèrent qu'une station STIC qu'ils ont mise sur le marché n'est pas conforme au présent règlement prennent sans délai les mesures correctives nécessaires pour la mettre en conformité, la retirer ou la rappeler, si nécessaire. Lorsque la station STIC présente un risque, les importateurs en informent immédiatement les autorités nationales compétentes des États membres dans lesquels ils l'ont mise à disposition, en fournissant des précisions, notamment, sur la non-conformité et toute mesure corrective adoptée.

    9.Pendant une durée de dix ans à compter de la mise sur le marché de la station STIC, les importateurs tiennent une copie de la déclaration UE de conformité à la disposition des autorités de surveillance du marché et s'assurent que la documentation technique peut être fournie à ces autorités, sur demande.

    10.Sur requête motivée d’une autorité nationale compétente, les importateurs lui communiquent toutes les informations et tous les documents nécessaires, sur support papier ou par voie électronique, pour démontrer la conformité d’une station STIC, dans une langue aisément compréhensible par cette autorité. Ils coopèrent, à la demande de cette autorité, à toute mesure adoptée en vue d’éliminer les risques présentés par les stations STIC qu’ils ont mises sur le marché.

    Article 10

    Obligations des distributeurs

    1.Lorsqu'ils mettent une station STIC à disposition sur le marché, les distributeurs agissent avec la diligence requise en ce qui concerne les exigences du présent règlement.

    2.Avant de mettre une station STIC à disposition sur le marché, les distributeurs vérifient:

    (a)qu'elle porte le marquage CE;

    (b)qu'elle est accompagnée des instructions et des informations de sécurité visées à l’article 7, paragraphe 9, fournies dans une langue aisément compréhensible par les utilisateurs finals dans l'État membre dans lequel elle doit être mise à disposition sur le marché;

    (c)que le fabricant et l'importateur se sont conformés aux exigences énoncées à l’article 7, paragraphes 7 et 8, et à l'article 9, paragraphe 4.

    3.Lorsqu'un distributeur considère qu'une station STIC n'est pas conforme à l'article 5, il ne la met à disposition sur le marché qu'après qu'elle a été mise en conformité. Lorsque la station STIC présente un risque, le distributeur en informe le fabricant ou l'importateur ainsi que les autorités de surveillance du marché.

    4.Tant qu'une station STIC est sous leur responsabilité, les distributeurs s'assurent que les conditions de stockage ou de transport ne compromettent pas sa conformité aux exigences énoncées à l'article 5.

    5.Les distributeurs qui considèrent qu'une station STIC qu'ils ont mise à disposition sur le marché n'est pas conforme au présent règlement ou à toute autre législation applicable de l’Union veillent à ce que des mesures correctives soient prises pour la mettre en conformité, la retirer ou la rappeler, selon le cas. Si la station STIC présente un risque, les distributeurs en informent immédiatement les autorités de surveillance du marché des États membres dans lesquels ils l'ont mise à disposition, en fournissant des précisions, notamment, sur la non-conformité et toute mesure corrective adoptée.

    6.Sur requête motivée d’une autorité nationale compétente, les distributeurs lui communiquent toutes les informations et tous les documents nécessaires pour démontrer la conformité d'une station STIC. Ils coopèrent, à la demande de cette autorité, à toute mesure visant à éliminer les risques présentés par des stations STIC qu’ils ont mises à disposition sur le marché.

    Article 11

    Cas dans lesquels les obligations des fabricants s'appliquent aux importateurs et aux distributeurs

    Lorsqu’un importateur ou un distributeur met une station STIC sur le marché sous son propre nom ou sa propre marque, ou lorsqu'il modifie une station STIC déjà mise sur le marché de telle sorte que sa conformité au présent règlement risque d’en être affectée, il est considéré comme un fabricant aux fins du présent règlement et est soumis aux obligations incombant au fabricant en vertu de l’article 7.

    Article 12

    Identification des opérateurs économiques

    Les opérateurs économiques transmettent aux autorités de surveillance du marché, à la demande de celles-ci, l’identité de:

    (a)tout opérateur économique qui leur a fourni une station STIC;

    (b)tout opérateur économique auquel ils ont fourni une station STIC.

    Les opérateurs économiques sont en mesure de communiquer les informations visées au premier alinéa pendant une durée de quinze ans à compter de la date à laquelle la station STIC leur a été fournie et pendant une durée de quinze ans à compter de la date à laquelle ils ont fourni la station STIC.

    Article 13

    Déclaration UE de conformité

    1.La déclaration UE de conformité atteste que le respect des exigences visées à l’article 5 a été démontré.

    2.La déclaration UE de conformité est structurée conformément au modèle figurant dans la partie B de l’annexe V, contient les éléments indiqués dans la partie A de l’annexe V et est tenue à jour. Elle est traduite dans la ou les langues requises par l'État membre dans lequel la station STIC est mise à disposition sur le marché.

    3.En établissant la déclaration UE de conformité, le fabricant assume la responsabilité de la conformité de la station STIC aux exigences énoncées dans le présent règlement.

    4.Lorsqu’une station STIC relève de plusieurs actes de l’Union imposant l’établissement d’une déclaration UE de conformité, il n’est établi qu’une seule déclaration UE de conformité pour l’ensemble de ces actes. Cette déclaration indique les actes concernés, ainsi que les références de leur publication.

    Article 14

    Principes généraux du marquage CE

    Le marquage CE est soumis aux principes généraux énoncés à l’article 30 du règlement (CE) nº 765/2008 du Parlement européen et du Conseil 24 .

    Article 15

    Règles et conditions d’apposition du marquage CE

    1.Le marquage CE est apposé de façon visible, lisible et indélébile sur la station STIC ou sur sa plaque signalétique.

    2.Le marquage CE est apposé avant que la station STIC ne soit mise sur le marché. Il peut être suivi d'un pictogramme ou de tout autre marquage indiquant un risque ou un usage particulier.

    Article 16

    Surveillance du marché de l’Union et contrôle des stations STIC entrant sur le marché de l’Union

    L'article 15, paragraphe 3, et les articles 16 à 29 du règlement (CE) nº 765/2008 s'appliquent aux stations STIC.

    Article 17

    Procédure applicable aux stations STIC qui présentent un risque au niveau national

    1.Lorsque les autorités de surveillance du marché d’un État membre ont pris des mesures conformément à l’article 20 du règlement (CE) nº 765/2008 ou qu’elles ont des raisons de croire qu’une station STIC présente un risque pour la santé ou la sécurité des personnes ou la sécurité routière et l’efficacité du trafic, elles effectuent une évaluation de la station STIC en question en tenant compte de toutes les exigences applicables du présent règlement. Les opérateurs économiques concernés coopèrent avec elles en tant que de besoin.

    Si, au cours de l'évaluation, les autorités de surveillance du marché constatent que la station STIC ne respecte pas les exigences du présent règlement, elles invitent sans tarder l'opérateur économique en cause à prendre toutes les mesures correctives appropriées pour la mettre en conformité avec ces exigences, la retirer du marché ou la rappeler dans un délai raisonnable, proportionné à la nature du risque.

    L’article 21 du règlement (CE) nº 765/2008 s’applique aux mesures visées au présent paragraphe, deuxième alinéa.

    2.Lorsque les autorités de surveillance du marché considèrent que la non-conformité n’est pas limitée au territoire national, elles informent sans tarder la Commission et les autres États membres des résultats de l’évaluation et des mesures qu’elles ont prescrites à l’opérateur économique.

    3.L’opérateur économique s’assure que toutes les mesures correctives appropriées sont prises dans l’ensemble de l’Union pour toutes les stations STIC en question qu’il a mises à disposition sur le marché de l’Union.

    4.Lorsque l'opérateur économique ne prend pas de mesures correctives adéquates dans le délai visé au paragraphe 1, deuxième alinéa, les autorités de surveillance du marché adoptent toutes les mesures provisoires appropriées pour interdire ou restreindre la mise à disposition de la station STIC sur leur marché national, pour la retirer de ce marché ou pour la rappeler.

    5.Les autorités de surveillance du marché informent sans tarder la Commission et les autres États membres des mesures provisoires visées au paragraphe 4. Cette information comprend toutes les précisions disponibles, notamment:

    (a)les données nécessaires pour identifier la station STIC non conforme;

    (b)l'origine de la station STIC;

    (c)le risque couru et la nature de la non-conformité alléguée de la station STIC aux exigences énoncées dans le présent règlement;

    (d)la nature et la durée des mesures provisoires adoptées;

    (e)les arguments avancés par l’opérateur économique.

    6.Les États membres autres que celui qui a entamé la procédure informent sans tarder la Commission et les autres États membres:

    (a)de toute mesure prise;

    (b)de toute information supplémentaire dont ils disposent à propos de la non-conformité de la station STIC concernée;

    (c)de leurs objections éventuelles à l'égard des mesures provisoires prises par l’État membre qui a entamé la procédure.

    7.Lorsque, dans les trois mois suivant la réception des informations visées au paragraphe 5, les autres États membres ou la Commission n'ont émis aucune objection à l’encontre d'une mesure provisoire prise par un État membre, cette mesure est réputée justifiée. Lorsque la mesure provisoire est réputée justifiée, les États membres veillent à ce que des mesures restrictives appropriées soient prises sans tarder à l'égard de la station STIC concernée, par exemple son retrait de leur marché. 

    Article 18

    Procédure de sauvegarde de l'Union

    1.Lorsque, au terme de la procédure visée à l’article 17, paragraphes 3 et 4, des objections ont été émises à l’encontre d’une mesure provisoire prise par un État membre ou lorsque la Commission considère qu’une mesure provisoire est contraire à la législation de l’Union, la Commission entame sans tarder des consultations avec les États membres et les opérateurs économiques en cause et procède à l’évaluation de la mesure provisoire. En fonction des résultats de cette évaluation, la Commission décide si la mesure nationale est ou non justifiée. 

    La Commission adresse sa décision à tous les États membres et la communique immédiatement aux opérateurs économiques concernés.

    2.Si la mesure provisoire est jugée justifiée dans une décision de la Commission, tous les États membres prennent les mesures nécessaires pour s’assurer du retrait de la station STIC non conforme de leur marché et ils en informent la Commission. Si la mesure provisoire est jugée non justifiée, l’État membre concerné la retire.

    Article 19

    Stations STIC conformes qui présentent un risque pour la santé et la sécurité au niveau national

    1.Si, à l'issue d'une évaluation effectuée en application de l'article 17, paragraphe 1, les autorités de surveillance du marché d’un État membre constatent qu'une station STIC, bien que conforme au présent règlement, présente un risque pour la santé ou la sécurité de personnes ou pour d'autres aspects de la protection de l’intérêt public, elles ordonnent à l’opérateur économique en cause de prendre une ou plusieurs des mesures correctives suivantes, en proportion de la nature du risque:

    (a)prendre toutes les mesures appropriées pour faire en sorte que la station STIC ne présente plus ce risque au moment de sa mise sur le marché;

    (b)retirer la station STIC du marché;

    (c)rappeler la station STIC.

    Les autorités de surveillance du marché prescrivent un délai raisonnable, proportionné à la nature du risque, dans lequel l’opérateur économique est tenu de prendre les mesures visées au premier alinéa.

    2.L’opérateur économique s’assure que la mesure corrective est prise dans l’ensemble de l’Union pour toutes les stations STIC en question qu’il a mises à disposition sur le marché de l’Union.

    3.Les autorités de surveillance du marché informent immédiatement la Commission et les autres États membres des mesures correctives qu’elles ont ordonnées en application du paragraphe 1 et de toutes les précisions disponibles, dont:

    (a)les données nécessaires à l’identification de la station STIC concernée;

    (b)l’origine et la chaîne d’approvisionnement de la station STIC;

    (c)la nature du risque;

    (d)la nature et la durée des mesures correctives.

    4.La Commission entame sans tarder des consultations avec les États membres et les opérateurs économiques en cause et évalue les mesures correctives ordonnées par les autorités de surveillance du marché. En fonction des résultats de cette évaluation, la Commission décide si la mesure est ou non justifiée et, si nécessaire, propose des mesures appropriées.

    5.La Commission adresse sa décision à tous les États membres et la communique immédiatement à l’opérateur ou aux opérateurs économiques concernés.

    Article 20

    Non-conformité formelle

    1.Sans préjudice de l’article 17, un État membre qui fait l'une des constatations ci-après enjoint à l’opérateur économique concerné de mettre un terme à la non-conformité:

    (a)le marquage CE a été apposé en violation de l’article 14 ou 15;

    (b)le marquage CE n'a pas été apposé;

    (c)la déclaration UE de conformité n'a pas été établie;

    (d)la déclaration UE de conformité n’a pas été établie correctement;

    (e)la documentation technique n’est pas disponible ou n’est pas complète;

    (f)les informations visées à l’article 5, paragraphe 6, ou à l’article 7, paragraphe 3, sont absentes, fausses ou incomplètes;

    (g)une autre prescription administrative prévue à l’article 5 ou à l’article 7 n’est pas remplie.

    2.Si la non-conformité visée au paragraphe 1 persiste, l’État membre concerné prend toutes les mesures appropriées pour restreindre ou interdire la mise à disposition de la station STIC sur le marché ou pour assurer son rappel ou son retrait du marché.

    Chapitre IV

    Mise en service et exploitation de stations STIC

    Article 21

    Mise en service de stations STIC centrales

    1.Avant de mettre en service des stations STIC centrales, l’exploitant de station STIC s’assure qu’elles ont été conçues et fabriquées conformément aux exigences énoncées à l’article 5. À cette fin, il prend l’une des mesures suivantes:

    (a)acheter une station STIC centrale qui a été mise sur le marché conformément au chapitre III. Dans ce cas, les paragraphes 2 et 3 du présent article ne s’appliquent pas;

    (b)intégrer les capacités de la station STIC dans un centre de contrôle de la circulation ou un serveur central. Dans ce cas, les paragraphes 2 et 3 du présent article s’appliquent et les articles 7 à 20 ne s’appliquent pas à la station STIC centrale.

    2.Les exploitants de station STIC établissent la documentation technique requise visée dans la partie C de l'annexe V et mettent en œuvre la procédure d'évaluation de la conformité visée dans la partie C de l'annexe V. Lorsqu'il a été démontré, à l'aide de cette procédure, qu'une station STIC centrale est conforme aux exigences énoncées à l'article 5, les exploitants de station STIC établissent une déclaration UE de conformité conformément à la partie D de l'annexe V.

    3.Les exploitants de station STIC conservent la documentation technique et la déclaration UE de conformité aussi longtemps que la station STIC centrale est en service.

    Article 22

    Obligations des exploitants de station STIC

    1.Les exploitants de station STIC veillent à ce que toutes leurs stations STIC soient mises en service et exploitées conformément au présent règlement.

    2.Avant de mettre en service une station STIC, l’exploitant de la station STIC vérifie:

    (a)qu'elle est munie du marquage CE;

    (b)que la documentation technique visée à l'article 7 est disponible;

    (c)que la station STIC est certifiée conformément aux exigences de l’annexe IV, point 1.6.2.

    Les obligations prévues au premier alinéa, points a) et b), du présent paragraphe ne s’appliquent pas aux stations STIC centrales mises en service conformément à l’article 21, paragraphe 1, point b).

    En outre, avant la mise en service d’une station STIC, l'exploitant de la station STIC l’inscrit dans le système de l’UE pour la gestion des authentifiants de sécurité des STIC, conformément à l’article 23, paragraphe 3.

    3.Avant la mise en service d’une station STIC, l'exploitant de la station STIC s'accorde avec le propriétaire de celle-ci sur les droits et les obligations relatifs à l'exploitation, à l'entretien et à la mise à jour de la station STIC, y compris sur les modalités d’information de l’utilisateur final.

    4.Lorsqu’une station STIC est inscrite dans le système de l’UE pour la gestion des authentifiants de sécurité des STIC, elle est enregistrée dans un registre des stations STIC de son autorité d’inscription, de même que l’identification de son exploitant. Le point de contact STIC tient à jour une liste des registres des stations STIC.

    5.L'exploitant de station STIC veille à ce que, lorsque la station STIC est en service, elle reste conforme aux exigences de l'article 5 applicables au moment de sa mise en service.

    6.Lorsque la mise à niveau d'une station STIC s'impose, que ce soit à l'initiative de son exploitant ou à la suite d'une modification du présent règlement, l'exploitant veille à ce que la station STIC soit conforme à la version la plus récente des spécifications applicables visées à l'article 5.

    7.Lorsque la mise à niveau d'une station STIC s'impose à l'initiative du fabricant ou de son mandataire, ledit fabricant ou mandataire et les exploitants de station STIC coopèrent pour veiller à ce que la station STIC soit conforme à la version la plus récente des spécifications applicables visées à l'article 5.

    Chapitre V

    Sécurité

    Article 23

    Inscription des stations STIC dans le système de l’UE pour la gestion des authentifiants de sécurité des STIC

    1.Le système de l’UE pour la gestion des authentifiants de sécurité des STIC est mis en place pour permettre la fourniture de communications sécurisées et de confiance entre les stations STIC.

    2.Le fonctionnement du système de l’UE pour la gestion des authentifiants de sécurité des STIC est conforme aux exigences énoncées dans:

    (a)l'annexe III (politique de certification), qui définit les exigences de gestion des certificats de clé publique pour les services STIC par les entités qui les ont délivrés et leur usage par les entités finales;

    (b)l'annexe IV (politique de sécurité), qui définit les exigences de gestion de la sécurité de l’information dans les STIC.

    3.Toutes les stations STIC sont inscrites dans le système de l’UE pour la gestion des authentifiants de sécurité des STIC et en respectent les règles, dans le respect des spécifications énoncées aux annexes III et IV.

    Article 24

    Autorité chargée de la politique de certification des STIC

    1.L'autorité chargée de la politique de certification des STIC est chargée de gérer la politique de certification et les autorisations relatives à l’infrastructure à clés publiques, conformément à la politique de certification énoncée à l'annexe III.

    2.La Commission fait fonction d’autorité chargée de la politique de certification des STIC jusqu’à ce qu’une entité spécifique soit instituée. 

    Article 25

    Gestionnaire de la liste de confiance

    1.Le gestionnaire de la liste de confiance est chargé de produire et mettre à jour la liste de confiance européenne des certificats (European Certificate Trust List, ECTL) conformément à la politique de certification exposée à l’annexe III et de présenter des rapports d’activité réguliers à l’autorité chargée de la politique de certification des STIC en ce qui concerne la sûreté de fonctionnement globale du modèle de confiance pour les STIC.

    2.La Commission fait fonction de gestionnaire de la liste de confiance jusqu’à ce qu’une entité spécifique soit instituée.

    Article 26

    Point de contact STIC

    1.Le point de contact STIC est chargé d'assurer toutes les communications avec les gestionnaires des autorités de certification primaire et de publier le certificat de clé publique du gestionnaire de la liste de confiance et l'ECTL conformément à la politique de certification exposée à l'annexe III.

    2.La Commission fait fonction de point de contact STIC jusqu’à ce qu’une entité spécifique soit instituée.

    Article 27

    Système de management de la sécurité de l’information

    Chaque exploitant de station STIC utilise un système de management de la sécurité de l'information conforme à la norme ISO/IEC 27001 et aux exigences supplémentaires de l’annexe IV, point 1.3.1. 

    Article 28

    Respect de la politique de sécurité

    Les exploitants de station STIC sollicitent et obtiennent régulièrement une certification conforme aux exigences de l’annexe IV, point 1.7. 

    Chapitre VI

    Mise en œuvre

    Article 29

    Mise en œuvre du réseau STIC

    1.La Commission prend en charge les tâches suivantes dans la mise en œuvre du réseau STIC:

    (a)tâches de gouvernance:

    (1)préparer les mises à jour du cadre de gouvernance des STIC;

    (2)soutenir l’élaboration de principes communs pour le traitement licite des données à caractère personnel par les responsables du traitement et les sous-traitants au sein du réseau STIC;

    (3)servir de point de contact en ce qui concerne la mise en œuvre du réseau STIC pour les exploitants et fabricants de stations STIC, les groupes d’utilisateurs de STI et les parties prenantes des pays tiers;

    (4)réexaminer les éléments suivants:

    (a)critères d’évaluation des STIC à utiliser par les laboratoires d’essai et autres organismes d’évaluation dans le processus d’évaluation de la conformité;

    (b)spécifications de référence pour les STIC, y compris les normes de base et d’essai à utiliser dans les différentes étapes du processus d’évaluation;

    (b)tâches de supervision: superviser la gestion des incidents de sécurité de grande ampleur et de forte gravité qui ont une incidence sur l’ensemble du réseau STIC (y compris dans des situations de rétablissement après sinistre où l’algorithme cryptographique est compromis);

    (c)tâches de l'autorité chargée de la politique de certification des STIC:

    (1)gestion de la politique de certification;

    (2)gestion des autorisations relatives à l’infrastructure à clés publiques.

    2.Dans l’exécution des tâches visées au paragraphe 1, la Commission est assistée par un groupe d’experts composé de représentants des parties prenantes publiques et privées, en particulier des fabricants et des exploitants de stations STIC au sein du réseau STIC.

    Chapitre VII

    Dispositions finales

    Article 30

    Mesures provisoires

    En cas de situation d’urgence compromettant le bon fonctionnement du réseau STIC et ayant de graves incidences directes sur la sécurité routière, la cybersécurité ou la disponibilité et l’intégrité des services STIC, la Commission peut adopter une décision arrêtant des mesures provisoires afin de remédier à cette situation. Cette décision se limite strictement à traiter les causes et les conséquences de cette situation. Elle est applicable jusqu’à ce que le présent règlement soit modifié pour remédier à cette situation.

    Article 31

    Présentation de rapports

    1.Les États membres surveillent la mise en œuvre du présent règlement sur leur territoire et rendent compte des progrès réalisés dans sa mise en œuvre en présentant les rapports réguliers visés à l’article 17, paragraphe 3, de la directive 2010/40/UE. Ces rapports concernent notamment:

    (a)une description des initiatives publiques et de type public-privé pertinentes pour le déploiement des STIC, y compris leurs objectifs, leur calendrier, leurs étapes, leurs ressources, le ou les acteurs principaux et leur statut;

    (b)la couverture du réseau routier par type de route pour chacun des services STIC prioritaires de véhicule à infrastructure énumérés à l’annexe I;

    (c)le nombre de stations STIC centrales et de stations de bord de route déployées sur leur territoire.

    Les États membres communiquent leur premier rapport au plus tard le 27 août 2020.

    2.Les autorités de certification racine figurant dans la liste de confiance européenne des certificats visée à l’annexe III notifient à la Commission, au plus tard le 31 décembre 2020 et, par la suite, au plus tard le 31 décembre de chaque année, le nombre de stations STIC fixes et mobiles inscrites et opérationnelles relevant de leur autorité.

    Article 32

    Stations STIC mises sur le marché avant le 31 décembre 2019

    1.L'autorité chargée de la politique de certification des STIC peut, au cas par cas, accorder l'inscription dans le modèle de confiance STIC aux stations STIC mises sur le marché au plus tard le 31 décembre 2019 qui ne satisfont pas pleinement aux exigences du présent règlement quant à la sécurité des STIC, ainsi qu'aux stations STIC du même type/modèle mises sur le marché au plus tard le 30 juin 2021, pour autant que les conditions énoncées au paragraphe 2 soient remplies. L'inscription peut également être accordée dans les mêmes conditions aux stations STIC du même type/modèle destinées à remplacer des stations STIC visées dans la première phrase qui sont défectueuses ou cassées.

    2.L’autorité chargée de la politique des certificats STIC peut inscrire les stations STIC visées au paragraphe 1 dans le modèle de confiance STIC dans les conditions suivantes:

    (a)le même niveau de sécurité et de confiance que celui requis par le présent règlement est assuré;

    (b)il est démontré que les stations STIC concernées, ainsi que la procédure d’inscription envisagée, ne font courir aucun risque supplémentaire au réseau STIC.

    3.L’autorité chargée de la politique de certification des STIC fonde sa décision sur le rapport d’un auditeur d'infrastructures à clés publiques accrédité et sur une évaluation des failles de sécurité effectuée par un organisme d’évaluation de la conformité.

    Article 33

    Réexamen

    1.Pour le [OP - veuillez insérer la date: 3 ans après l'entrée en vigueur du présent règlement] au plus tard, la Commission procède au réexamen de la mise en œuvre du présent règlement et, le cas échéant, adopte de nouvelles spécifications communes relevant du champ d'application de celui-ci.

    2.Lorsque des parties prenantes ont l’intention de déployer dans le réseau STIC un service ou une méthode de communication nouveaux ou actualisés, ou encore d’autres solutions innovantes, notamment des technologies pour lesquelles des prototypes sont actuellement à l'essai, elles soumettent au préalable à la Commission un dossier contenant les spécifications techniques de la solution innovante et les informations relatives à son degré de maturité et à sa compatibilité avec le présent règlement. Ces spécifications techniques sont élaborées dans le respect des principes d’ouverture, de consensus et de transparence définis à l’annexe II du règlement (UE) nº 1025/2012.

    La Commission analyse ensuite le dossier dans les meilleurs délais et entame l'examen du dossier avec le groupe d’experts visé à l’article 29, paragraphe 2, dans un délai de deux mois, en vue d’une éventuelle modification du présent règlement. Le groupe d’experts évalue la nécessité d'adopter des spécifications communes intégrant les nouvelles solutions dans le réseau STIC et formule un avis, au plus tard six mois après la réception du dossier. Le cas échéant, le Centre commun de recherche de la Commission contribue aux discussions en question en produisant une évaluation technique indépendante.

    La présentation de solutions innovantes à la Commission et, en conséquence, la modification éventuelle du présent règlement peuvent intervenir à tout moment après l’entrée en vigueur du présent règlement.

    3.Pour préserver la continuité des services STIC prioritaires énumérés à l'annexe I, les modifications futures garantissent la compatibilité et l’interopérabilité avec les stations STIC existantes mises en service conformément au présent règlement, ou définissent une trajectoire de migration appropriée.

    Article 34

    Entrée en vigueur

    Le présent règlement entre en vigueur le vingtième jour suivant celui de sa publication au Journal officiel de l’Union européenne.

    Il est applicable à partir du 31 décembre 2019.

    Le présent règlement est obligatoire dans tous ses éléments et directement applicable dans tout État membre.

    Fait à Bruxelles, le 13.3.2019

       Par la Commission

       Le président,
       Jean-Claude JUNCKER

    (1)    https://ec.europa.eu/transport/themes/its/c-its_en
    (2)     https://www.c-roads.eu
    (3)    Communication de la Commission au Parlement européen, au Conseil, au Comité économique et social européen et au Comité des régions intitulée «Une stratégie européenne relative aux systèmes de transport intelligents coopératifs, jalon d'une mobilité coopérative, connectée et automatisée» [COM(2016) 766 final].
    (4)    Directive 2010/40/UE du Parlement européen et du Conseil du 7 juillet 2010 concernant le cadre pour le déploiement de systèmes de transport intelligents dans le domaine du transport routier et d’interfaces avec d’autres modes de transport (JO L 207 du 6.8.2010, p. 1).
    (5)    Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données) (JO L 119 du 4.5.2016, p. 1).
    (6)    Directive 2002/58/CE du Parlement européen et du Conseil du 12 juillet 2002 concernant le traitement des données à caractère personnel et la protection de la vie privée dans le secteur des communications électroniques (directive vie privée et communications électroniques) (JO L 201 du 31.7.2002, p. 37).
    (7)    Directive 95/46/CE du Parlement européen et du Conseil du 24 octobre 1995 relative à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données («directive sur la protection des données») (JO L 281 du 23.11.1995, p. 31).
    (8)    Décision d'exécution de la Commission du 7 avril 2016 modifiant la décision d'exécution C(2014) 1921 de la Commission établissant un programme de travail pluriannuel 2014-2020 pour une assistance financière dans le domaine du mécanisme pour l’interconnexion en Europe (MIE) – secteur des transports pour la période 2014-2020.
    (9)    JO L 207 du 6.8.2010, p. 1.
    (10)    Communication de la Commission au Parlement européen, au Conseil, au Comité économique et social européen et au Comité des régions intitulée «Une stratégie européenne relative aux systèmes de transport intelligents coopératifs, jalon d'une mobilité coopérative, connectée et automatisée» [COM(2016) 766 final].
    (11)    Règlement délégué (UE) nº 886/2013 de la Commission du 15 mai 2013 complétant la directive 2010/40/UE du Parlement européen et du Conseil en ce qui concerne les données et procédures pour la fourniture, dans la mesure du possible, d’informations minimales universelles sur la circulation liées à la sécurité routière gratuites pour les usagers (JO L 247 du 18.9.2013, p. 6).
    (12)    Règlement délégué (UE) 2015/962 de la Commission du 18 décembre 2014 complétant la directive 2010/40/UE du Parlement européen et du Conseil en ce qui concerne la mise à disposition, dans l'ensemble de l'Union, de services d'informations en temps réel sur la circulation (JO L 157 du 23.6.2015, p. 21).
    (13)    JO L 194 du 19.7.2016, p. 1.
    (14)    Décision 2008/671/CE de la Commission du 5 août 2008 sur l’utilisation harmonisée du spectre radioélectrique dans la bande de fréquences 5 8755 905 MHz pour les applications des systèmes de transport intelligents liées à la sécurité (JO L 220 du 15.8.2008, p. 24).
    (15)    Mandat de normalisation M/453 adressé au CEN, au CENELEC et à l'ETSI dans le domaine des technologies de l'information et de la communication en appui à l'interopérabilité des systèmes coopératifs pour le transport intelligent dans la Communauté européenne.
    (16)    Directive 2014/53/UE du Parlement européen et du Conseil du 16 avril 2014 relative à l'harmonisation des législations des États membres concernant la mise à disposition sur le marché d'équipements radioélectriques et abrogeant la directive 1999/5/CE (JO L 153 du 22.5.2014, p. 62).
    (17)    Décision nº 768/2008/CE du Parlement européen et du Conseil du 9 juillet 2008 relative à un cadre commun pour la commercialisation des produits et abrogeant la décision 93/465/CEE du Conseil (JO L 218 du 13.8.2008, p. 82).
    (18)    Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données) (JO L 119 du 4.5.2016, p. 1).
    (19)    Directive 2002/58/CE du Parlement européen et du Conseil du 12 juillet 2002 concernant le traitement des données à caractère personnel et la protection de la vie privée dans le secteur des communications électroniques (directive vie privée et communications électroniques) (JO L 201 du 31.7.2002, p. 37).
    (20)    Règlement (CE) n° 45/2001 du Parlement européen et du Conseil du 18 décembre 2000 relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel par les institutions et organes communautaires et à la libre circulation de ces données (JO L 8 du 12.1.2001, p. 1).
    (21)    Directive 2004/52/CE du Parlement européen et du Conseil du 29 avril 2004 concernant l’interopérabilité des systèmes de télépéage routier dans la Communauté (JO L 166 du 30.4.2004, p. 124).
    (22)    Décision de la Commission 2009/750/CE du 6 octobre 2009 relative à la définition du service européen de télépéage et à ses aspects techniques (JO L 268 du 13.10.2009, p. 11).
    (23)    Règlement (UE) nº 165/2014 du Parlement européen et du Conseil du 4 février 2014 relatif aux tachygraphes dans les transports routiers, abrogeant le règlement (CEE) nº 3821/85 du Conseil concernant l'appareil de contrôle dans le domaine des transports par route et modifiant le règlement (CE) nº 561/2006 du Parlement européen et du Conseil relatif à l'harmonisation de certaines dispositions de la législation sociale dans le domaine des transports par route (JO L 60 du 28.2.2014, p. 1).
    (24)    Règlement (CE) nº 765/2008 du Parlement européen et du Conseil du 9 juillet 2008 fixant les prescriptions relatives à l'accréditation et à la surveillance du marché pour la commercialisation des produits et abrogeant le règlement (CEE) nº 339/93 du Conseil (JO L 218 du 13.8.2008, p. 30).
    Top

    ANNEXE I

    1.Introduction

    La présente annexe contient les profils de service pour les services STI-C prioritaires. Un profil de service est une configuration particulière de normes, définissant la mise en œuvre de différentes options de normes.

    1.1.Références

    Les références suivantes sont utilisées dans la présente annexe:

    TS 102 894-2    ETSI TS 102 894-2, Systèmes de transport intelligents (STI); Exigences liées aux utilisateurs et aux applications; Partie 2: dictionnaire de données commun pour la couche applications et installations [Intelligent Transport Systems (ITS); Users and applications requirements; Part 2: Applications and facilities layer common data dictionary], V1.3.1 (2018-08)

    EN 302 637-2    ETSI EN 302 637-2, Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule - Ensemble d’applications de base - Partie 2: spécification du service de base de sensibilisation coopérative, V1.4.0 (2018-08); cette référence s'entend comme une référence à la version 1.4.1 à compter de la date de publication de cette version.

    EN 302 637-3    ETSI EN 302 637-3, Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule - Ensemble d’applications de base - Partie 3: spécifications du service de base de notification environnementale décentralisée, v1.3.0 (201808); cette référence s'entend comme une référence à la version 1.3.1 à compter de la date de publication de cette version.

    ECE 13    Règlement nº 13 de la Commission économique pour l'Europe des Nations unies (CEE-ONU), Prescriptions uniformes relatives à l'homologation des véhicules des catégories M, N et O en ce qui concerne le freinage [2016/194]

    ECE 13H    Règlement nº 13-H de la Commission économique pour l’Europe des Nations unies (CEE-ONU), Prescriptions uniformes relatives à l’homologation des voitures particulières en ce qui concerne le freinage [2015/2364]

    ECE 48    Règlement nº 48 de la Commission économique pour l'Europe des Nations unies (CEE-ONU), Prescriptions uniformes relatives à l'homologation des véhicules en ce qui concerne l'installation des dispositifs d'éclairage et de signalisation lumineuse [2016/1723]

    ECE 121    Règlement nº 121 de la Commission économique pour l'Europe des Nations unies (CEE-ONU), Prescriptions uniformes relatives à l'homologation des véhicules en ce qui concerne l'emplacement et les moyens d'identification des commandes manuelles, des témoins et des indicateurs [2016/18]

    ISO/TS 19321    ISO/TS 19321, Systèmes intelligents de transport -- Coopérative STI -- Dictionnaire de structures de données d’informations dans les véhicules (IVI) [Intelligent transport systems — Cooperative ITS — Dictionary of in-vehicle information (IVI) data structures] (15 avril 2015)

    ISO 639-1    Codes pour la représentation des noms de langue -- Partie 1: Code alpha-2 [Codes for the representation of names of languages — Part 1: Alpha-2 code]

    ISO/TS 14823    ISO/TS 14823:2017. Systèmes de transport intelligents -- Dictionnaire de données graphiques [Intelligent transport systems – Graphic data dictionary]

    1.2.Notations et abréviations

    Les notations et abréviations qui suivent apparaissent dans l’annexe:

    ABS                Système antiblocage

    ASR                Régulation antipatinage

    AT                Ticket d’autorisation

    CAM                Message de sensibilisation coopérative

    STI-C            Systèmes de transport intelligents coopératifs

    DCC                Gestion décentralisée de l’encombrement

    DEN                Notification environnementale décentralisée

    DENM            Message de notification environnementale décentralisée

    GNSS            Système mondial de radionavigation par satellite

    I2V                Infrastructure à véhicule

    IRC                Conteneur de réduction d’impact

    IVI                Informations d'infrastructure à véhicule

    MAP                Informations topologiques pour l’intersection

    SPAT                Signal Phase and Timing (Phases et minutage en matière de signalisation)

    SREM            Message étendu de demande d’allumage de signal

    SSEM            Message étendu de demande d’état d’allumage de signal

    TC                Classe de trafic

    TMS                Système de gestion du trafic

    TOC                Centre d’opérations du trafic

    TRCO            Condition de déclenchement

    TTC                Temps restant avant la collision

    V2V                Véhicule à véhicule

    1.3.Définitions

    Les définitions suivantes sont utilisées dans la présente annexe:

    (a)«véhicule à l’arrêt», un véhicule dont la vitesse absolue est inférieure ou égale à 8 centimètres par seconde, cet état étant déterminé par des capteurs embarqués;

    (b)«véhicule d'urgence», un véhicule désigné pour intervenir en cas d’urgence et autorisé à cette fin. Les véhicules d'urgence sont souvent autorisés par la loi à enfreindre les règles conventionnelles de circulation routière afin d’atteindre leur destination le plus rapidement possible, par exemple (mais pas uniquement) en franchissant une intersection lorsque le feu est au rouge ou en dépassant les limitations de vitesse.

    2.Liste de services prioritaires

    Catégorie de service

    Service

    Profil de service

    Services de véhicule à véhicule

    Embouteillage

    Fin de file dangereuse

    Section 3

    Embouteillage

    Embouteillage à l’avant

    Section 4

    Avertissement en cas de véhicule à l’arrêt

    Véhicule immobilisé

    Section 5

    Avertissement en cas de véhicule à l’arrêt

    Véhicule en panne

    Section 6

    Avertissement en cas de véhicule à l’arrêt

    Après accident

    Section 7

    Avertissement en cas de véhicule spécial

    Véhicule d'urgence en intervention

    Section 8

    Avertissement en cas de véhicule spécial

    Véhicule d'urgence de sécurisation à l’arrêt

    Section 9

    Avertissement en cas de véhicule spécial

    Avertissement en cas de véhicule de dépannage à l’arrêt

    Section 10

    Échange d’IRC

    Demande d’IRC

    Section 11

    Échange d’IRC

    Réponse d’IRC

    Section 12

    Situation dangereuse

    Allumage du feu-stop électronique d'urgence

    Section 13

    Situation dangereuse

    Intervention du freinage automatique

    Section 14

    Situation dangereuse

    Intervention du système de retenue réversible de l’occupant

    Section 15

    Conditions météorologiques défavorables

    Brouillard

    Section 16

    Conditions météorologiques défavorables

    Précipitation

    Section 17

    Conditions météorologiques défavorables

    Perte de traction

    Section 18

    Services d'infrastructure à véhicule

    Signalisation à bord des véhicules

    Informations dynamiques sur les limitations de vitesse

    Section 19

    Signalisation à bord des véhicules

    «Texte libre» VMS (signalisation à messages variables) intégré

    Section 20

    Signalisation à bord des véhicules

    Autres informations de signalisation

    Section 21

    Notification des endroits dangereux

    Zone d’accident

    Section 22

    Notification des endroits dangereux

    Embouteillages à l’avant

    Section 23

    Notification des endroits dangereux

    Véhicule à l’arrêt

    Section 24

    Notification des endroits dangereux

    Avertissement en cas de conditions météorologiques particulières

    Section 25

    Notification des endroits dangereux

    Route temporairement glissante

    Section 26

    Notification des endroits dangereux

    Animal ou personne sur la route

    Section 27

    Notification des endroits dangereux

    Obstacle sur la route

    Section 28

    Avertissement en cas de travaux routiers

    Fermeture de voie (et autres restrictions)

    Section 29

    Avertissement en cas de travaux routiers

    Fermeture de routes

    Section 30

    Avertissement en cas de travaux routiers

    Travaux routiers — mobiles

    Section 31

    Intersections équipées de feux de signalisation

    Vitesse d’approche optimale recommandée pour le passage au feu vert

    Section 32

    Intersections équipées de feux de signalisation

    Octroi d’un statut de priorité aux transports publics

    Section 33

    3.Embouteillage — Fin de file dangereuse

    3.1.Description du service de systèmes de transport intelligents coopératifs (STI-C)

    Ce service STI-C transmet des informations de véhicule à véhicule (V2V) concernant une situation dans laquelle un égo-véhicule détecte la fin d’un embouteillage («fin de file dangereuse»). Une telle situation se présente lorsque la voie de circulation sur laquelle l'égo-véhicule se trouve est bloquée et que le véhicule en question ne peut pas poursuivre sur sa voie. L’environnement urbain n’est pas pris en compte dans le cadre de ce service.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«situations dangereuses — allumage du feu-stop électronique d'urgence».

    3.2.Conditions de déclenchement

    3.2.1.Conditions préalables

    (1)Les conditions préalables suivantes doivent systématiquement être remplies pour que ce service STI-C soit déclenché:

    (a)l'égo-véhicule se trouve dans un environnement non urbain, tel que déterminé d’une des manières suivantes (au minimum):

    ·la vitesse est supérieure à 80 km/h pendant un intervalle de temps d’au moins 30 secondes au cours des 60 secondes précédant chaque détection et la valeur absolue de l’angle de braquage du volant est inférieure à 90 ° pendant un intervalle de temps d’au moins 30 secondes au cours des 60 secondes précédant chaque détection (une «fin de file dangereuse» ne doit pas être détectée dans un environnement non autoroutier);

    ·un capteur d’images embarqué indique un environnement non urbain;

    ·une carte numérique embarquée indique un environnement non urbain.

    (2)La vitesse et la décélération du véhicule doivent être déterminées par le signal de bus du véhicule et non par un système mondial de radionavigation par satellite (GNSS). La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée. Cette exigence doit s’appliquer à toutes les occurrences ultérieures d’analyse de vitesse et de décélération du véhicule.

    (3)La vitesse et les valeurs d’angle doivent être mesurées en continu. Les conditions doivent être remplies pendant toute la durée de la mesure. Le processus doit recommencer si les conditions ne sont pas remplies pendant la totalité de cette durée.

    3.2.2.Conditions spécifiques au service

    (4)Si les conditions préalables mentionnées au point (1) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un message de notification environnementale décentralisée (DENM) doit être déclenchée:

    ·TRCO_0 ET (TRCO_2 OU TRCO_3 OU TRCO_4 OU TRCO_5 OU TRCO_6)

    ·TRCO_1 ET TRCO_2.

    Tableau 1: Conditions spécifiques au service «Embouteillage — Fin de file dangereuse»

    Numéro de TRCO

    Condition de déclenchement (TRCO)

    État

    TRCO_0

    L'égo-véhicule roule à une vitesse initiale supérieure à 80 km/h et la décélération initiale est inférieure ou égale à 0,1 m/s². Le conducteur réagit à la fin de file dangereuse en réduisant sa vitesse, passant ainsi de la vitesse initiale à une vitesse cible inférieure ou égale à 30 km/h. Un maximum de 10 secondes doit s’écouler entre la vitesse initiale et la vitesse cible. Une décélération instantanée supérieure à 3,5 m/s² de la vitesse initiale à la vitesse cible est détectée.

    réaction du conducteur

    TRCO_1

    Les passagers de l'égo-véhicule réagissent à l’embouteillage en allumant les feux de détresse pendant au moins 3 secondes.

    réaction du conducteur

    TRCO_2

    Au moins trois autres véhicules se déplaçant à une vitesse d’au moins 7 km/h ont allumé leurs feux de détresse pendant au moins 3 secondes, tel qu’indiqué par:

    ·un capteur d’images embarqué; ou

    ·des CAM.

    environnement ou capteurs embarqués

    TRCO_3

    Au moins un DENM correspondant au service STI-C «Embouteillage - Fin de file dangereuse» a été reçu.

    environnement

    TRCO_4

    Au moins cinq DENM différents (c’est-à-dire présentant des actionID différents) correspondant au service STIC «Embouteillage - Embouteillage à l’avant» ont été reçus du trafic aval.

    environnement

    TRCO_5

    Au moins un DENM correspondant au service STI-C «Avertissement en cas de véhicule spécial - Véhicule d'urgence de sécurisation à l’arrêt» a été reçu, la linkedCause étant égale à Conditions de circulation ou Fin de file dangereuse.

    environnement

    TRCO_6

    Les capteurs embarqués de l'égo-véhicule reconnaissent que le véhicule fait face à une fin de file dangereuse.

    capteurs embarqués

    (5)Un nouveau DENM ne doit pas être demandé dans le Detection Blocking Time (Temps de blocage de la détection). Le Detection Blocking Time est déclenché après la détection de l’événement et la demande d’un DENM à cet effet. De cette façon, un seul événement ne peut pas surcharger le canal de transmission. Le Detection Blocking Time doit s’élever à 60 secondes, qu’importe la façon dont l’événement est détecté. La période de détection entre deux événements détectés doit être au moins égale au Detection Blocking Time. L’algorithme de détection peut être exécuté pendant le Detection Blocking Time.

    Remarque: aucune période n’est présentée pour les manœuvres de freinage, car la vitesse initiale de l'égo-véhicule n’a pas de limite supérieure.

    (6)Une condition est valide aussi longtemps qu’elle est active et pendant une période supplémentaire de 5 secondes (la période augmente le déterminisme de l’algorithme de détection). La validité diminue à partir du moment où la condition n’est plus remplie, facilitant ainsi la combinaison de conditions de déclenchement.

    (7)Les CAM et les DENM de véhicules télécommandés utilisés pour évaluer les conditions spécifiques au service tel que décrit précédemment doivent être pertinents pour l'égo-véhicule. La pertinence doit être déterminée d’une des manières suivantes:

    (a)une carte numérique indique que l’événement et l'égo-véhicule sont séparés par une distance inférieure à 500 m et qu’ils partagent un même sens de déplacement;

    (b)une correspondance de l’historique de cheminement indique que l’événement et l'égo-véhicule sont séparés par une distance inférieure à 500 m et partagent un même sens de déplacement;

    (c)la distance euclidienne entre l’événement et l'égo-véhicule est inférieure à 500 m et la valeur absolue de la différence de cap est inférieure à 10 °. Les positions de référence de l’embouteillage d’après les DENM se situent dans une zone couvrant un champ de -45 à +45 ° à partir de l’axe longitudinal de l'égo-véhicule.

    Remarque: lors du comptage des véhicules ou des événements, le changement de ticket d’autorisation (AT) doit être envisagé de manière à garantir qu’aucun véhicule ou événement n’est compté plusieurs fois.

    3.2.3.Qualité des informations

    (8)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont la situation est détectée. Les TRCO [voir point (4)] sont répartis en groupes: réaction du conducteur, dynamique du véhicule, environnement et capteurs embarqués. La valeur informationQuality doit être établie conformément au tableau suivant. Il convient d’utiliser la valeur la plus élevée possible.

    Tableau 2: Qualité des informations relatives au service «Embouteillage — Fin de file dangereuse»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    Au moins une TRCO issue du groupe réaction du conducteur ET environnement est remplie.

    1

    Au moins une TRCO issue du groupe réaction du conducteur ET capteurs embarqués est remplie.

    2

    Au moins une TRCO issue du groupe réaction du conducteur ET l’environnement ET capteurs embarqués est remplie.

    3

    3.3.Conditions de terminaison

    (9)Une terminaison du service STI-C ne doit pas être envisagée.

    3.3.1.Annulation

    (10)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    3.3.2.Négation

    (11)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    3.4.Mise à jour

    (12)Un DENM de mise à jour ne doit pas être utilisé pour ce service STI-C.

    3.5.Durée de répétition et intervalle de répétition

    (13)Les nouveaux DENM doivent être répétés pendant une repetitionDuration (durée de répétition) de 20 secondes avec un repetitionInterval (intervalle de répétition) de 0,5 seconde. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base de notification environnementale décentralisée (DEN) doivent être établis en fonction des valeurs ci-dessus.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    3.6.Classe de trafic

    (14)Les nouveaux DENM doivent être fixés à la classe de trafic 1.

    3.7.Paramètres du message

    3.7.1.DENM

    (15)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 3: Éléments de données du DENM «Embouteillage — Fin de file dangereuse»

    Zone de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    relevanceDistance

    lessThan1000m(4)

    relevanceTrafficDirection

    upstreamTraffic(1)

    validityDuration

    20 secondes (les véhicules devraient faire face à une situation de circulation différente 20 secondes après la détection)

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (8)

    causeCode

    dangerousEndOfQueue(27)

    subCauseCode

    unavailable(0) (non disponible)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    3.7.2.Message de sensibilisation coopérative (CAM)

    (16)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    3.8.Couche de mise en réseau et de transport

    (17)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    3.9.Couche de sécurité

    (18)Si les conditions de déclenchement sont remplies tel que décrit au point (4), un changement de AT doit être bloqué pour les nouveaux DENM tant que la validityDuration (durée de validité) n’a pas expiré. Les nouveaux DENM correspondants doivent être envoyés au moyen du même AT.

    4.Embouteillage — Embouteillage à l’avant

    4.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant une situation dans laquelle un égo-véhicule détecte un embouteillage. Une telle situation se présente si l'égo-véhicule est entouré par une circulation à l’arrêt ou par une circulation dense. Ce service ne s’applique pas aux environnements urbains.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

       «avertissement en cas de véhicule à l’arrêt — véhicule immobilisé»;

       «avertissement en cas de véhicule à l’arrêt — véhicule en panne»;

       «avertissement en cas de véhicule à l’arrêt — après accident»;

       «avertissement en cas de véhicule spécial — avertissement en cas de véhicule de dépannage à l’arrêt».

    4.2.Conditions de déclenchement

    4.2.1.Conditions préalables

    (19)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C puisse être initialisé:

    (a)aucun service «avertissement en cas de véhicule à l’arrêt» (voir sections 4 à 6) n’est détecté;

    (b)aucun service «avertissement en cas de véhicule spécial» (voir sections 7 à 9) n’est détecté;

    (c)l'égo-véhicule se trouve dans un environnement non urbain. La localisation doit être déterminée d’une des manières suivantes (au minimum):

    (a)la vitesse est supérieure à 80 km/h pendant un intervalle de temps d’au moins 30 secondes au cours des 180 secondes précédant chaque détection et la valeur absolue de l’angle de braquage du volant est inférieure à 90 ° pendant un intervalle de temps d’au moins 30 secondes au cours des 60 secondes précédant chaque détection (les embouteillages ne doivent pas être détectés dans un environnement autoroutier);

    (b)un capteur d’images embarqué indique un environnement non urbain;

    (c)une carte numérique embarquée indique un environnement non urbain.

    (20)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée. Cette exigence s’applique à toutes les occurrences ultérieures d’analyse de vitesse de véhicule.

    (21)La vitesse et les valeurs d’angle doivent être mesurées en continu. Les conditions doivent être remplies pendant toute la durée de la mesure. Le processus doit recommencer si les conditions ne sont pas remplies pendant la totalité de cette durée.

    4.2.2.Conditions spécifiques au service

    (22)Si les conditions préalables mentionnées au point (19) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    ·TRCO_0;

    ·TRCO_1 ET (TRCO_2 OU TRCO_3 OU TRCO_4 OU TRCO_5)

    Tableau 4: Conditions spécifiques au service «Embouteillage — Embouteillage à l’avant»

    Numéro de TRCO

    Condition de déclenchement

    État

    TRCO_0

    L'égo-véhicule roule à une vitesse moyenne inférieure ou égale à 30 km/h et supérieure à 0 km/h (ce seuil est introduit afin d’éviter les chevauchements et d’établir une distinction entre la TRCO_0 et la TRCO_1). La vitesse moyenne doit être calculée sur une période de 120 secondes (la condition de durée exclut du déclenchement les états de circulation à variations fréquentes).

    Remarque: cette TRCO couvre le scénario dans lequel l'égo-véhicule est entouré par une circulation en accordéon.

    dynamique du véhicule

    TRCO_1

    La vitesse de l'égo-véhicule est égale à 0 km/h pendant au moins 30 secondes.

    Remarque: cette TRCO couvre un scénario dans lequel l'égo-véhicule est à l’arrêt et entouré d’autres usagers de la route.

    dynamique du véhicule

    TRCO_2

    Au moins un DENM correspondant au service STI-C «Embouteillage - Embouteillage à l’avant » présentant le même sens de déplacement a été reçu.

    environnement

    TRCO_3

    Au moins une notification d’embouteillage présentant le même sens de déplacement a été reçue au moyen d’une radio mobile.

    environnement

    TRCO_4

    Des CAM indiquent qu’au moins cinq autres véhicules situés dans un rayon de 100 m et présentant le même sens de déplacement affichent une vitesse inférieure ou égale à 30 km/h.

    environnement

    TRCO_5

    Des capteurs embarqués indiquent qu’au moins cinq autres véhicules situés dans un rayon de 100 m et présentant le même sens de déplacement affichent une vitesse inférieure ou égale à 30 km/h.

    capteur embarqué

    (23)Un nouveau DENM ne doit pas être demandé dans le Detection Blocking Time. Le Detection Blocking Time est déclenché après la détection de l’événement et la demande d’un DENM à cet effet. De cette façon, un seul événement ne peut pas surcharger le canal de transmission. Le Detection Blocking Time doit s’élever à 180 secondes, qu’importe la façon dont l’événement est détecté. La période de détection entre deux événements détectés doit être au moins égale au Detection Blocking Time. L’algorithme de détection peut être exécuté pendant le Detection Blocking Time.

    (24)Une condition est valide aussi longtemps qu’elle est active et pendant une période supplémentaire de 5 secondes (la période augmente le déterminisme de l’algorithme de détection). La validité diminue à partir du moment où la condition n’est plus remplie, facilitant ainsi la combinaison de conditions de déclenchement.

    (25)Les CAM et les DENM de véhicules télécommandés utilisés pour évaluer les conditions spécifiques au service tel que décrit précédemment sont pertinents pour l'égo-véhicule. La pertinence doit être déterminée d’une des manières suivantes:

    (a)une carte numérique indique que l’événement et l'égo-véhicule sont séparés par une distance inférieure à 500 m et qu’ils partagent un même sens de déplacement;

    (b)une correspondance de l’historique de cheminement indique que l’événement et l'égo-véhicule sont séparés par une distance inférieure à 500 m et partagent un même sens de déplacement;

    (c)la distance euclidienne entre l’événement et l'égo-véhicule est inférieure à 500 m et la valeur absolue de la différence de cap est inférieure à 10 °. Les positions de référence de l’embouteillage d’après les DENM se situent dans une zone couvrant un champ de -45 à +45 ° à partir de l’axe longitudinal de l'égo-véhicule.

    Remarque: lors du comptage des véhicules ou des événements, le changement de AT doit être envisagé de manière à garantir qu’aucun véhicule ou événement n’est compté plusieurs fois.

    4.2.3.Qualité des informations

    (26)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont la situation est détectée. Les TRCO [voir point (22)] sont répartis en groupes: réaction du conducteur, dynamique du véhicule, environnement et capteurs embarqués. La valeur informationQuality doit être établie conformément au tableau suivant. Il convient d’utiliser la valeur la plus élevée possible.

    Tableau 5: Qualité des informations relatives au service «Embouteillage — Embouteillage à l’avant»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    Au moins une condition du groupe «dynamique du véhicule» est remplie, c’est-à-dire que la condition TRCO_0 est remplie.

    1

    Au moins une condition du groupe «dynamique du véhicule» ET «environnement» est remplie.

    2

    Au moins une condition du groupe «dynamique du véhicule» ET «capteur embarqué» est remplie.

    3

    Au moins une condition du groupe «dynamique du véhicule» ET «environnement» ET «capteur embarqué» est remplie.

    4

    4.3.Conditions de terminaison

    (27)Une terminaison du service STI-C ne doit pas être envisagée.

    4.3.1.Annulation

    (28)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    4.3.2.Négation

    (29)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    4.4.Mise à jour

    (30)Un DENM de mise à jour ne doit pas être utilisé pour ce service STI-C.

    4.5.Durée de répétition et intervalle de répétition

    (31)Les nouveaux DENM doivent être répétés pendant une repetitionDuration de 60 secondes avec un repetitionInterval de 1 seconde. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    4.6.Classe de trafic

    (32)Les nouveaux DENM doivent être fixés à la classe de trafic 1.

    4.7.Paramètres du message

    4.7.1.DENM

    (33)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 6: Éléments de données du DENM «Embouteillage — Embouteillage à l’avant»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    relevanceDistance

    lessThan1000m(4)

    relevanceTrafficDirection

    upstreamTraffic(1)

    validityDuration

    60 secondes (la durée d’une situation d’embouteillage devrait s’élever à au moins 60 secondes)

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (26).

    causeCode

    trafficCondition(1) [conditions de circulation(1)]

    subCauseCode

    unavailable(0)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    4.7.2.CAM

    (34)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    4.8.Couche de mise en réseau et de transport

    (35)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    4.9.Couche de sécurité

    (36)Si les conditions de déclenchement sont remplies tel que décrit au point (22), un changement de AT doit être bloqué pour les nouveaux DENM tant que la validityDuration (durée de validité) n’a pas expiré. Les nouveaux DENM correspondants doivent être envoyés au moyen du même AT.

    5.Avertissement en cas de véhicule à l’arrêt - véhicule immobilisé

    5.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant une situation dans laquelle un véhicule est immobilisé, sans que des informations spécifiques ne soient disponibles concernant le motif de cette immobilisation.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«avertissement en cas de véhicule spécial — avertissement en cas de véhicule de dépannage à l’arrêt»;

    ·«avertissement en cas de véhicule à l’arrêt — véhicule en panne»;

    ·«avertissement en cas de véhicule à l’arrêt — après accident».

    (37)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme remplies. Un tel signal incite la pile à générer un nouveau DENM, un DENM de mise à jour ou un DENM d’annulation. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    5.2.Conditions de déclenchement

    5.2.1.Conditions préalables

    (38)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C soit déclenché:

    (a)aucun message d’avertissement en cas de panne empêchant le conducteur de poursuivre sa route (symboles d’avertissement rouges, par exemple, conformément au règlement [ECE 121]) n’apparaît sur le tableau de bord.

    Remarque: ce service n’est pas tenu de vérifier l’état du terminal d’allumage 15 pour donner lieu à un déclenchement (peut être allumé ou éteint). Le fonctionnement du service est facultatif lorsque le terminal d’allumage 15 est éteint.

    (39)Il convient d’éviter l’activation parallèle avec les autres services STI-C liés. Lorsque les services STI-C «véhicule en panne» et/ou «après accident» sont déclenchés simultanément, les services STI-C doivent être hiérarchisés comme suit:

    (a)«après accident» (priorité la plus élevée);

    (b)«véhicule en panne»;

    (c)«véhicule immobilisé» (priorité la moins élevée).

    5.2.2.Conditions spécifiques au service

    (40)Si les conditions préalables mentionnées au point (38) et toutes les conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (a)l'égo-véhicule a allumé ses feux de détresse;

    (b)le véhicule est immobile;

    (c)le temporisateur de déclenchement a expiré.

    (41)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée. Cette exigence s’applique à toutes les occurrences ultérieures d’analyse de vitesse de véhicule.

    (42)Si le véhicule a allumé ses feux de détresse et est à l’arrêt, le temporisateur de déclenchement doit être mis à 30 secondes et être lancé. Le temporisateur de déclenchement doit être réduit si les situations suivantes se présentent:

    (a)le temporisateur doit être réduit de 10 secondes si la transmission automatique (AUT) est fixée à «stationnement» pendant au moins 3 secondes;

    (b)le temporisateur doit être réduit de 10 secondes si la boîte de vitesse est fixée à «libre» pendant au moins 3 secondes;

    (c)le temporisateur doit être réduit de 10 secondes si le frein de stationnement est activé pendant au moins 3 secondes;

    (d)le temporisateur doit être réduit de 10 secondes si un nombre arbitraire de boucles de ceintures de sécurité passent de «connectées» à «déconnectées» pendant au moins 3 secondes;

    (e)le temporisateur doit être mis à 0 si un nombre arbitraire de portières sont ouvertes pendant au moins 3 secondes;

    (f)le temporisateur doit être mis à 0 si le terminal d’allumage passe de l’état allumé à éteint pendant au moins 3 secondes;

    (g)le temporisateur doit être mis à 0 si le coffre est ouvert pendant au moins 3 secondes;

    (h)le temporisateur doit être mis à 0 si le capot est ouvert pendant au moins 3 secondes.

    (43)Toutes les procédures susmentionnées concernant la réduction du temporisateur doivent être appliquées à une seule reprise pendant la détection initiale. Si le temporisateur de déclenchement a été réduit à 0, aucune réduction supplémentaire n’est nécessaire au cours du cycle de détection actuel.

    (44)Pendant l’exécution du temporisateur de déclenchement, les feux de détresse doivent être allumés et le véhicule doit être à l’arrêt. Sinon, la détection est annulée.

    5.2.3.Qualité des informations

    (45)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (42)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 7: Qualité des informations relatives au service «véhicule à l’arrêt — véhicule immobilisé»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    Aucune des conditions a) à h) n’est remplie.

    1

    Au moins une des conditions a) à d) est remplie.

    2

    Au moins une des conditions e) à h) est remplie.

    3

    (46)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour. Pendant la phase de mise à jour, seules les conditions qui entraîneraient une réduction du temporisateur doivent être évaluées, et non le temporisateur lui-même.

    5.3.Conditions de terminaison

    (47)Ce service STI-C se termine par une annulation de la station STI-C d’origine. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    5.3.1.Annulation

    (48)Si au moins une des conditions suivantes est remplie avant que la période établie de l’élément de données validityDuration ait expiré, la génération d’un DENM d’annulation doit être déclenchée:

    (a)le véhicule n’est plus à l’arrêt depuis 5 secondes;

    (b)les feux de détresse sont éteints;

    (c)la position du véhicule a changé de plus de 500 m (par exemple, parce que le véhicule a été remorqué).

    Remarque: la condition d’annulation n’implique pas que la station STI-C est tenue d’être opérationnelle en permanence ou d’étendre son fonctionnement pendant cette condition d’annulation.

    5.3.2.Négation

    (49)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    5.4.Mise à jour

    (50)Si le DENM précédemment déclenché pour un véhicule immobilisé détecté n’a pas été annulé, la génération d’un DENM de mise à jour doit être déclenchée toutes les 15 secondes.

    (51)Pendant la phase de mise à jour, seules les conditions de déclenchement doivent faire l’objet d’une vérification (une évaluation supplémentaire des temporisateurs ne doit pas être exécutée).

    (52)De nouvelles valeurs doivent être attribuées aux éléments ou champs de données dans le DENM en fonction de l’événement modifié (detectionTime ou informationQuality, par exemple).

    Remarque: la condition de mise à jour n’implique pas que la station STI-C est tenue d’être opérationnelle en permanence ou d’étendre son fonctionnement pendant cette condition de mise à jour.

    5.5.Durée de répétition et intervalle de répétition

    (53)Les DENM qui sont nouveaux, ont été mis à jour ou ont été annulés doivent être répétés pendant une repetitionDuration de 15 secondes avec un repetitionInterval de 1 seconde. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: la validityDuration est fixée à 30 secondes. Par conséquent, il est possible d'empêcher un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    5.6.Classe de trafic

    (54)Les DENM nouveaux, de mise à jour et d’annulation doivent être fixés à la classe de trafic 1.

    5.7.Paramètres du message

    5.7.1.DENM

    (55)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 8: Éléments de données du DENM «avertissement en cas de véhicule à l’arrêt — véhicule immobilisé»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM, d'un DENM de mise à jour ou d'un DENM d’annulation. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi en cas de DENM nouveau ou de mise à jour. Doit être fixé à isCancellation(0) en cas de DENM d’annulation.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    relevanceDistance

    lessThan1000m(4)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens

     

    0

    allTrafficDirections(0)

     

    1

    upstreamTraffic(1)

     

    2

    allTrafficDirections(0)

     

    3

    upstreamTraffic(1)

     

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    30 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (45). Doit être rafraîchi pour chaque DENM de mise à jour.

    causeCode

    stationaryVehicle(94)

    subCauseCode

    unavailable(0)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    Conteneur à la carte: StationaryVehicleContainer

    stationarySince

    Doit être établi en fonction de la durée en minutes de l’immobilité de la station STI-C de détection. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    5.7.2.CAM

    (56)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    5.8.Couche de mise en réseau et de transport

    (57)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    5.9.Couche de sécurité

    (58)Si les conditions de déclenchement décrites au point (40) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux, de mise à jour et d’annulation tant que la validityDuration n’a pas expiré. Les DENM nouveaux, de mise à jour et d’annulation correspondants doivent être envoyés au moyen du même AT.

    6.Avertissement en cas de véhicule à l’arrêt — véhicule en panne

    6.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant un véhicule en panne. Bien que diverses raisons puissent donner lieu à une panne de véhicule, comme l’éclatement de pneus, le manque de carburant ou une panne de moteur, cette section se concentre sur les raisons indiquées par les messages d’avertissement en cas de panne qui s’affichent sur le tableau de bord.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«avertissement en cas de véhicule spécial — avertissement en cas de véhicule de dépannage à l’arrêt»;

    ·«avertissement en cas de véhicule à l’arrêt — véhicule immobilisé»;

    ·«avertissement en cas de véhicule à l’arrêt — après accident».

    (59)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme valides. Un tel signal incite la pile à générer un DENM nouveau, de mise à jour ou d’annulation. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    6.2.Conditions de déclenchement

    6.2.1.Conditions préalables

    (60)La condition préalable suivante doit être remplie pour que ce service STI-C soit déclenché:

    (a)un message d’avertissement en cas de panne empêchant le conducteur de poursuivre sa route (symboles d’avertissement rouges, par exemple, conformément au règlement [ECE 121]) apparaît sur le tableau de bord.

    Remarque: ce service n’est pas tenu de vérifier l’état du terminal d’allumage 15 pour donner lieu à un déclenchement (peut être allumé ou éteint). Le fonctionnement du service est facultatif lorsque le terminal d’allumage 15 est éteint.

    (61)Il convient d’éviter l’activation parallèle avec les autres services STI-C liés. Lorsque les services STI-C «véhicule immobilisé» et/ou «après accident» sont déclenchés simultanément, les services STI-C doivent être hiérarchisés comme suit:

    (a)«après accident» (priorité la plus élevée);

    (b)«véhicule en panne»;

    (c)«véhicule immobilisé» (priorité la moins élevée).

    6.2.2.Conditions spécifiques au service

    (62)Si la condition préalable mentionnée au point (60) et toutes les conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (a)l'égo-véhicule a allumé ses feux de détresse;

    (b)le véhicule est immobile;

    (c)le temporisateur de déclenchement a expiré.

    (63)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée. Cette exigence s’applique à toutes les occurrences ultérieures d’analyse de vitesse de véhicule.

    (64)Si le véhicule a allumé ses feux de détresse et est à l’arrêt, le temporisateur de déclenchement doit être mis à 30 secondes et être lancé. Le temporisateur de déclenchement doit être réduit si les situations suivantes se présentent:

    (a)le temporisateur doit être réduit de 10 secondes si la transmission automatique (AUT) est fixée à «stationnement» pendant au moins 3 secondes;

    (b)le temporisateur doit être réduit de 10 secondes si la boîte de vitesse est fixée à «libre» pendant au moins 3 secondes;

    (c)le temporisateur doit être réduit de 10 secondes si le frein de stationnement est activé pendant au moins 3 secondes;

    (d)le temporisateur doit être réduit de 10 secondes si un nombre arbitraire de boucles de ceintures de sécurité passent de «connectées» à «déconnectées» pendant au moins 3 secondes;

    (e)le temporisateur doit être mis à 0 si un nombre arbitraire de portières sont ouvertes pendant au moins 3 secondes;

    (f)le temporisateur doit être mis à 0 si le terminal d’allumage passe de l’état allumé à éteint pendant au moins 3 secondes;

    (g)le temporisateur doit être mis à 0 si le coffre est ouvert pendant au moins 3 secondes;

    (h)le temporisateur doit être mis à 0 si le capot est ouvert pendant au moins 3 secondes.

    (65)Toutes les procédures susmentionnées concernant la réduction du temporisateur doivent être appliquées à une seule reprise pendant la détection initiale. Si le temporisateur de déclenchement a été réduit à 0, aucune réduction supplémentaire n’est nécessaire au cours du cycle de détection actuel.

    (66)Pendant l’exécution du temporisateur de déclenchement, les feux de détresse doivent être allumés et le véhicule doit être à l’arrêt sans interruption. Sinon, la détection est annulée.

    6.2.3.Qualité des informations

    (67)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (64)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 9: Qualité des informations relatives au service «véhicule à l’arrêt — véhicule en panne»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    Aucune des conditions a) à h) n’est remplie.

    1

    Au moins une des conditions a) à d) est remplie.

    2

    Au moins une des conditions e) à h) est remplie.

    3

    (68)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour. Pendant la phase de mise à jour, seules les conditions qui entraîneraient une réduction du temporisateur doivent être évaluées, et non le temporisateur lui-même.

    6.3.Conditions de terminaison

    (69)Ce service STI-C se termine par une annulation de la station STI-C d’origine. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    6.3.1.Annulation

    (70)Si au moins une des conditions suivantes est remplie avant que la période établie de l’élément de données validityDuration ait expiré, la génération d’un DENM d’annulation doit être déclenchée:

    (a)le véhicule n’est plus à l’arrêt depuis 5 secondes;

    (b)les feux de détresse sont éteints;

    (c)la position du véhicule a changé de plus de 500 m (par exemple, parce que le véhicule a été remorqué).

    Remarque: la condition d’annulation n’implique pas que la station STI-C est tenue d’être opérationnelle en permanence ou d’étendre son fonctionnement pendant cette condition d’annulation.

    6.3.2.Négation

    (71)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    6.4.Mise à jour

    (72)Si le DENM précédemment déclenché pour un véhicule en panne détecté n’a pas été annulé, la génération d’un DENM de mise à jour doit être déclenchée toutes les 15 secondes.

    (73)Pendant la phase de mise à jour, seules les conditions de déclenchement doivent faire l’objet d’une vérification (les temporisateurs ne doivent pas être soumis à des évaluations supplémentaires).

    (74)Si le terminal d’allumage 15 passe de l’état allumé à éteint, un DENM de mise à jour doit être immédiatement déclenché.

    (75)De nouvelles valeurs doivent être attribuées aux éléments ou champs de données dans le DENM en fonction de l’événement modifié (detectionTime ou informationQuality, par exemple).

    Remarque: la condition de mise à jour n’implique pas que la station STI-C est tenue d’être opérationnelle en permanence ou d’étendre son fonctionnement pendant cette condition de mise à jour.

    6.5.Durée de répétition et intervalle de répétition

    (76)Les DENM qui sont nouveaux, ont été mis à jour ou ont été annulés doivent être répétés pendant une repetitionDuration de 15 secondes avec un repetitionInterval de 1 seconde. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    (77)Dans le cas d’un terminal d’allumage 15 allumé, la validityDuration doit être mise à 30 secondes. Par conséquent, il est possible d’éviter un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: la validityDuration est fixée à une valeur supérieure dans le cas d’un terminal d’allumage 15 éteint (par rapport au cas de figure où le terminal d’allumage 15 est allumé). Cela est dû au fait qu’un DENM de mise à jour ne peut être déclenché et ne peut plus être envoyé. Par conséquent, le dernier DENM doit être maintenu actif plus longtemps.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    6.6.Classe de trafic

    (78)Les DENM nouveaux, de mise à jour et d’annulation doivent être fixés à la classe de trafic 1.

    6.7.Paramètres du message

    6.7.1.DENM

    (79)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 10: Éléments de données du DENM «avertissement en cas de véhicule à l’arrêt — véhicule en panne»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM, d'un DENM de mise à jour ou d'un DENM d’annulation. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi en cas de DENM nouveau ou de mise à jour. Doit être fixé à isCancellation(0) en cas de DENM d’annulation.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    relevanceDistance

    lessThan1000m(4)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens

     

    0

    allTrafficDirections(0)

     

    1

    upstreamTraffic(1)

     

    2

    allTrafficDirections(0)

     

    3

    upstreamTraffic(1)

     

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    ·Terminal d’allumage 15 allumé: 30 secondes

    ·Terminal d’allumage 15 éteint: 900 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (67). Doit être rafraîchi pour chaque DENM de mise à jour.

    causeCode

    stationaryVehicle(94)

    subCauseCode

    vehicleBreakdown(2)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    Conteneur à la carte: StationaryVehicleContainer

    stationarySince

    Doit être établi en fonction de la durée en minutes de l’immobilité de la station STI-C de détection. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    6.7.2.CAM

    (80)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    6.8.Couche de mise en réseau et de transport

    (81)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    6.9.Couche de sécurité

    (82)Si les conditions de déclenchement décrites au point (62) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux, de mise à jour et d’annulation tant que la validityDuration n’a pas expiré. Les DENM nouveaux, de mise à jour et d’annulation correspondants doivent être envoyés au moyen du même AT.

    7.Avertissement en cas de véhicule à l’arrêt — après accident

    7.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant un véhicule à l’arrêt des suites d’un accident de la route.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

       «avertissement en cas de véhicule à l’arrêt — véhicule immobilisé»;

       «avertissement en cas de véhicule à l’arrêt — véhicule en panne».

    (83)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme valides. Un tel signal incite la pile à générer un DENM nouveau, de mise à jour ou d’annulation. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    7.2.Conditions de déclenchement

    7.2.1.Conditions préalables

    (84)Aucune condition préalable spécifique ne s’applique dans le cadre de ce service STI-C.

    (85)Il convient d’éviter l’activation parallèle avec les autres services STI-C liés. Lorsque les services STI-C «véhicule immobilisé» et/ou «véhicule en panne» sont déclenchés simultanément, les services STI-C doivent être hiérarchisés comme suit:

    (a)«après accident» (priorité la plus élevée);

    (b)«véhicule en panne»;

    (c)«véhicule immobilisé» (priorité la moins élevée).

    7.2.2.Conditions spécifiques au service

    (86)Si les conditions préalables mentionnées au point (84) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (a)un service d’appel d’urgence (eCall) a été déclenché manuellement par un occupant du véhicule à l’aide du bouton eCall et le véhicule est mis à l’arrêt dans les 15 secondes. Si le véhicule est déjà à l’arrêt, la condition est immédiatement remplie;

    (b)un accident de faible gravité est détecté sans l’activation d’un système de retenue irréversible de l’occupant (coupure de la batterie haute tension, déverrouillage de portières, par exemple) et le véhicule est mis à l’arrêt dans les 15 secondes. Si le véhicule est déjà à l’arrêt, la condition est remplie immédiatement;

    (c)une collision impliquant des piétons est détectée avec l’activation d’au moins un système irréversible de protection des piétons (par exemple, ouverture du capot, airbag extérieur) et le véhicule est mis à l’arrêt dans les 15 secondes. Si le véhicule est déjà à l’arrêt, la condition est remplie immédiatement;

    (d)un accident de haute gravité est détecté avec l’activation d’au moins un système de retenue irréversible de l’occupant (tendeur de ceinture pyrotechnique, airbag, par exemple).

    (87)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée. Cette exigence s’applique à toutes les occurrences ultérieures d’analyse de vitesse de véhicule.

    Remarque: les conditions ne doivent faire l’objet d’une vérification que si l’alimentation nécessaire est présente. Cela signifie qu’une mise en œuvre du système à l’épreuve des collisions n’est pas requise.

    7.2.3.Qualité des informations

    (88)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (86)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 11: Qualité des informations relatives au service «véhicule à l’arrêt — après accident»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    La condition a) est remplie.

    1

    La condition b) ou la condition c) est remplie.

    2

    La condition d) est remplie.

    3

    (89)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    7.3.Conditions de terminaison

    (90)Ce service STI-C se termine par une annulation de la station STI-C d’origine. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    7.3.1.Annulation

    (91)Une fois qu’au moins une des conditions suivantes est remplie avant que la période établie de l’élément de données validityDuration ait expiré, la génération d’un DENM d’annulation doit être déclenchée:

    (a)l'égo-véhicule n’est pas à l’arrêt pendant une durée de 15 secondes;

    (b)la position du véhicule a changé de plus de 500 m (par exemple, parce que le véhicule a été remorqué).

    Remarque: la condition d’annulation n’implique pas que la station STI-C est tenue d’être opérationnelle en permanence ou d’étendre son fonctionnement pendant cette condition d’annulation.

    7.3.2.Négation

    (92)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    7.4.Mise à jour

    (93)Un DENM de mise à jour doit être déclenché toutes les 60 secondes si le service STI-C n’a pas été annulé.

    (94)Si le terminal d’allumage 15 passe de l’état allumé à éteint, un DENM de mise à jour doit être immédiatement déclenché.

    (95)De nouvelles valeurs doivent être attribuées aux éléments ou champs de données dans le DENM en fonction de l’événement modifié (detectionTime ou informationQuality, par exemple).

    Remarque: la condition de mise à jour n’implique pas que la station STI-C est tenue d’être opérationnelle en permanence ou d’étendre son fonctionnement pendant cette condition de mise à jour.

    7.5.Durée de répétition et intervalle de répétition

    (96)Les DENM qui sont nouveaux, ont été mis à jour ou ont été annulés doivent être répétés pendant une repetitionDuration de 60 secondes avec un repetitionInterval de 1 seconde. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    (97)Dans le cas d’un terminal d’allumage 15 allumé, la validityDuration doit être mise à 180 secondes. Par conséquent, il est possible d’éviter un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: la validityDuration est fixée à une valeur supérieure dans le cas d’un terminal d’allumage 15 éteint (par rapport au cas de figure où le terminal d’allumage 15 est allumé). Cela est dû au fait qu’un DENM de mise à jour ne peut être déclenché et ne peut plus être envoyé. Par conséquent, le dernier DENM doit être maintenu actif plus longtemps.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    7.6.Classe de trafic

    (98)Les DENM nouveaux, de mise à jour et d’annulation doivent être fixés à la classe de trafic 1.

    7.7.Paramètres du message

    7.7.1.DENM

    (99)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 12: Éléments de données du DENM «avertissement en cas de véhicule à l’arrêt — après accident»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM, d'un DENM de mise à jour ou d'un DENM d’annulation. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi en cas de DENM nouveau ou de mise à jour. Doit être fixé à isCancellation(0) en cas de DENM d’annulation.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    relevanceDistance

    lessThan5km(5)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens

     

    0

    allTrafficDirections(0)

     

    1

    upstreamTraffic(1)

     

    2

    allTrafficDirections(0)

     

    3

    upstreamTraffic(1)

     

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    ·Terminal d’allumage 15 allumé: 180 secondes

    ·Terminal d’allumage 15 éteint: 1 800 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (88). Doit être rafraîchi pour chaque DENM de mise à jour.

    causeCode

    stationaryVehicle(94)

    subCauseCode

    postCrash(3)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    Conteneur à la carte: StationaryVehicleContainer

    stationarySince

    Doit être établi en fonction de la durée en minutes de l’immobilité de la station STI-C de détection. Doit être établi conformément à la norme [TS 102 894-2].

     

    Doit être rafraîchi pour un DENM de mise à jour.

    7.7.2.CAM

    (100)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    7.8.Couche de mise en réseau et de transport

    (101)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    7.9.Couche de sécurité

    (102)Si les conditions de déclenchement décrites au point (86) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux, de mise à jour et d’annulation tant que la validityDuration n’a pas expiré. Les DENM nouveaux, de mise à jour et d’annulation correspondants doivent être envoyés au moyen du même AT.

    8.Avertissement en cas de véhicule spécial — véhicule d'urgence en intervention

    8.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant un véhicule d'urgence se rendant sur son lieu d’opération, ce qui est signalé par l’utilisation de la rampe lumineuse.

    (103)Dès que le service STI-C est déclenché, un DENM doit être transmis par la station STI-C embarquée dans le véhicule d'urgence et des parties des champs de données CAM doivent être établies conformément aux dispositions de la section 8.7.2.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«avertissement en cas de véhicule spécial — véhicule d'urgence de sécurisation à l’arrêt»;

    ·«avertissement en cas de véhicule spécial — avertissement en cas de véhicule de dépannage à l’arrêt».

    (104)Le service STI-C par défaut pour une station STI-C embarquée dans un véhicule d'urgence est: «véhicule d'urgence en intervention». Un passage au service STI-C «véhicule d'urgence de sécurisation à l’arrêt» doit être déclenché uniquement si les conditions établies à la section 9 sont remplies.

    8.2.Conditions de déclenchement

    8.2.1.Conditions préalables

    (105)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C soit déclenché:

    (a)le stationType est confirmé comme étant un véhicule spécial [le stationType du CAM est fixé à specialVehicles(10)]. Le service STI-C est réservé aux véhicules d'urgence;

    (b)les conditions de déclenchement concernant le service «véhicule d'urgence de sécurisation à l’arrêt» ne doivent pas être remplies (voir section 9.2).

    8.2.2.Conditions spécifiques au service

    (106)Si les conditions préalables mentionnées au point (105) et la condition suivante sont remplies, la génération d’un DENM doit être déclenchée:

    (a)la rampe lumineuse est utilisée.

    (107)Le niveau de la qualité des informations peut être renforcé par les conditions suivantes:

    (b)la sirène est utilisée;

    (c)le véhicule n’est pas à l’arrêt.

    (108)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée.

    8.2.3.Qualité des informations

    (109)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir points (106) et (107)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 13: Qualité des informations relatives au service «véhicule d'urgence en intervention»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    La condition a) est remplie

    1

    Les conditions a) et b) sont remplies

    2

    Les conditions a) et c) sont remplies

    3

    Les conditions a), b) et c) sont remplies

    4

    (110)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    8.3.Conditions de terminaison

    (111)Le service STI-C doit être terminé lorsque la rampe lumineuse n’est plus utilisée. Lors de la terminaison du service STI-C, la mise à jour des DENM doit se terminer. Le vehicleRole doit être fixé à default(0) si la rampe lumineuse n’est plus utilisée.

    8.3.1.Annulation

    (112)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    8.3.2.Négation

    (113)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    8.4.Mise à jour

    (114)Le DENM généré doit être mis à jour toutes les 250 millisecondes si les conditions de déclenchement sont toujours remplies. Les champs de données auxquels de nouvelles valeurs sont attribuées sont définis dans le tableau 14 ci-après.

    8.5.Durée de répétition et intervalle de répétition

    (115)Une répétition du DENM ne doit pas être utilisée pour ce service STI-C.

    8.6.Classe de trafic

    (116)Les DENM nouveaux, de mise à jour et d’annulation doivent être fixés à la classe de trafic 1.

    8.7.Paramètres du message

    8.7.1.DENM

    (117)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 14: Éléments de données du DENM «véhicule d'urgence en intervention»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM ou d'un DENM de mise à jour. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STIC.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    relevanceDistance

    lessThan1000m(4)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens

     

    0

    allTrafficDirections(0)

     

    1

    upstreamTraffic(1)

     

    2

    allTrafficDirections(0)

     

    3

    upstreamTraffic(1)

     

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    2 secondes

    stationType

    specialVehicles(10)

    Conteneur de situation

    informationQuality

    Voir point (109). Doit être rafraîchi pour chaque DENM de mise à jour.

    causeCode

    emergencyVehicleApproaching(95)

    subCauseCode

    emergencyVehicleApproaching(1)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    Conteneur à la carte: StationaryVehicleContainer

    stationarySince

    Doit être établi en fonction de la durée en minutes de l’immobilité de la station STI-C de détection. Doit être établi conformément à la norme [TS 102 894-2].

     

    Doit être rafraîchi pour un DENM de mise à jour.

    8.7.2.CAM

    (118)Le vehicleRole doit être initialisé à son réglage par «défaut» [le vehicleRole du CAM est fixé à default(0)]. Si au moins une des conditions de déclenchement mentionnées au point (106) est remplie, le vehicleRole doit être fixé à emergency(6).

    (119)Le tableau suivant précise les éléments de données du CAM devant être établis si le service STI-C est déclenché.

    Tableau 15: Éléments de données du CAM «véhicule d'urgence en intervention»

    Champ de données

    Valeur

    CoopAwareness

    generationDeltaTime

    Moment correspondant au moment de la position de référence dans le CAM, considéré comme le moment de génération du CAM.

    Doit être établi conformément à la norme [EN 302 637-2].

    BasicContainer

    stationType

    specialVehicles(10)

    referencePosition

    Position et précision de position mesurées au point de référence de la station STIC d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le HighFrequencyContainer doit être fixé à BasicVehicleContainerHighFrequency

    heading

    La direction du cap de la station STI-C d’origine par rapport au nord véritable.

    Doit être établi conformément à la norme [TS 102 894-2].

    speed

    La vitesse de conduite de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    driveDirection

    Sens de déplacement du véhicule (marche avant ou marche arrière) de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    vehicleLength

    Longueur du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    vehicleWidth

    Largeur du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    longitudinalAcceleration

    Accélération longitudinale du véhicule de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    curvature

    Courbure de la précision et de la trajectoire du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    curvatureCalcMode

    Indique si le taux de lacet est utilisé pour calculer la courbure pour une valeur de courbure rapportée.

    Doit être établi conformément à la norme [TS 102 894-2].

    yawRate

    Le taux de lacet du véhicule à un moment donné.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le LowFrequencyContainer doit être fixé à BasicVehicleContainerLowFrequency

    vehicleRole

    emergency(6)

    exteriorLights

    Indique l’état des interrupteurs d'éclairage extérieur d’un véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    pathHistory

    Représente le mouvement d’un véhicule sur une distance et/ou une période récente.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le SpecialVehicleContainer doit être fixé à EmergencyContainer

    lightBarSirenInUse

    Le bit lightBarActivated doit être mis à 1 (onChange) si l’utilisation de la rampe lumineuse est détectée; sinon, il doit être fixé à 0.

    Le bit sirenActivated doit être mis à 1 si l’utilisation de la sirène est détectée; sinon, il doit être mis à 0.

    emergencyPriority

    Non requis

    causeCode

    Comme spécifié au point (117).

    subCauseCode

    Comme spécifié au point (117).

    8.8.Couche de mise en réseau et de transport

    (120)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    8.9.Couche de sécurité

    (121)Si les conditions de déclenchement décrites au point (106) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux et de mise à jour tant que la validityDuration n’a pas expiré. Les DENM nouveaux et de mise à jour correspondants doivent être envoyés au moyen du même AT.

    9.Avertissement en cas de véhicule spécial — véhicule d'urgence de sécurisation à l’arrêt

    9.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant un véhicule d'urgence à l'arrêt sécurisant une zone dangereuse.

    (122)Dès que le service STI-C est déclenché, un DENM doit être transmis par la station STI-C embarquée dans le véhicule d'urgence et des parties des champs de données CAM doivent être établies conformément aux dispositions de la section 9.7.2.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«avertissement en cas de véhicule spécial — véhicule d'urgence en intervention»;

    ·«avertissement en cas de véhicule spécial — avertissement en cas de véhicule de dépannage à l’arrêt».

    9.2.Conditions de déclenchement

    9.2.1.Conditions préalables

    (123)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C soit déclenché:

    ·le stationType est confirmé comme étant un véhicule d'urgence [le stationType du CAM est fixé à specialVehicles(10)]. Le service STI-C est réservé aux véhicules d'urgence;

    ·le temporisateur d’arrêt doit être remis à zéro.

    (124)Le service STI-C par défaut pour une station STI-C embarquée dans un véhicule d'urgence est: «véhicule d'urgence en intervention». Un passage au service STI-C «véhicule d'urgence de sécurisation à l’arrêt» doit être déclenché uniquement si les conditions définies à la section 9.2.2 sont remplies.

    9.2.2.Conditions spécifiques au service

    (125)Si le véhicule est à l’arrêt et si la rampe lumineuse est utilisée, un temporisateur d’arrêt doit être remis à zéro et démarré. Si la rampe lumineuse n’est plus utilisée ou si le véhicule n’est plus à l’arrêt, le temporisateur d’arrêt doit être arrêté et remis à zéro.

    (126)Si les conditions préalables mentionnées au point (123) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (a)la rampe lumineuse est utilisée et le relais moteur est activé;

    (b)la rampe lumineuse est utilisée, les feux de détresse sont allumés et le frein de stationnement est utilisé ou (dans le cas d’une transmission automatique) la fonction «stationnement» est sélectionnée;

    (c)la rampe lumineuse est utilisée, les feux de détresse sont allumés et le temporisateur d’arrêt est fixé à 60 secondes ou plus.

    (127)Le niveau de la qualité des informations peut être renforcé par les conditions suivantes:

    (d)l’état d’au moins une portière, ou du coffre, est «ouvert»;

    (e)le siège du conducteur est détecté, au moyen d’une des techniques suivantes, comme «non occupé»:

    (1)caméra de l’habitacle;

    (2)technique de pointe de détection de l’occupation des sièges utilisée pour le rappel du port de la ceinture de sécurité.

    (128)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée. Cette exigence s’applique à toutes les occurrences ultérieures d’analyse de vitesse de véhicule.

    (129)Si le service STI-C est déclenché en raison du fait que la condition a) ou la condition b) du point (126) est remplie, le temporisateur d’arrêt doit être arrêté et fixé à 60 secondes. Pendant la phase de mise à jour, seules les conditions doivent faire l’objet d’une vérification et aucun temporisateur ne doit être démarré.

    9.2.3.Qualité des informations

    (130)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir points (126) et (127)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 16: Qualité des informations relatives au service «véhicule d'urgence de sécurisation à l’arrêt»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    La condition c) est remplie

    1

    La condition b) est remplie

    2

    Au moins une des conditions b) ou c) est remplie et la condition d) est remplie

    3

    Au moins une des conditions b) ou c) est remplie et la condition e) est remplie

    4

    La condition a) est remplie

    5

    (131)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    9.3.Conditions de terminaison

    (132)Ce service STI-C se termine par une annulation de la station STI-C d’origine. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    9.3.1.Annulation

    (133)Si la condition suivante est remplie avant que la période établie de l’élément de données validityDuration ait expiré, la génération d’un DENM d’annulation doit être déclenchée:

    (a)l’ensemble des conditions spécifiques au service STI-C a) à c) mentionnées à la section 9.2.2 ne sont plus remplies.

    Le vehicleRole doit être fixé à default(0) si la rampe lumineuse n’est plus utilisée.

    9.3.2.Négation

    (134)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.    

    9.4.Mise à jour

    (135)Le DENM généré doit être mis à jour toutes les 60 secondes si les conditions de déclenchement sont toujours remplies. Tous les champs de données auxquels de nouvelles valeurs sont attribuées sont définis dans le tableau 17 ci-après.

    9.5.Durée de répétition et intervalle de répétition

    (136)Les DENM qui sont nouveaux, ont été mis à jour ou ont été annulés doivent être répétés pendant une repetitionDuration de 60 secondes avec un repetitionInterval de 1 seconde. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: la validityDuration est fixée à 180 secondes. Par conséquent, il est possible d'empêcher un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    9.6.Classe de trafic

    (137)Les DENM nouveaux, de mise à jour et d’annulation doivent être fixés à la classe de trafic 1.

    9.7.Paramètres du message

    9.7.1.DENM

    (138)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 17: Éléments de données du DENM «véhicule d'urgence de sécurisation à l’arrêt»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM, d'un DENM de mise à jour ou d'un DENM d’annulation. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi en cas de DENM nouveau ou de mise à jour. Doit être fixé à isCancellation(0) si les conditions d’annulations sont remplies; voir point (133).

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    relevanceDistance

    lessThan5km (5)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens

     

    0

    allTrafficDirections(0)

     

    1

    upstreamTraffic(1)

     

    2

    allTrafficDirections(0)

     

    3

    upstreamTraffic(1)

     

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    180 secondes

    stationType

    specialVehicles(10)

    Conteneur de situation

    informationQuality

    Voir point (130). Doit être rafraîchi pour chaque DENM de mise à jour.

    causeCode

    rescueAndRecoveryWorkInProgress(15)

    subCauseCode

    emergencyVehicles(1)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    Conteneur à la carte: StationaryVehicleContainer

    stationarySince

    Doit être établi en fonction de la durée en minutes de l’immobilité de la station STI-C de détection. Doit être établi conformément à la norme [TS 102 894-2].

     

    Doit être rafraîchi pour un DENM de mise à jour.

    9.7.2.CAM

    (139)Le vehicleRole doit être initialisé à son réglage par «défaut» [le vehicleRole du CAM est fixé à default(0)]. Si au moins une des conditions de déclenchement définies au point (126) est remplie, le vehicleRole doit être fixé à emergency(6).

    (140)Le tableau suivant précise les éléments de données du CAM devant être établis si le service STI-C est déclenché.

    Tableau 18: Éléments de données du CAM «véhicule d'urgence de sécurisation à l’arrêt»

    Champ de données

    Valeur

    CoopAwareness

    generationDeltaTime

    Moment correspondant au moment de la position de référence dans le CAM, considéré comme le moment de génération du CAM.

    Doit être établi conformément à la norme [EN 302 637-2].

    BasicContainer

    stationType

    specialVehicles(10)

    referencePosition

    Position et précision de position mesurées au point de référence de la station STIC d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le HighFrequencyContainer doit être fixé à BasicVehicleContainerHighFrequency

    heading

    La direction du cap de la station STI-C d’origine par rapport au nord véritable.

    Doit être établi conformément à la norme [TS 102 894-2].

    speed

    La vitesse de conduite de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    driveDirection

    Sens de déplacement du véhicule (marche avant ou marche arrière) de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    vehicleLength

    Longueur du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    vehicleWidth

    Largeur du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    longitudinalAcceleration

    Accélération longitudinale du véhicule de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    curvature

    Courbure de la précision et de la trajectoire du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    curvatureCalcMode

    Indique si le taux de lacet est utilisé pour calculer la courbure pour une valeur de courbure rapportée.

    Doit être établi conformément à la norme [TS 102 894-2].

    yawRate

    Le taux de lacet du véhicule à un moment donné.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le LowFrequencyContainer doit être fixé à BasicVehicleContainerLowFrequency

    vehicleRole

    emergency(6)

    exteriorLights

    Indique l’état des interrupteurs d'éclairage extérieur d’un véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    pathHistory

    Représente le mouvement d’un véhicule sur une distance et/ou une période récente.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le SpecialVehicleContainer doit être fixé à EmergencyContainer

    lightBarSirenInUse

    Le bit lightBarActivated doit être mis à 1 (onChange) si l’utilisation de la rampe lumineuse est détectée; sinon, il doit être mis à 0.

    Le bit sirenActivated doit être mis à 1 si l’utilisation de la sirène est détectée; sinon, il doit être mis à 0.

    emergencyPriority

    Non requis

    causeCode

    Comme spécifié au point (138).

    subCauseCode

    Comme spécifié au point (138).

    9.8.Couche de mise en réseau et de transport

    (141)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    9.9.Couche de sécurité

    (142)Si les conditions de déclenchement décrites au point (126) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux, de mise à jour et d’annulation tant que la validityDuration n’a pas expiré. Les DENM nouveaux, de mise à jour et d’annulation correspondants doivent être envoyés au moyen du même AT.

    10.Avertissement en cas de véhicule spécial — avertissement en cas de véhicule de dépannage à l’arrêt

    10.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant un véhicule de dépannage assistant un véhicule en panne. Le service STI-C du service de dépannage en mouvement, c’est-à-dire remorquant un véhicule en panne, est couvert par le CAM commun.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«avertissement en cas de véhicule spécial — véhicule d'urgence en intervention»;

    ·«avertissement en cas de véhicule spécial — véhicule d'urgence de sécurisation à l’arrêt».

    10.2.Conditions de déclenchement

    10.2.1.Conditions préalables

    (143)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C soit déclenché:

    ·le stationType est confirmé comme étant un véhicule d'urgence [le stationType du CAM est fixé à specialVehicles(10)]. Le service STI-C est réservé aux véhicules de dépannage;

    ·le temporisateur d’arrêt doit être remis à zéro.

    10.2.2.Conditions spécifiques au service

    (144)Si le véhicule est à l’arrêt et si la rampe lumineuse est utilisée, un temporisateur d’arrêt doit être remis à zéro et démarré. Si la rampe lumineuse n’est plus utilisée ou si le véhicule n’est plus à l’arrêt, le temporisateur d’arrêt doit être arrêté et remis à zéro.

    (145)Si les conditions préalables mentionnées au point (143) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (a)la rampe lumineuse est utilisée, les feux de détresse sont allumés et le frein de stationnement est utilisé ou (dans le cas d’une transmission automatique) la fonction «stationnement» est sélectionnée;

    (b)la rampe lumineuse est utilisée, les feux de détresse sont allumés et le temporisateur d’arrêt est fixé à 60 secondes ou plus.

    (146)Le niveau de la qualité des informations peut être renforcé par les conditions suivantes:

    (c)l’état de la portière du conducteur est «ouvert»;

    (d)le siège du conducteur est détecté, au moyen d’une des techniques suivantes, comme «non occupé»:

    (1)caméra de l’habitacle;

    (2)technique de pointe de détection de l’occupation des sièges utilisée pour le rappel du port de la ceinture de sécurité.

    (147)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée. Cette exigence s’applique à toutes les occurrences ultérieures d’analyse de vitesse de véhicule.

    (148)Si le service STI-C est déclenché en raison du fait que la condition a) du point (145) est remplie, le temporisateur d’arrêt doit être interrompu et fixé à 60 secondes. Pendant la phase de mise à jour, seules les conditions doivent faire l’objet d’une vérification et aucun temporisateur ne doit être démarré.

    10.2.3.Qualité des informations

    (149)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir points (145) et (146)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 19: Qualité des informations relatives au service «avertissement en cas de véhicule de dépannage à l’arrêt»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    La condition b) est remplie

    1

    La condition a) est remplie

    2

    Au moins une des conditions a) ou b) est remplie et la condition c) est remplie

    3

    Au moins une des conditions a) ou b) est remplie et la condition d) est remplie

    4

    (150)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    10.3.Conditions de terminaison

    (151)Ce service STI-C se termine par une annulation de la station STI-C d’origine. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    10.3.1.Annulation

    (152)Si la condition suivante est remplie avant que la période établie de l’élément de données validityDuration ait expiré, la génération d’un DENM d’annulation doit être déclenchée et le vehicleRole doit être fixé à default(0):

    (a)les conditions spécifiques au service STI-C a) et b) mentionnées au point (145) ne sont pas remplies.

    10.3.2.Négation

    (153)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.    

    10.4.Mise à jour

    (154)Le DENM généré doit être mis à jour toutes les 60 secondes si les conditions de déclenchement sont toujours remplies. Tous les champs de données auxquels de nouvelles valeurs sont attribuées sont définis dans le tableau 20 ci-après.

    10.5.Durée de répétition et intervalle de répétition

    (155)Les DENM qui sont nouveaux, ont été mis à jour ou ont été annulés doivent être répétés pendant une repetitionDuration de 60 secondes avec un repetitionInterval de 1 seconde. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: la validityDuration est fixée à 180 secondes. Par conséquent, il est possible d'empêcher un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    10.6.Classe de trafic

    (156)Les DENM nouveaux, de mise à jour et d’annulation doivent être fixés à la classe de trafic 1.

    10.7.Paramètres du message

    10.7.1.DENM

    (157)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 20: Éléments de données du DENM «avertissement en cas de véhicule de dépannage à l’arrêt»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM, d'un DENM de mise à jour ou d'un DENM d’annulation. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi en cas de DENM nouveau ou de mise à jour. Doit être fixé à isCancellation(0) si les conditions d’annulation sont remplies, voir point (152).

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    relevanceDistance

    lessThan5km(5)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens

     

    0

    allTrafficDirections(0)

     

    1

    upstreamTraffic(1)

     

    2

    allTrafficDirections(0)

     

    3

    upstreamTraffic(1)

     

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    180 secondes

    stationType

    specialVehicles(10)

    Conteneur de situation

    informationQuality

    Voir point (149). Doit être rafraîchi pour chaque DENM de mise à jour.

    causeCode

    rescueAndRecoveryWorkInProgress(15)

    subCauseCode

    unavailable(0)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 8942].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    Conteneur à la carte: StationaryVehicleContainer

    stationarySince

    Doit être établi en fonction de la durée en minutes de l’immobilité de la station STI-C de détection. Doit être établi conformément à la norme [TS 102 894-2].

     

    Doit être rafraîchi pour un DENM de mise à jour.

    10.7.2.CAM

    (158)Le vehicleRole doit être initialisé à son réglage par «défaut» [le vehicleRole du CAM est fixé à default(0)]. Si au moins une des conditions de déclenchement définies au point (145) est remplie, le vehicleRole doit être fixé à rescue(5).

    (159)Le tableau suivant précise les éléments de données du CAM devant être établis si le service STI-C est déclenché.

    Tableau 21: Éléments de données du CAM «avertissement en cas de véhicule de dépannage à l’arrêt»

    Champ de données

    Valeur

    CoopAwareness

    generationDeltaTime

    Moment correspondant au moment de la position de référence dans le CAM, considéré comme le moment de génération du CAM.

    Doit être établi conformément à la norme [EN 302 637-2].

    BasicContainer

    stationType

    specialVehicles(10)

    referencePosition

    Position et précision de position mesurées au point de référence de la station STIC d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le HighFrequencyContainer doit être fixé à BasicVehicleContainerHighFrequency

    heading

    La direction du cap de la station STI-C d’origine par rapport au nord véritable.

    Doit être établi conformément à la norme [TS 102 894-2].

    speed

    La vitesse de conduite de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    driveDirection

    Sens de déplacement du véhicule (marche avant ou marche arrière) de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    vehicleLength

    Longueur du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    vehicleWidth

    Largeur du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    longitudinalAcceleration

    Accélération longitudinale du véhicule de la station STI-C d’origine.

    Doit être établi conformément à la norme [TS 102 894-2].

    curvature

    Courbure de la précision et de la trajectoire du véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    curvatureCalcMode

    Indique si le taux de lacet est utilisé pour calculer la courbure pour une valeur de courbure rapportée.

    Doit être établi conformément à la norme [TS 102 894-2].

    yawRate

    Le taux de lacet du véhicule à un moment donné.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le LowFrequencyContainer doit être fixé à BasicVehicleContainerLowFrequency

    vehicleRole

    rescue(5)

    exteriorLights

    Indique l’état des interrupteurs d'éclairage extérieur d’un véhicule.

    Doit être établi conformément à la norme [TS 102 894-2].

    pathHistory

    Représente le mouvement d’un véhicule sur une distance et/ou une période récente.

    Doit être établi conformément à la norme [TS 102 894-2].

    Le SpecialVehicleContainer doit être fixé à SafetyCarContainer

    lightBarSirenInUse

    Le bit lightBarActivated doit être mis à 1 (onChange) si l’utilisation de la rampe lumineuse est détectée; sinon, il doit être fixé à 0.

    Le bit sirenActivated doit être mis à 1 si l’utilisation de la sirène est détectée; sinon, il doit être mis à 0.

    causeCode

    Comme spécifié au point (157).

    subCauseCode

    Comme spécifié au point (157).

    10.8.Couche de mise en réseau et de transport

    (160)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    10.9.Couche de sécurité

    (161)Si les conditions de déclenchement décrites au point (145) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux, de mise à jour et d’annulation tant que la validityDuration n’a pas expiré. Les DENM nouveaux, de mise à jour et d’annulation correspondants doivent être envoyés au moyen du même AT.

    11.Échange d’IRC — IRC de demande

    11.1.Description du service STI-C

    Le service STI-C transmet des informations V2V concernant une situation de conduite critique dans le cadre de laquelle une collision entre deux véhicules est très probable ou inévitable. L'égo-véhicule reconnaît une collision potentielle et envoie son propre IRC pour obtenir l’IRC de collision de l’autre véhicule en réponse.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«échange d’IRC — IRC de réponse».

    (162)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme valides. Un tel signal incite la pile à générer un nouveau DENM. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    11.2.Conditions de déclenchement

    11.2.1.Conditions préalables

    (163)Aucune condition préalable spécifique ne s’applique dans le cadre de ce service STI-C.

    11.2.2.Conditions spécifiques au service

    (164)Si les deux conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (a)le «temps restant avant la collision» (TTC) calculé par un algorithme de dispositif de mesure embarqué est inférieur à 1,5 seconde. La tolérance acceptable pour la valeur TTC calculée s’élève à 10 %;

    (b)la vitesse relative entre deux véhicules allant potentiellement entrer en collision est supérieure à 20 km/h.

    Remarque: calculer le TTC sur la base de la position GNSS uniquement, telle que fournie par des récepteurs GNSS de pointe, n’est pas suffisamment fiable dans le cadre de ce service.

    11.2.3.Qualité des informations

    (165)La valeur de l’élément de données informationQuality dans le DENM dépend de la façon dont l’événement est détecté. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 22: Qualité des informations relatives au service «Échange d’IRC — IRC de demande»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    Autres

    1

    11.3.Conditions de terminaison

    (166)Une terminaison du service STI-C ne doit pas être envisagée.

    11.3.1.Annulation

    (167)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    11.3.2.Négation

    (168)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    11.4.Mise à jour

    (169)Un DENM de mise à jour ne doit pas être utilisé pour ce service STI-C.

    11.5.Durée de répétition et intervalle de répétition

    (170)Les nouveaux DENM doivent être répétés pendant une repetitionDuration de 300 millisecondes (100 millisecondes à trois reprises consécutives) avec un repetitionInterval de 100 millisecondes. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: comme il n’est pas garanti qu’un IRC envoyé atteindra le récepteur (par exemple, en raison de la charge du canal, si le récepteur est temporairement hors de portée, etc.), l’émetteur envoie l’IRC à trois reprises consécutives, soit l’équivalent d’une repetitionDuration de 300 millisecondes.

    Remarque: la durée estimée de transmission (application à application) d’un IRC (répétition non comprise) sur le réseau local sans fil (WLAN) automobile est de 200 à 300 millisecondes. Si seule la troisième tentative est reçue (dans le pire cas de figure), dans les deux cas (demande et réponse), les informations seront disponibles pour les deux véhicules après 1 seconde [2 * (300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz))]. Par conséquent, le paramètre de déclenchement TTC inférieur à 1,5 seconde est suffisant. L’envoi de l’IRC à trois reprises consécutives est considéré comme un bon compromis entre la charge du canal et le succès de la transmission.

    Remarque: seul le premier DENM sera envoyé sans contraintes de gestion décentralisée de l’encombrement (DCC). Les deuxième et troisième DENM peuvent être affectés par la DCC (en fonction de la charge actuelle du canal).

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    11.6.Classe de trafic

    (171)Les nouveaux DENM doivent être fixés à la classe de trafic 0.

    11.7.Paramètres du message

    11.7.1.DENM

    (172)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 23: Éléments de données du DENM «Échange d’IRC — IRC de demande»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STIC d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    relevanceDistance

    lessThan100m(1)
    Remarque: doit également couvrir le pire cas de figure dans lequel le véhicule roule à une vitesse de près de 250 km/h et se dirige vers une fin de file dangereuse (s = v*t = 69,4 m/s * 1,5 s = 104,2 m).

    relevanceTrafficDirection

    allTrafficDirections(0)

    validityDuration

    2 secondes
    Remarque: doit être supérieur au TTC.

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (165)

    causeCode

    collisionRisk(97)

    subCauseCode

    unavailable(0)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    roadType

    Doit être établi conformément à la norme [TS 102 894-2]. Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte: ImpactReductionContainer

    heightLonCarrLeft

    Hauteur du longeron de gauche du véhicule entre la base et le sommet. Doit être établi conformément à la norme [TS 102 894-2].

    heightLonCarrRight

    Hauteur du longeron de droite du véhicule entre la base et le sommet. Doit être établi conformément à la norme [TS 102 894-2].

    posLonCarrLeft

    Distance longitudinale entre le centre du pare-chocs avant du véhicule et l’avant du longeron de gauche du véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    posLonCarrRight

    Distance longitudinale entre le centre du pare-chocs avant du véhicule et l’avant du longeron de droite du véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    positionOfPillars

    Les montants du véhicule font référence au support vertical ou quasi vertical du véhicule, désignés respectivement A, B, C ou D. Doit être établi conformément à la norme [TS 102 894-2].

    posCentMass

    Distance perpendiculaire entre le centre de gravité d’un véhicule vide et la ligne frontale de la zone de délimitation du véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    wheelBaseVehicle

    Distance perpendiculaire entre l’essieu avant et arrière de la base des roues d’un véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    turningRadius

    Plus petit demi-tour circulaire que le véhicule est capable de réaliser. Doit être établi conformément à la norme [TS 102 894-2].

    posFrontAx

    Distance perpendiculaire entre la ligne frontale de la zone de délimitation du véhicule et l’essieu avant. Doit être établi conformément à la norme [TS 102 894-2].

    positionOfOccupants

    BitString indiquant si un siège passager est occupé ou si l’état d’occupation est détectable. Doit être établi conformément à la norme [TS 102 8942].

    vehicleMass

    Masse d’un véhicule à vide. Doit être établi conformément à la norme [TS 102 894-2].

    requestResponseIndication

    request(0)

    11.7.2.CAM

    (173)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    11.8.Couche de mise en réseau et de transport

    (174)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    11.9.Couche de sécurité

    (175)Si les conditions de déclenchement décrites au point (164) s’appliquent, un changement de AT doit être bloqué tant que la validityDuration n’a pas expiré.

    12.Échange d’IRC — IRC de réponse

    12.1.Description du service STI-C

    Le service STI-C transmet des informations V2V concernant une situation de conduite critique dans le cadre de laquelle une collision entre deux véhicules est très probable ou inévitable. L'égo-véhicule a reçu un IRC d’un autre véhicule et envoie son propre IRC en réponse.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«échange d’IRC — IRC de demande».

    (176)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme valides. Un tel signal incite la pile à générer un nouveau DENM. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    12.2.Conditions de déclenchement

    12.2.1.Conditions préalables

    (177)Un IRC tel que décrit dans le tableau 23 a été reçu.

    12.2.2.Conditions spécifiques au service

    (178)Si la condition préalable mentionnée au point (177) et les deux conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (a)la requestResponseIndication dans l’IRC reçu est fixée à request(0);

    (b)la distance perpendiculaire entre le véhicule demandeur (position de l’événement dans l’IRC) et l'égo-véhicule (position de référence telle que définie dans le CAM) est inférieure à 100 m.

    Remarque: lorsqu’un IRC est reçu, le récepteur doit vérifier si l’IRC a effectivement été demandé avant de répondre avec son propre IRC. Cela peut être effectué sur la base de la requestResponseIndication. Afin d’éviter une charge inutile sur le canal de transmission provenant de plusieurs IRC transmis, seuls les véhicules se trouvant à proximité immédiate (dans un rayon de moins de 100 m) répondent à la demande.

    12.2.3.Qualité des informations

    (179)La valeur de l’élément de données informationQuality dans le DENM dépend de la façon dont l’événement est détecté. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 24: Qualité des informations relatives au service «Échange d’IRC — IRC de réponse»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    Autres

    1

    12.3.Conditions de terminaison

    (180)Une terminaison du service STI-C ne doit pas être envisagée.

    12.3.1.Annulation

    (181)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    12.3.2.Négation

    (182)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    12.4.Mise à jour

    (183)Un DENM de mise à jour ne doit pas être utilisé pour ce service STI-C.

    12.5.Durée de répétition et intervalle de répétition

    (184)Les nouveaux DENM doivent être répétés pendant une repetitionDuration de 300 millisecondes (100 millisecondes à trois reprises consécutives) avec un repetitionInterval de 100 millisecondes. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: comme il n’est pas garanti qu’un IRC envoyé atteindra le récepteur (par exemple, en raison de la charge du canal, si le récepteur est temporairement hors de portée, etc.), l’émetteur envoie l’IRC à trois reprises consécutives, soit l’équivalent d’une repetitionDuration de 300 millisecondes.

    Remarque: la durée estimée de transmission (application à application) d’un IRC (répétition non comprise) sur le réseau local sans fil (WLAN) automobile est de 200 à 300 millisecondes. Si seule la troisième tentative est reçue (dans le pire cas de figure), dans les deux cas (demande et réponse), les informations seront disponibles pour les deux véhicules après 1 seconde [2 * (300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz))]. Par conséquent, le paramètre de déclenchement TTC inférieur à 1,5 seconde est suffisant. L’envoi de l’IRC à trois reprises consécutives est considéré comme un bon compromis entre la charge du canal et le succès de la transmission.

    Remarque: seul le premier DENM sera envoyé sans contraintes de DCC. Les deuxième et troisième DENM peuvent être affectés par la DCC (en fonction de la charge actuelle du canal).

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    12.6.Classe de trafic

    (185)Les nouveaux DENM doivent être fixés à la classe de trafic 0.

    12.7.Paramètres du message

    12.7.1.DENM

    (186)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 25: Éléments de données du DENM «Échange d’IRC — IRC de réponse»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STIC d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    relevanceDistance

    lessThan100m(1)

    relevanceTrafficDirection

    allTrafficDirections(0)

    validityDuration

    2 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (179).

    causeCode

    collisionRisk(97)

    subCauseCode

    unavailable(0)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    roadType

    Doit être établi conformément à la norme [TS 102 894-2]. Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte: ImpactReductionContainer

    heightLonCarrLeft

    Hauteur du longeron de gauche du véhicule entre la base et le sommet. Doit être établi conformément à la norme [TS 102 894-2].

    heightLonCarrRight

    Hauteur du longeron de droite du véhicule entre la base et le sommet. Doit être établi conformément à la norme [TS 102 894-2].

    posLonCarrLeft

    Distance longitudinale entre le centre du pare-chocs avant du véhicule et l’avant du longeron de gauche du véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    posLonCarrRight

    Distance longitudinale entre le centre du pare-chocs avant du véhicule et l’avant du longeron de droite du véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    positionOfPillars

    Les montants du véhicule font référence au support vertical ou quasi vertical du véhicule, désignés respectivement A, B, C ou D. Doit être établi conformément à la norme [TS 102 894-2].

    posCentMass

    Distance perpendiculaire entre le centre de gravité d’un véhicule vide et la ligne frontale de la zone de délimitation du véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    wheelBaseVehicle

    Distance perpendiculaire entre l’essieu avant et arrière de la base des roues d’un véhicule. Doit être établi conformément à la norme [TS 102 894-2].

    turningRadius

    Plus petit demi-tour circulaire que le véhicule est capable de réaliser. Doit être établi conformément à la norme [TS 102 894-2].

    posFrontAx

    Distance perpendiculaire entre la ligne frontale de la zone de délimitation du véhicule et l’essieu avant. Doit être établi conformément à la norme [TS 102 894-2].

    positionOfOccupants

    BitString indiquant si un siège passager est occupé ou si l’état d’occupation est détectable. Doit être établi conformément à la norme [TS 102 8942].

    vehicleMass

    Masse d’un véhicule à vide. Doit être établi conformément à la norme [TS 102 894-2].

    requestResponseIndication

    response(1)

    12.7.2.CAM

    (187)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    12.8.Couche de mise en réseau et de transport

    (188)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    12.9.Couche de sécurité

    (189)Si les conditions de déclenchement décrites au point (178) s’appliquent, un changement de AT doit être bloqué tant que la validityDuration n’a pas expiré. Les nouveaux DENM correspondants doivent être envoyés au moyen du même AT.

    13.Situation dangereuse — allumage du feu-stop électronique d'urgence

    13.1.Description du service STI-C

    Le service STI-C transmet des informations V2V concernant un freinage d'urgence effectué par le conducteur, par exemple en réponse à un véhicule à l’arrêt ou à un véhicule roulant à une vitesse inférieure à l’avant. L'égo-véhicule lui-même devient une zone de danger local potentielle.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«situations dangereuses — intervention du freinage automatique»;

    ·«situations dangereuses — intervention du système de retenue réversible de l’occupant».

    13.2.Conditions de déclenchement

    13.2.1.Conditions préalables

    (190)Aucune condition préalable spécifique ne s’applique dans le cadre de ce service STI-C.

    (191)Il convient d’éviter l’activation parallèle avec les autres services STI-C liés. Lorsque les services STI-C «intervention du freinage automatique» et/ou «intervention du système de retenue réversible de l’occupant» sont déclenchés simultanément, les services STI-C doivent être hiérarchisés comme suit:

    (a)«allumage du feu-stop électronique d'urgence» (priorité la plus élevée);

    (b)«intervention du freinage automatique»;

    (c)«intervention du système de retenue réversible de l’occupant» (priorité la moins élevée).

    (192)Si un service STI-C de priorité supérieure est déclenché, toute transmission de service STI-C lié de priorité inférieure déjà déclenchée et toujours active concernant la mise à jour doit être avortée. En outre, la génération d’un nouveau DENM pour le service STI-C de priorité supérieure doit être demandée.

    13.2.2.Conditions spécifiques au service

    (193)Si la condition suivante est remplie, les conditions de déclenchement pour ce service STIC sont remplies et la génération d’un DENM doit être déclenchée:

    (a)un signal représentant la demande d’allumage du feu-stop électronique d'urgence est détecté. Les conditions d’une telle demande sont établies dans les règlements [ECE 48], [ECE 13] et [ECE 13H].

    Les véhicules peuvent également utiliser la condition de déclenchement de remplacement suivante:

    (b)la vitesse actuelle du véhicule est supérieure à 20 km/h et l’accélération actuelle est inférieure à -7 m/s² pour un minimum de 500 millisecondes.

    (194)L’accélération du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. L’accélération filtrée par rapport au bruit du capteur doit être utilisée.

    13.2.3.Qualité des informations

    (195)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (193)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 26: Qualité des informations relatives au service «allumage du feu-stop électronique d'urgence»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    0

    La condition a) est remplie

    1

    La condition a) est remplie et l’accélération longitudinale filtrée actuelle du véhicule est inférieure à -4 m/s2

    2

    La condition b) est remplie

    3

    (196)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    13.3.Conditions de terminaison

    (197)Le service STI-C doit être terminé lorsque la condition a) ou la condition b) n’est plus valide. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    13.3.1.Annulation

    (198)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    13.3.2.Négation

    (199)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    13.4.Mise à jour

    (200)Le DENM généré doit être mis à jour toutes les 100 millisecondes si les conditions de déclenchement sont toujours remplies. Tous les champs de données auxquels de nouvelles valeurs sont attribuées sont définis dans le tableau 27 ci-après.

    13.5.Durée de répétition et intervalle de répétition

    (201)Une répétition du DENM ne doit pas être utilisée pour ce service STI-C.

    13.6.Classe de trafic

    (202)Les DENM nouveaux et de mise à jour doivent être fixés à la classe de trafic 0.

    13.7.Paramètres du message

    13.7.1.DENM

    (203)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 27: Éléments de données du DENM «allumage du feu-stop électronique d'urgence»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM ou d'un DENM de mise à jour. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour chaque DENM de mise à jour.

    relevanceDistance

    lessThan500m(3)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens 

    0

    allTrafficDirections(0) 

    1

    upstreamTraffic(1) 

    2

    allTrafficDirections(0) 

    3

    upstreamTraffic(1) 

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    2 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (195).

    causeCode

    dangerousSituation(99)

    subCauseCode

    emergencyElectronicBrakeEngaged(1)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    13.7.2.CAM

    (204)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    13.8.Couche de mise en réseau et de transport

    (205)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    13.9.Couche de sécurité

    (206)Si les conditions de déclenchement décrites au point (193) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux et de mise à jour tant que la validityDuration n’a pas expiré. Les DENM nouveaux et de mise à jour correspondants doivent être envoyés au moyen du même AT.

    14.Situations dangereuses — intervention du freinage automatique

    14.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant une intervention du freinage d'urgence automatique par le véhicule. L'égo-véhicule lui-même devient une zone de danger local potentielle.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«situations dangereuses — allumage du feu-stop électronique d'urgence»;

    ·«situations dangereuses — intervention du système de retenue réversible de l’occupant».

    14.2.Conditions de déclenchement

    14.2.1.Conditions préalables

    (207)Aucune condition préalable spécifique ne s’applique dans le cadre de ce service STI-C.

    (208)Il convient d’éviter l’activation parallèle avec les autres services STI-C liés. Lorsque les services STI-C «allumage du feu-stop électronique d'urgence» et/ou «intervention du système de retenue réversible de l’occupant» sont déclenchés simultanément, les services STI-C doivent être hiérarchisés comme suit:

    (a)«allumage du feu-stop électronique d'urgence» (priorité la plus élevée);

    (b)«intervention du freinage automatique»;

    (c)«intervention du système de retenue réversible de l’occupant» (priorité la moins élevée).

    (209)Si un service STI-C de priorité supérieure est déclenché, toute transmission de service STI-C lié de priorité inférieure déjà déclenchée et toujours active concernant la mise à jour doit être avortée. En outre, la génération d’un nouveau DENM pour le service STI-C de priorité supérieure doit être demandée.

    14.2.2.Conditions spécifiques au service

    (210)Si la condition suivante est remplie, les conditions de déclenchement pour ce service STIC sont remplies et la génération d’un DENM doit être déclenchée:

    (a)un signal représentant une demande d’intervention d’un système de freinage d'urgence autonome est détecté.

    (211)L’accélération du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. L’accélération filtrée par rapport au bruit du capteur doit être utilisée.

    14.2.3.Qualité des informations

    (212)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (210)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 28: Qualité des informations relatives au service «intervention du freinage automatique»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    0

    La condition a) est remplie

    1

    La condition a) est remplie et l’accélération longitudinale filtrée actuelle du véhicule est inférieure à -4 m/s2

    2

    (213)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    14.3.Conditions de terminaison

    (214)Le service STI-C doit être terminé lorsque la condition a) n’est plus valide. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    14.3.1.Annulation

    (215)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    14.3.2.Négation

    (216)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    14.4.Mise à jour

    (217)Le DENM généré doit être mis à jour toutes les 100 millisecondes si les conditions de déclenchement sont toujours remplies. Tous les champs de données auxquels de nouvelles valeurs sont attribuées sont définis dans le tableau 29.

    14.5.Durée de répétition et intervalle de répétition

    (218)Une répétition du DENM ne doit pas être utilisée pour ce service STI-C.

    14.6.Classe de trafic

    (219)Les DENM nouveaux et de mise à jour doivent être fixés à la classe de trafic 0.

    14.7.Paramètres du message

    14.7.1.DENM

    (220)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 29: Éléments de données du DENM «intervention du freinage automatique»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM ou d'un DENM de mise à jour. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour chaque DENM de mise à jour.

    relevanceDistance

    lessThan500m(3)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens 

    0

    allTrafficDirections(0) 

    1

    upstreamTraffic(1) 

    2

    allTrafficDirections(0) 

    3

    upstreamTraffic(1) 

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    2 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (212)

    causeCode

    dangerousSituation(99)

    subCauseCode

    aebEngaged(5)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    14.7.2.CAM

    (221)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    14.8.Couche de mise en réseau et de transport

    (222)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    14.9.Couche de sécurité

    (223)Si les conditions de déclenchement décrites au point (210) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux et de mise à jour tant que la validityDuration n’a pas expiré. Les DENM nouveaux et de mise à jour correspondants doivent être envoyés au moyen du même AT.

    15.Situation dangereuse — intervention du système de retenue réversible de l’occupant

    15.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant une intervention active d’un système de retenue réversible de l’occupant (tendeur de ceinture réversible, par exemple) dans l'égo-véhicule en raison de conditions de conduite critiques.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«situations dangereuses — allumage du feu-stop électronique d'urgence»;

    ·«situations dangereuses — intervention du freinage automatique».

    15.2.Conditions de déclenchement

    15.2.1.Conditions préalables

    (224)Aucune condition préalable spécifique ne s’applique dans le cadre de ce service STI-C.

    (225)Il convient d’éviter l’activation parallèle avec les autres services STI-C liés. Lorsque les services STI-C «allumage du feu-stop électronique d'urgence» et/ou «intervention du freinage automatique» sont déclenchés simultanément, les services STI-C doivent être hiérarchisés comme suit:

    (a)«allumage du feu-stop électronique d'urgence» (priorité la plus élevée);

    (b)«intervention du freinage automatique»;

    (c)«intervention du système de retenue réversible de l’occupant» (priorité la moins élevée).

    (226)Si un service STI-C de priorité supérieure est déclenché, toute transmission de service STI-C lié de priorité inférieure déjà déclenchée et toujours active concernant la mise à jour doit être avortée. En outre, la génération d’un nouveau DENM pour le service STI-C de priorité supérieure doit être demandée.

    15.2.2.Conditions spécifiques au service

    (227)Si la condition suivante est remplie, la génération d’un DENM doit être déclenchée:

    (a)un signal représentant une demande d’intervention active d’un système de retenue réversible de l’occupant (tendeur de ceinture réversible, par exemple) est détecté en raison de conditions de conduite critiques.

    15.2.3.Qualité des informations

    (228)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (227)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 30: Qualité des informations relatives au service «intervention du système de retenue réversible de l’occupant»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    0

    La condition a) est remplie

    1

    La condition a) est remplie et l’accélération longitudinale filtrée actuelle du véhicule est inférieure à -4 m/s2

    2

    (229)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    15.3.Conditions de terminaison

    (230)Le service STI-C doit être terminé lorsque la condition a) n’est plus valide. Lors de la terminaison du service STI-C, la demande de DENM de mise à jour doit être terminée.

    15.3.1.Annulation

    (231)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    15.3.2.Négation

    (232)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    15.4.Mise à jour

    (233)Le DENM généré doit être mis à jour toutes les 100 millisecondes si les conditions de déclenchement sont toujours remplies. Tous les champs de données auxquels de nouvelles valeurs sont attribuées sont définis dans le tableau 31 ci-après.

    15.5.Durée de répétition et intervalle de répétition

    (234)Une répétition du DENM ne doit pas être utilisée pour ce service STI-C.

    15.6.Classe de trafic

    (235)Les DENM nouveaux et de mise à jour doivent être fixés à la classe de trafic 0.

    15.7.Paramètres du message

    15.7.1.DENM

    (236)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 31: Éléments de données du DENM «intervention du système de retenue réversible de l’occupant»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM ou d'un DENM de mise à jour. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour chaque DENM de mise à jour.

    relevanceDistance

    lessThan500m(3)

    relevanceTrafficDirection

    Si le roadType est connu, la valeur doit être établie comme suit:

    RoadType

    Sens

    0

    allTrafficDirections(0)

    1

    upstreamTraffic(1)

    2

    allTrafficDirections(0)

    3

    upstreamTraffic(1)

    Sinon, la valeur doit être fixée à allTrafficDirections(0)

    validityDuration

    2 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (228).

    causeCode

    dangerousSituation(99)

    subCauseCode

    preCrashSystemEngaged(2)

    Conteneur de localisation

    eventSpeed

    Vitesse de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    eventPositionHeading

    En-tête de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    traces

    PathHistory (historique de cheminement) de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    Conteneur à la carte

    lanePosition

    Si le DE lanePosition est obtenu au moyen d’un capteur embarqué (radar, capteur d’images, par exemple), la valeur doit être établie conformément à la norme [TS 102 894-2]. L’utilisation d’un GNSS ou d’une carte numérique pour estimer le numéro de voie n’est pas légitime pour cette version de la condition de déclenchement.

    Si le DE lanePosition est inconnu, il doit être omis.

    Doit être rafraîchi pour un DENM de mise à jour.

    15.7.2.CAM

    (237)Une adaptation de CAM ne doit pas être utilisée pour ce service STI-C.

    15.8.Couche de mise en réseau et de transport

    (238)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    15.9.Couche de sécurité

    (239)Si les conditions de déclenchement décrites au point (227) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux et de mise à jour tant que la validityDuration n’a pas expiré. Les DENM nouveaux et de mise à jour correspondants doivent être envoyés au moyen du même AT.

    16.Conditions météorologiques défavorables — brouillard

    16.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant du brouillard pouvant obstruer le champ de vision du conducteur.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«conditions météorologiques défavorables — précipitations».

    (240)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme valides. Un tel signal incite la pile à générer un DENM nouveau ou de mise à jour. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    16.2.Conditions de déclenchement

    16.2.1.Conditions préalables

    (241)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C soit déclenché:

    (a)la vitesse du véhicule est supérieure à 7 km/h;

    (b)la vitesse du véhicule est inférieure à 80 km/h.

    (242)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée.

    16.2.2.Conditions spécifiques au service

    (243)Si les conditions préalables mentionnées au point (241) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (1)réaction du conducteur et état des feux:

    (a)le conducteur allume les feux brouillard arrière et les feux de croisement. Toutes ces conditions doivent être valides pendant plus de 20 secondes (pour réduire au minimum le risque d’utilisation abusive par le conducteur, les conditions doivent être valides pendant une période plus longue);

    (b)le conducteur allume les feux brouillard arrière et les feux de croisement et la vitesse du véhicule est inférieure à 60 km/h. Toutes ces conditions doivent être valides pendant une durée supérieure à 20 secondes;

    (2)dispositif de mesure de la distance de visibilité:

    (a)la visibilité due au brouillard est inférieure à 80 m avec +/- 40 m de tolérance pendant plus de 5 secondes [la vision difficile doit être détectée pendant une période raisonnable; la période est plus courte que pour les conditions a) et b), car les informations disponibles sont plus fiables];

    (b)la visibilité due au brouillard est inférieure à 80 m avec +/- 40 m de tolérance et la vitesse du véhicule est inférieure à 60 km/h (si le véhicule se trouve dans une zone non urbaine, cette vitesse peut indiquer une visibilité réduite) pendant plus de 5 secondes.

    (244)Un DENM nouveau ou de mise à jour ne doit pas être généré dans le Detection Blocking Time. Le Detection Blocking Time est lancé après la détection de l’événement et le déclenchement d’un DENM à cet effet. De cette façon, un seul événement ne peut pas déclencher une série de DENM. S’agissant du dispositif de mesure de la distance de visibilité [conditions c) et d)], le Detection Blocking Time doit être de 15 secondes. Pour les autres conditions, il ne doit pas y avoir de Detection Blocking Time.

    (245)Afin de garantir un comportement fonctionnel cohérent pour les différentes conditions de déclenchement et le Detection Blocking Time, le Minimum Detection Interval (intervalle minimal de détection) entre deux événements détectés doit être de 20 secondes.

    16.2.3.Qualité des informations

    (246)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (243)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 32: Qualité des informations relatives au service «conditions météorologiques défavorables — brouillard»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    La condition a) est remplie

    1

    La condition b) est remplie

    2

    La condition c) est remplie

    3

    La condition d) est remplie

    4

    (247)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    16.3.Conditions de terminaison

    (248)Une terminaison du service STI-C ne doit pas être envisagée.

    16.3.1.Annulation

    (249)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    16.3.2.Négation

    (250)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    16.4.Mise à jour

    (251)La procédure de mise à jour appropriée du DENM doit être déterminée sur la base des conditions suivantes:

    (a)au moins une des conditions mentionnées au point (243) est remplie après le Minimum Detection Interval spécifié à la section 16.2.2;

    (b)la validityDuration de l’ancien DENM n’a pas expiré;

    (c)ni la valeur de l’élément de données DeltaLatitude ni celle de l’élément de données DeltaLongitude, représentant la distance entre l’événement détecté actuel et l’ancien événement détecté, ne dépasse le seuil qui peut être couvert par les éléments de données DeltaLatitude et DeltaLongitude.

    (252)Si les conditions a), b) et c) telles que décrites au point (251) sont remplies, un DENM de mise à jour doit être généré. Les informations des anciens éléments de données du DENM (eventPosition, eventDeltaTime, informationQuality) doivent être conservées dans l’eventHistory en tant qu'eventPoint supplémentaire.

    Les points d’événement doivent être classés en ordre croissant en fonction de leur durée de vie, l’eventPoint le plus récent étant en première position. Les points d’événement de l’eventHistory présentant une durée de vie dépassant la validityDuration doivent être supprimés de l’eventHistory pour le DENM de mise à jour. Si la distance couverte par l’eventHistory dépasse le seuil autorisé par la sécurité, les points d’événement les plus anciens doivent être supprimés de l’eventHistory.

    Les informations relatives à l’événement détecté actuel doivent être attribuées aux champs de données DENM du DENM mis à jour.

    Remarque: il appartient au récepteur de gérer les points d’événement présentant une durée de vie dépassant la validityDuration après la génération du DENM de mise à jour.

    (253)Si les conditions a) et b) sont remplies, mais que la condition c) n’est pas remplie, aucun DENM de mise à jour ne doit être généré. À la place, un nouveau DENM supplémentaire doit être généré. Les informations relatives à l’événement détecté actuel doivent être attribuées aux champs de données DENM du nouveau DENM supplémentaire. L’ancien DENM doit continuer à être transmis tant que la repetitionDuration de l’ancien DENM n’expire pas.

    (254)Si la condition a) est remplie, mais que la condition b) n’est pas remplie, aucun DENM de mise à jour ne doit être généré, mais un nouveau DENM en fonction de l’événement détecté actuel doit être généré.

    Remarque: dans ce cas, la transmission de l’ancien DENM a déjà été interrompue, car la repetitionDuration de l’ancien DENM a expiré.

    (255)Si la condition a) n’est pas remplie, la génération d’un DENM de mise à jour n’est pas nécessaire.

    16.5.Durée de répétition et intervalle de répétition

    (256)Les DENM qui sont nouveaux ou ont été mis à jour doivent être répétés pendant une repetitionDuration de 180 secondes avec un repetitionInterval de 4 secondes. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: la validityDuration est fixée à 300 secondes. Par conséquent, il est possible d'empêcher un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    16.6.Classe de trafic

    (257)Les DENM nouveaux et de mise à jour doivent être fixés à la classe de trafic 1.

    16.7.Paramètres du message

    16.7.1.DENM

    (258)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 33: Éléments de données du DENM «conditions météorologiques défavorables — brouillard»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. L'horodatage reflète le début de la détection de l’événement actuel. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour et être fixé au moment de détection de l’événement actuel.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM ou d'un DENM de mise à jour. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STI-C.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour.

    relevanceDistance

    ·DENM nouveau: lessThan1000m(4)

    ·DENM de mise à jour: lessThan5km(5) (le recours à des mises à jour rend la distance couverte par l’eventHistory plus longue; pour atteindre toutes les stations STI pertinentes, la relevanceDistance est plus longue dans ce cas.)

    relevanceTrafficDirection

    allTrafficDirections(0)

    validityDuration

    300 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (246). Doit être rafraîchi pour chaque DENM de mise à jour et être fixé à l’informationQuality du point d’événement actuel.

    causeCode

    adverseWeatherCondition-Visibility(18)

    subCauseCode

    unavailable(0) ou fog(1)

    eventHistory

    Cet élément ne doit être utilisé que pour les DENM de mise à jour (voir section 16.4).

    Conteneur de localisation

    traces

    Le PathHistory de la station STI-C d’origine par rapport au point d’événement actuel.
    Doit être établi conformément à la norme [TS 102 894-2].
    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    16.7.2.CAM

    (259)Une adaptation CAM ne doit pas être utilisée pour ce service STI-C.

    16.8.Couche de mise en réseau et de transport

    (260)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    16.9.Couche de sécurité

    (261)Si les conditions de déclenchement décrites au point (243) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux et de mise à jour pendant 15 minutes (à partir de la génération du nouveau DENM). Les DENM nouveaux et de mise à jour correspondants doivent être envoyés au moyen du même AT.

    (262)Si le AT change et en cas de transmission active de DENM (DENM nouveau ou de mise à jour), la transmission doit être interrompue. En outre, l’EventHistory et le PathHistory doivent être supprimés. Le processus de génération de DENM réguliers doit alors se poursuivre.

    17.Conditions météorologiques défavorables — précipitations

    17.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant les précipitations pouvant obstruer le champ de vision du conducteur.

    Les services STI-C suivants sont liés à ce service, car ils présentent des conditions de déclenchement similaires:

    ·«conditions météorologiques défavorables — brouillard».

    (263)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme valides. Un tel signal incite la pile à générer un DENM nouveau ou de mise à jour. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    17.2.Conditions de déclenchement

    17.2.1.Conditions préalables

    (264)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C soit déclenché:

    (a)la vitesse du véhicule est supérieure à 7 km/h;

    (b)la vitesse du véhicule est inférieure à 80 km/h;

    (c)la fonction lave-glace n’est pas active.

    (265)La vitesse du véhicule doit être déterminée par le signal de bus du véhicule et non par un GNSS. La vitesse filtrée du véhicule (par rapport au bruit du capteur) doit être utilisée.

    17.2.2.Conditions spécifiques au service

    (266)Si les conditions préalables mentionnées au point (264) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (1)niveau des essuie-glaces et état des feux:

    (a)l’essuie-glace fonctionne à son niveau de vitesse maximal. Les feux de croisement sont allumés. Toutes ces conditions doivent être valides pendant une durée supérieure à 20 secondes;

    (b)l’essuie-glace fonctionne à son niveau de vitesse maximal et la vitesse du véhicule est inférieure à 60 km/h. Les feux de croisement sont allumés. Toutes ces conditions doivent être valides pendant une durée supérieure à 20 secondes;

    (2)dispositif de mesure de la pluie, niveau des essuie-glaces et état des feux:

    (a)la pluviosité représente au moins 90 % de la mesure maximale du dispositif de mesure et l’essuie-glace fonctionne à son niveau de vitesse maximal. Les feux de croisement sont allumés. Toutes ces conditions doivent être valides pendant une durée supérieure à 20 secondes;

    (b)la pluviosité représente au moins 90 % de la mesure maximale du dispositif de mesure et l’essuie-glace fonctionne à son niveau de vitesse maximal. Les feux de croisement sont allumés et la vitesse du véhicule est inférieure à 60 km/h. Toutes ces conditions doivent être valides pendant plus de 20 secondes.

    (267)Le Minimum Detection Interval entre deux événements détectés doit être de 20 secondes.

    17.2.3.Qualité des informations

    (268)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (266)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 34: Qualité des informations relatives au service «conditions météorologiques défavorables — précipitations»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    La condition a) est remplie

    1

    La condition b) est remplie

    2

    La condition c) est remplie

    3

    La condition d) est remplie

    4

    (269)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    17.3.Conditions de terminaison

    (270)Une terminaison du service STI-C ne doit pas être envisagée.

    17.3.1.Annulation

    (271)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    17.3.2.Négation

    (272)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    17.4.Mise à jour

    (273)La procédure de mise à jour appropriée du DENM doit être déterminée sur la base des conditions suivantes:

    (a)au moins une des conditions mentionnées au point (266) est remplie après le Minimum Detection Interval spécifié à la section 17.2.2;

    (b)la validityDuration de l’ancien DENM n’a pas expiré;

    (c)ni la valeur de l’élément de données DeltaLatitude ni celle de l’élément de données DeltaLongitude, représentant la distance entre l’événement détecté actuel et l’ancien événement détecté, ne dépasse le seuil qui peut être couvert par les éléments de données DeltaLatitude et DeltaLongitude.

    (274)Si les conditions a), b) et c) telles que décrites au point (273) sont remplies, un DENM de mise à jour doit être généré. Les informations des anciens éléments de données du DENM (eventPosition, eventDeltaTime, informationQuality) doivent être conservées dans l’eventHistory en tant qu'eventPoint supplémentaire.

    Les points d’événement doivent être classés en ordre croissant en fonction de leur durée de vie, l’eventPoint le plus récent étant en première position. Les points d’événement de l’eventHistory présentant une durée de vie dépassant la validityDuration doivent être supprimés de l’eventHistory pour le DENM de mise à jour. Si la distance couverte par l’eventHistory dépasse le seuil autorisé par la sécurité, les points d’événement les plus anciens doivent être supprimés de l’eventHistory.

    Les informations relatives à l’événement détecté actuel doivent être attribuées aux champs de données DENM du DENM mis à jour.

    Remarque: il appartient au récepteur de gérer les points d’événement présentant une durée de vie dépassant la validityDuration après la génération du DENM de mise à jour.

    (275)Si les conditions a) et b) sont remplies, mais que la condition c) n’est pas remplie, aucun DENM de mise à jour ne doit être généré. À la place, un nouveau DENM supplémentaire doit être généré. Les informations relatives à l’événement détecté actuel doivent être attribuées aux champs de données DENM du nouveau DENM supplémentaire. L’ancien DENM doit continuer à être transmis tant que la repetitionDuration de l’ancien DENM n’expire pas.

    (276)Si la condition a) est remplie, mais que la condition b) n’est pas remplie, aucun DENM de mise à jour ne doit être généré, mais un nouveau DENM en fonction de l’événement détecté actuel doit être généré.

    Remarque: dans ce cas, la transmission de l’ancien DENM a déjà été interrompue, car la repetitionDuration de l’ancien DENM a expiré.

    (277)Si la condition a) n’est pas remplie, la génération d’un DENM de mise à jour n’est pas nécessaire.

    17.5.Durée de répétition et intervalle de répétition

    (278)Les DENM qui sont nouveaux ou ont été mis à jour doivent être répétés pendant une repetitionDuration de 180 secondes avec un repetitionInterval de 4 secondes. Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: la validityDuration est fixée à 300 secondes. Par conséquent, il est possible d'empêcher un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    17.6.Classe de trafic

    (279)Les DENM nouveaux et de mise à jour doivent être fixés à la classe de trafic 1.

    17.7.Paramètres du message

    17.7.1.DENM

    (280)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 35: Éléments de données du DENM «conditions météorologiques défavorables — précipitations»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. L'horodatage reflète le début de la détection du point d’événement actuel. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour et être fixé au moment de détection du point d’événement actuel.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM ou d'un DENM de mise à jour. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STIC.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour et être fixé à la position du point d’événement actuel.

    relevanceDistance

    ·Nouveau DENM: lessThan1000m(4)

    ·DENM de mise à jour: lessThan5km(5) (le recours à des mises à jour rend la distance couverte par l’eventHistory plus longue; pour atteindre toutes les stations STI pertinentes, la relevanceDistance est plus longue dans ce cas.)

    relevanceTrafficDirection

    allTrafficDirections(0)

    validityDuration

    300 secondes

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (268). Doit être rafraîchi pour chaque DENM de mise à jour et être fixé à l’informationQuality du point d’événement actuel.

    causeCode

    adverseWeatherCondition-Precipitation(19)

    subCauseCode

    unavailable(0), heavyRain(1) ou heavySnowfall(2)

    eventHistory

    Cet élément ne doit être utilisé que pour les DENM de mise à jour (voir section 17.4).

    Conteneur de localisation

    traces

    Le PathHistory de la station STI-C d’origine par rapport au point d’événement actuel.
    Doit être établi conformément à la norme [TS 102 894-2].
    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour et être fixé au roadType du point d’événement actuel.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    17.7.2.CAM

    (281)Une adaptation CAM ne doit pas être utilisée pour ce service STI-C.

    17.8.Couche de mise en réseau et de transport

    (282)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    17.9.Couche de sécurité

    (283)Si les conditions de déclenchement décrites au point (266) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux et de mise à jour pendant 15 minutes (à partir de la génération du nouveau DENM). Les DENM nouveaux et de mise à jour correspondants doivent être envoyés au moyen du même AT.

    (284)Si le AT change et en cas de transmission active d’un DENM nouveau ou de mise à jour, la transmission doit être interrompue. En outre, l’EventHistory et le PathHistory doivent être supprimés. Le processus de génération de DENM réguliers doit alors se poursuivre.

    18.Conditions météorologiques défavorables — perte de traction

    18.1.Description du service STI-C

    Ce service STI-C transmet des informations V2V concernant une route glissante pouvant affecter la conduite.

    (285)Un signal DENM ne doit être envoyé à la pile que si les conditions de déclenchement décrites dans la présente section sont considérées, après évaluation, comme valides. Un tel signal incite la pile à générer un DENM nouveau ou de mise à jour. Si les conditions de déclenchement ne sont pas remplies, un signal DENM ne doit pas être généré.

    18.2.Conditions de déclenchement

    18.2.1.Conditions préalables

    (286)Les conditions préalables suivantes doivent être remplies pour que ce service STI-C soit déclenché:

    (a)le levier de vitesses n’est pas sur la position marche arrière;

    (b)aucune erreur concernant le moteur, la transmission et le système de freinage n’est signalée.

    18.2.2.Conditions spécifiques au service

    (287)Si la condition préalable mentionnée au point (286) et au moins une des conditions suivantes sont remplies, les conditions de déclenchement pour ce service STI-C sont remplies et la génération d’un DENM doit être déclenchée:

    (1)sur la base d’une accélération positive:

    (a)sur la base de la régulation antipatinage (ASR), de la pédale d’accélérateur, de l’accélération du véhicule et de la vitesse du véhicule. Une demande d’ASR doit être active pendant au moins 200 millisecondes (comme pour les autres fonctions de sécurité dépendant de l’ASR). La pédale d’accélérateur est enfoncée en moyenne plus de 30 % du temps pendant lequel l’intervention d’ASR est active. L’accélération du véhicule (accélération en fonction du signal de bus filtré du véhicule) est inférieure à 40 % de l’accélération du véhicule sur une surface présentant un coefficient de friction élevé [comme l'asphalte sec (µ typique = 0,85)] à la même vitesse de départ et pour la même manœuvre (afin de couvrir différentes configurations de conduite, par exemple le mode deux roues motrices ou quatre roues motrices, aucune valeur détaillée n’a été indiquée ici);

    (b)sur la base de l’ASR, de la pédale d’accélérateur, de l’accélération du véhicule et de la vitesse du véhicule. Une demande d’ASR doit être active pendant au moins 200 millisecondes. La pédale d’accélérateur est enfoncée en moyenne plus de 30 % du temps pendant lequel l’intervention d’ASR est active. L’accélération du véhicule (accélération en fonction du signal de bus filtré du véhicule) est inférieure à 20 % de l’accélération du véhicule sur une surface présentant un coefficient de friction élevé [comme l'asphalte sec (µ typique = 0,85)] à la même vitesse de départ et pour la même manœuvre;

    (c)sur la base de l’ASR, de la pédale d’accélérateur, de l’accélération du véhicule et de la vitesse du véhicule. Une demande d’ASR doit être active pendant au moins 200 millisecondes. La pédale d’accélérateur est enfoncée en moyenne plus de 30 % du temps pendant lequel l’intervention d’ASR est active. L’accélération du véhicule (accélération en fonction du signal de bus filtré du véhicule) est inférieure à 10 % de l’accélération du véhicule sur une surface présentant un coefficient de friction élevé [comme l'asphalte sec (µ typique = 0,85)] à la même vitesse de départ et pour la même manœuvre;

    (d)sur la base de l’ASR et de la pédale d’accélérateur. Une demande d’ASR doit être active pendant au moins 200 millisecondes. La pédale d’accélérateur est enfoncée en moyenne moins de 30 % du temps pendant lequel l’intervention de l’ASR est active (pour éviter une intervention de l’ASR sur une surface présentant une valeur de friction élevée);

    (2)sur la base d’une accélération négative (décélération):

    (a)sur la base du système antiblocage (ABS), de la pression de freinage et de la décélération. L’intervention de l’ABS est active pendant plus de 200 millisecondes (en fonction d’autres fonctions de sécurité dépendant de l’ABS). La pression de freinage est supérieure à 20 % de la pression de freinage maximale utile. La décélération du véhicule (décélération en fonction du signal de bus filtré du véhicule) est inférieure à 50 % de la décélération du véhicule sur une surface présentant un coefficient de friction élevé [comme l'asphalte sec (µ typique = 0,85)] à la même vitesse de départ et pour la même manœuvre;

    (b)sur la base de l’ABS, de la pression de freinage et de la décélération. L’intervention de l’ABS est active pendant plus de 200 millisecondes. La pression de freinage est supérieure à 20 % de la pression de freinage maximale utile. La décélération du véhicule (décélération en fonction du signal de bus filtré du véhicule) est inférieure à 25 % de la décélération du véhicule sur une surface présentant un coefficient de friction élevé [comme l'asphalte sec (µ typique = 0,85)] à la même vitesse de départ et pour la même manœuvre;

    (c)sur la base de l’ABS, de la pression de freinage et de la décélération. L’intervention de l’ABS est active pendant plus de 200 millisecondes. La pression de freinage est supérieure à 20 % (pour éviter une intervention de l’ABS sur une surface présentant une valeur de friction élevée) de la pression de freinage maximale utile. La décélération du véhicule (décélération en fonction du signal de bus filtré du véhicule) est inférieure à 10 % de la décélération du véhicule sur une surface présentant un coefficient de friction élevé [comme l'asphalte sec (µ typique = 0,85)] à la même vitesse de départ et pour la même manœuvre;

    (d)sur la base de l’ABS et de la pression de freinage. L’intervention de l’ABS est active pendant plus de 200 millisecondes. La pression de freinage est inférieure à 20 % de la pression de freinage maximale utile;

    (3)sur la base de l’estimation du coefficient de friction:

    (a)le coefficient de friction est inférieur à 0,3 pendant au moins 5 secondes (le coefficient de friction de la glace est inférieur à 0,2; pour la neige et les gravillons, il est d’environ 0,4. Le coefficient de friction doit être détecté pendant une période donnée);

    (b)le coefficient de friction est inférieur à 0,2 pendant au moins 5 secondes.

    (288)Si les conditions 1a à 1c ou 2a à 2c sont considérées, après évaluation, comme valides, l’accélération/la décélération du véhicule doit être déterminée par le signal de bus du véhicule et non par l’analyse GNSS.

    (289)Un DENM nouveau ou de mise à jour ne doit pas être généré dans le Detection Blocking Time. Le Detection Blocking Time est lancé après la détection de l’événement et le déclenchement d’un DENM à cet effet. De cette façon, un seul événement ne peut pas déclencher une série de DENM. Pour l’estimation du coefficient de friction (conditions 3a et 3b), le Detection Blocking Time doit s’élever à 15 secondes. Pour les autres conditions, le Detection Blocking Time doit s’élever à 20 secondes.

    (290)Afin de garantir un comportement fonctionnel cohérent pour les conditions de déclenchement a) à d) et le Detection Blocking Time, le Minimum Detection Interval entre deux événements détectés doit être de 20 secondes.

    18.2.3.Qualité des informations

    (291)La valeur de l’élément de données (DE) informationQuality dans le DENM dépend de la façon dont l’événement est détecté [voir point (287)]. La valeur informationQuality doit être établie conformément au tableau suivant (il convient d’utiliser la valeur la plus élevée possible):

    Tableau 36: Qualité des informations relatives au service «conditions météorologiques défavorables — perte de traction»

    Détection de l’événement

    Valeur du DE informationQuality

    Aucune mise en œuvre conforme à une TRCO

    inconnue(0)

    La condition 1a ou la condition 2a est remplie

    1

    La condition 1b est remplie

    2

    La condition 1c ou 2b est remplie

    3

    La condition 2c est remplie

    4

    La condition 1d ou 2d est remplie

    5

    La condition 3a est remplie

    6

    La condition 3b est remplie

    7

    (292)Si les conditions de déclenchement changent entre deux mises à jour, le DE informationQuality ne doit pas être modifié avant la prochaine mise à jour. Si les conditions modifiées sont toujours remplies pendant la mise à jour du DENM, le DE informationQuality doit être mis à jour.

    18.3.Conditions de terminaison

    (293)Une terminaison du service STI-C ne doit pas être envisagée.

    18.3.1.Annulation

    (294)Un DENM d’annulation ne doit pas être utilisé pour ce service STI-C.

    18.3.2.Négation

    (295)Un DENM de négation ne doit pas être utilisé pour ce service STI-C.

    18.4.Mise à jour

    (296)La procédure de mise à jour appropriée du DENM doit être déterminée sur la base des conditions suivantes:

    (a)au moins une des conditions mentionnées au point (287) est remplie après le Minimum Detection Interval spécifié à la section 18.2.2;

    (b)la validityDuration de l’ancien DENM n’a pas expiré;

    (c)ni la valeur de l’élément de données DeltaLatitude ni celle de l’élément de données DeltaLongitude, représentant la distance entre l’événement détecté actuel et l’ancien événement détecté, ne dépasse le seuil qui peut être couvert par les éléments de données DeltaLatitude et DeltaLongitude.

    (297)Si les conditions a), b) et c) telles que décrites au point (296) sont remplies, un DENM de mise à jour doit être généré. Les informations des anciens éléments de données du DENM (eventPosition, eventDeltaTime, informationQuality) doivent être conservées dans l’eventHistory en tant qu'eventPoint supplémentaire.

    Les points d’événement doivent être classés en ordre croissant en fonction de leur durée de vie, l’eventPoint le plus récent étant en première position. Les points d’événement de l’eventHistory présentant une durée de vie dépassant la validityDuration [voir point (303)] doivent être supprimés de l’eventHistory pour le DENM de mise à jour. Si la distance couverte par l’eventHistory dépasse le seuil autorisé par la sécurité, les points d’événement les plus anciens doivent être supprimés de l’eventHistory.

    Les informations relatives à l’événement détecté actuel doivent être attribuées aux champs de données DENM du DENM mis à jour.

    Remarque: il appartient au récepteur de gérer les points d’événement présentant une durée de vie dépassant la validityDuration après la génération du DENM de mise à jour.

    (298)Si les conditions a) et b) sont remplies, mais que la condition c) n’est pas remplie, aucun DENM de mise à jour ne doit être généré. À la place, un nouveau DENM supplémentaire doit être généré. Les informations relatives à l’événement détecté actuel doivent être attribuées aux champs de données DENM du nouveau DENM supplémentaire. L’ancien DENM doit continuer à être transmis tant que la repetitionDuration de l’ancien DENM n’expire pas.

    (299)Si la condition a) est remplie, mais que la condition b) n’est pas remplie, aucun DENM de mise à jour ne doit être généré, mais un nouveau DENM en fonction de l’événement détecté actuel doit être généré.

    Remarque: dans ce cas, la transmission de l’ancien DENM a déjà été interrompue, car la repetitionDuration de l’ancien DENM a expiré.

    (300)Si la condition a) n’est pas remplie, la génération d’un DENM de mise à jour n’est pas nécessaire.

    18.5.Durée de répétition et intervalle de répétition

    (301)Par défaut, les DENM qui sont nouveaux ou ont été mis à jour doivent être répétés pendant une repetitionDuration de 300 secondes avec un repetitionInterval de 1 seconde.

    Toutefois, si le DENM est déclenché dans une zone urbaine, tel que déterminé par une carte numérique ou un algorithme de capteur embarqué, il doit être répété pendant une repetitionDuration de 180 secondes avec un repetitionInterval de 4 secondes.

    Par conséquent, les paramètres d’interface Durée de répétition et Intervalle de répétition entre l’application et le service de base DEN doivent être établis en fonction des valeurs ci-dessus.

    Remarque: la validityDuration est établie à 600 secondes ou 300 secondes, respectivement. Par conséquent, il est possible d'empêcher un intervalle entre les DENM si la repetitionDuration du DENM d’origine a expiré et la mise à jour n’a pas encore été reçue.

    Remarque: lorsque deux DENM présentant un même causeCode proviennent de la même station STI-C, le cas doit être géré par la station STI-C réceptrice.

    18.6.Classe de trafic

    (302)Les DENM nouveaux et de mise à jour doivent être fixés à la classe de trafic 1.

    18.7.Paramètres du message

    18.7.1.DENM

    (303)Le tableau suivant précise les éléments de données du DENM devant être établis.

    Tableau 37: Éléments de données du DENM «conditions météorologiques défavorables — perte de traction»

    Champ de données

    Valeur

    Conteneur de gestion

    actionID

    Identificateur d’un DENM. Doit être établi conformément à la norme [TS 102 894-2].

    detectionTime

    TimestampIts- Horodatage correspondant à la détection de l’événement par la station STI-C d’origine. L'horodatage reflète le début de la détection du point d’événement actuel. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour et être fixé au moment de détection du point d’événement actuel.

    referenceTime

    TimestampIts- Horodatage correspondant à la génération d'un nouveau DENM ou d'un DENM de mise à jour. Doit être établi conformément à la norme [TS 102 894-2].

    termination

    Ne doit pas être établi, car ni la négation ni l’annulation ne sont à utiliser dans le cadre de ce service STIC.

    eventPosition

    ReferencePosition. Doit être établi conformément à la norme [TS 102 894-2].

    Doit être rafraîchi pour un DENM de mise à jour et être fixé à la position du point d’événement actuel.

    relevanceDistance

    ·DENM nouveau: lessThan1000m(4)

    ·DENM de mise à jour: lessThan5km(5) (le recours à des mises à jour rend la distance couverte par l’eventHistory plus longue; pour atteindre toutes les stations STI pertinentes, la relevanceDistance est plus longue dans ce cas.)

    relevanceTrafficDirection

    allTrafficDirections(0)

    validityDuration

    Par défaut: 600 secondes

    Dans les zones urbaines, tel que déterminé par une carte numérique ou un algorithme de capteur embarqué: 300 secondes (si le véhicule ne dispose pas d’informations indiquant s’il se trouve dans une zone urbaine/non urbaine, la valeur par défaut doit être utilisée).

    stationType

    Le type de la station STI-C d’origine. Doit être établi conformément à la norme [TS 102 894-2].

    Conteneur de situation

    informationQuality

    Voir point (291). Doit être rafraîchi pour chaque DENM de mise à jour et être fixé à l’informationQuality du point d’événement actuel.

    causeCode

    adverseWeatherCondition-Adhesion(6)

    subCauseCode

    unavailable(0)

    eventHistory

    Cet élément ne doit être utilisé que pour les DENM de mise à jour (voir section 18.4).

    Conteneur de localisation

    traces

    Le PathHistory de la station STI-C d’origine par rapport au point d’événement actuel.
    Doit être établi conformément à la norme [TS 102 894-2].
    Doit être rafraîchi pour un DENM de mise à jour.

    roadType

    RoadType (type de route) de la route sur laquelle la station STI-C de détection est située.

    Doit être rafraîchi pour un DENM de mise à jour et être fixé au roadType du point d’événement actuel.

    Doit être établi conformément à la norme [TS 102 894-2] en association avec les règles suivantes:

    Urbain/non urbain

    Séparation structurelle

    Élément de données

    Urbain

    Non

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Urbain

    Oui

    urban-WithStructuralSeparation ToOppositeLanes(1)

    Urbain

    Inconnu

    urban-NoStructuralSeparation ToOppositeLanes(0)

    Non urbain

    Non

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Non urbain

    Oui

    nonUrban-WithStructuralSeparation ToOppositeLanes(3)

    Non urbain

    Inconnu

    nonUrban-NoStructuralSeparation ToOppositeLanes(2)

    Si les informations relatives à l’état urbain/non urbain ne peuvent être déterminées, l’élément de données doit être omis.

    18.7.2.CAM

    (304)Une adaptation CAM ne doit pas être utilisée pour ce service STI-C.

    18.8.Couche de mise en réseau et de transport

    (305)Le paramètre d’interface zone de destination du DENM entre le service de base DEN et la couche de mise en réseau et de transport doit correspondre à une forme circulaire dont le rayon est égal à la distance relevanceDistance.

    18.9.Couche de sécurité

    (306)Si les conditions de déclenchement décrites au point (287) s’appliquent, un changement de AT doit être bloqué pour les DENM nouveaux et de mise à jour pendant 15 minutes (à partir de la génération du nouveau DENM). Les DENM nouveaux et de mise à jour correspondants doivent être envoyés au moyen du même AT.

    (307)Si le AT change et en cas de transmission active d’un DENM nouveau ou de mise à jour, la transmission doit être interrompue. En outre, l’EventHistory et le PathHistory doivent être supprimés. Le processus de génération de DENM réguliers doit alors se poursuivre.

    19.Signalisation à bord des véhicules — informations dynamiques sur les limitations de vitesse

    Ce service STI-C transmet en continu des informations I2V (en utilisant des IVI) sur les limitations de vitesse en vigueur, par segment, voie ou catégorie de véhicule, telles que définies et distribuées par l’exploitant du réseau routier.

    (308)Les informations doivent être cohérentes avec les panneaux de signalisation dynamiques en vigueur.

    (309)[ISO/TS 14823] Le champ de données doit être défini comme suit: serviceCategoryCode = réglementaire, nature = 5, serialnumber = 57, attributes/spe/spm = valeur de la limitation de vitesse en km/h et unit = 0 (soit kmperh) ou l’équivalent pour les autres pays (par exemple 1 pour milesperh).

    (310)En ce qui concerne la fin de la limitation de vitesse, on peut utiliser ce qui suit: [ISO/TS 14823] Champ de données comme suit: serviceCategoryCode = réglementaire (12), nature = 6, serialnumber = 14 (avis de fin de limitation de vitesse) ou serviceCategoryCode = informatif (13), nature = 6, serialnumber = 63 (avis de fin de toutes les restrictions par panneaux électroniques) si ce panneau est placé sur la route. Les messages de fin peuvent être redondants, car le point final de la zone de pertinence du message IVI initial met déjà fin à la limitation de vitesse.

    20.Signalisation à bord des véhicules — «Texte libre» VMS intégré

    Ce service STI-C transmet des informations d'infrastructure à véhicule (I2V) [en utilisant des informations d'infrastructure à véhicule (IVI)] sous forme de «texte libre», telles que définies et distribuées par l’exploitant du réseau routier. La priorité des messages de signalisation à bord des véhicules (IVS) envoyés est définie par l’exploitant du réseau routier.

    (311)Les informations doivent être cohérentes avec les panneaux de signalisation dynamiques en vigueur.

    21.Signalisation à bord des véhicules — autres informations de signalisation

    Ce service STI-C transmet des informations de signalisation I2V (en utilisant des IVI) autres que les informations dynamiques sur les limitations de vitesse et sous forme de texte libre, par exemple les interdictions de dépassement ou les consignes sur les voies, telles que définies et distribuées par l’exploitant du réseau routier.

    (312)Les informations doivent être cohérentes avec les panneaux de signalisation dynamiques en vigueur.

    (313)[ISO/TS 14 823] Le champ de données est défini comme suit: serviceCategoryCode = informatif; nature = 6; serialnumber = 59 (pour voie fermée), 60 (pour voie libre), 61 (pour voie libre à gauche) ou 62 (pour voie libre à droite).

    (314)En ce qui concerne la «fin de la restriction»: serviceCategoryCode = informatif (13); nature = 6; serialnumber = 63 pour «fin de toutes les restrictions par panneaux électroniques» peut être utilisé si ce panneau électronique est affiché. Les messages de fin peuvent être redondants, car le point final de la zone de pertinence du message IVI initial met déjà fin aux informations de signalisation.

    22.Notification des endroits dangereux — zone d’accident

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant une zone d’accident, au moyen d’un identificateur unique de message d’avertissement, telles que définies et distribuées par l’exploitant du réseau routier.

    (315)Le causeCode doit être mis à 2 (accident) et le subCauseCode doit être mis à une valeur située entre 0 et 7 (sauf 6).

    23.Notification des endroits dangereux — embouteillage à l’avant

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant un embouteillage à l’avant, par segment ou voie, au moyen d’un identificateur unique de message d’avertissement, telles que définies et distribuées par l’exploitant du réseau routier (en mentionnant les positions, la longueur de l’embouteillage et le tronçon/les voies concerné(es), si ces informations sont disponibles).

    (316)Le causeCode doit être mis à 27 (fin de file dangereuse) et le subCauseCode doit être mis à 0 (non disponible) pour signaler une fin de file dangereuse. Pour transmettre des informations concernant l’ensemble de la longueur de la file, le causeCode doit être mis à 1 (encombrement de la circulation) et le subCauseCode doit être mis à 0.

    24.Notification des endroits dangereux — véhicule à l’arrêt

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant un véhicule à l’arrêt, au moyen d’un identificateur unique de message d’avertissement, telles que définies et distribuées par l’exploitant du réseau routier.

    (317)Le causeCode doit être mis à 94 (véhicule à l’arrêt) et le subCauseCode doit être mis à 0 (non disponible) ou à 2 (véhicule en panne).

    25.Notification des endroits dangereux — avertissement en cas de conditions météorologiques particulières

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant des précipitations, des conditions météorologiques extrêmes (scénario 1) ou de faibles distances de visibilité (scénario 3) actuel(le)s ou prévu(e)s, au moyen d’un identificateur unique de message d’avertissement, telles que définies et distribuées par l’exploitant du réseau routier.

    (318)Le causeCode doit être mis à 17 (conditions météorologiques extrêmes) ou à 19 (précipitations).

    26.Notification des endroits dangereux — route temporairement glissante

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant des tronçons de route glissants, au moyen d’un identificateur unique de message d’avertissement, telles que définies et distribuées par l’exploitant du réseau routier.

    (319)Le causeCode doit être mis à 6 (adhérence) et le subCauseCode doit être mis à une valeur située entre 0 et 9.

    27.Notification des endroits dangereux — animal ou personne sur la route

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant des animaux ou des personnes se trouvant sur la route, au moyen d’un identificateur unique de message d’avertissement, telles que définies et distribuées par l’exploitant du réseau routier.

    (320)Le causeCode doit être mis à 11 (animal sur la route) ou à 12 (présence humaine sur la route).

    28.Notification des endroits dangereux — obstacle sur la route

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant un ou plusieurs obstacle(s) présent(s) sur une ou plusieurs voie(s). Toutefois, la circulation est toujours possible (pas de blocage). Ce service utilise un identificateur unique de message d’avertissement, tel que défini et distribué par l’exploitant du réseau routier.

    (321)Le causeCode doit être mis à 10 (obstacle sur la route) et le subCauseCode doit être mis à une valeur située entre 0 et 5 (6 et 7 n’étant pas utilisés).

    29.Avertissement en cas de travaux routiers — fermeture de voie (et autres restrictions)

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant la fermeture d’une partie d’une voie, d’une voie entière ou de plusieurs voies (y compris la bande d’arrêt d’urgence) sans fermeture complète de la route. Ce service utilise un identificateur unique de message d’avertissement, tel que défini et distribué par l’exploitant du réseau routier.

    Pour la fourniture de ce service, l’une des approches suivantes est possible:

    ·travaux routiers statiques planifiés [déclenchement du centre d’opérations du trafic (TOC)] – l’exploitant du réseau routier programme des travaux routiers statiques et planifiés (ou ad hoc) dans son système de gestion du trafic (TMS);

    ·mode autonome – une remorque est utilisée pour des travaux routiers à court ou à long terme, mais sans connexion avec le TOC (aucune connexion disponible);

    ·mode augmenté (mode autonome suivi d’un déclenchement du TOC) – le message est d’abord envoyé depuis une remorque et peut être mis à jour ultérieurement, y compris avec des détails supplémentaires du TOC.

    (322)Le causeCode doit être mis à 3 (travaux routiers) et le subCauseCode doit être mis à 0 ou à 4.

    30.Avertissement en cas de travaux routiers — fermeture de route

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant une fermeture de route due à une série de travaux routiers statiques. La fermeture est temporaire. Ce service utilise un identificateur unique de message d’avertissement, tel que défini et distribué par l’exploitant du réseau routier.

    (323)Le causeCode doit être mis à 3 (travaux routiers) et le subCauseCode doit être mis à 1.

    31.Avertissement en cas de travaux routiers — travaux routiers (mobiles)

    Ce service STI-C transmet des informations I2V (en utilisant une DEN) concernant une zone routière dans laquelle, à un moment donné, une voie est rétrécie ou fermée (sans fermeture de la route), en raison de la prévision d’un chantier mobile. Ce service utilise un identificateur unique de message d’avertissement, tel que défini et distribué par l’exploitant du réseau routier.

    Pour la fourniture de ce service STI-C, l’une des approches suivantes est possible:

    ·déclenchement du TOC – l’exploitant du réseau routier programme des travaux routiers mobiles et planifiés (ou ad hoc) dans son TMS. Les informations contiennent tous les éléments pouvant être utilisés pour déterminer la zone de travaux (position de début/fin, durée). Les agents d’exécution n’utiliseront pas l’ensemble de la zone, mais marqueront la zone de travaux effective au sein de celle-ci. Des informations supplémentaires, telles que la limitation de vitesse dans chaque tronçon rétréci, peuvent être ajoutées;

    ·mode autonome – une remorque est utilisée pour des travaux routiers à court ou à long terme, mais sans connexion avec le TOC (aucune connexion disponible);

    (324)Le causeCode doit être mis à 3 (travaux routiers) et le subCauseCode doit être mis à 3.

    32.Intersections équipées de feux de signalisation — vitesse d’approche optimale recommandée pour le passage au feu vert

    Ce service STI-C transmet des informations I2V, en utilisant des messages Signal Phase and Timing (SPAT) et des informations topologiques pour l’intersection (MAP), concernant la vitesse optimale recommandée aux usagers de la route à l'approche et au passage des intersections équipées de feux de circulation, sur la base de l’état de phase actuel et des prévisions en matière de minutage des feux de circulation, ainsi que de la topologie routière de la ou des intersections(s) à l’avant.

    Pour la fourniture de ce service, l’une des approches suivantes est possible:

    ·le véhicule calcule la vitesse optimale recommandée – l’intersection équipée de feux de signalisation transmet l’état de phase actuel des feux de circulation ainsi que le minutage des changements de phase à venir périodiquement et en temps réel. Le véhicule en approche, lequel connaît sa propre position et sa propre vitesse, reçoit les messages et calcule la vitesse optimale d’approche de l’intersection;

    ·l’infrastructure calcule la vitesse optimale recommandée – l’intersection équipée de feux de signalisation calcule et transmet des informations relatives à la vitesse optimale recommandée d’approche de l’intersection périodiquement et en temps réel pour de multiples tronçons routiers proches de l’intersection. Le véhicule en approche, lequel connaît sa propre position et sa propre vitesse, reçoit les messages et extrait la vitesse optimale d’approche de l’intersection;

    ·informations sur la vitesse optimale recommandée pour une onde verte – une séquence d’intersections équipées de feux de circulation et synchronisées transmet des informations prédéfinies/planifiées sur la vitesse optimale pour une onde verte. Le véhicule en approche, lequel connaît sa propre position et sa propre vitesse, reçoit les messages et extrait la vitesse de l’onde verte pour franchir les intersections.

    (325)Les informations sur l’état de phase actuel et le minutage des changements de phase à venir transmises par l’intersection équipée de feux de signalisation doivent être suffisamment précises et fiables pour garantir des informations de haute qualité sur la vitesse optimale.

    (326)Les informations doivent concorder avec les signaux physiques de l’intersection.

    (327)Les conditions de circulation, telles que les files ou les embouteillages, affectent la validité des informations sur la vitesse optimale et doivent donc être prises en compte.

    (328)La vitesse optimale ne doit jamais dépasser la limitation de vitesse légale.

    33.Intersections équipées de feux de signalisation — octroi d’un statut de priorité aux transports publics

    Ce service STI-C donne la priorité aux véhicules de transport public plutôt qu’aux véhicules privés aux intersections équipées de feux de signalisation en utilisant des messages étendus de demande d’allumage de signal (SREM) et des messages étendus d’état des demandes d’allumage de signal (SSEM). Le véhicule de transport public transmet une demande d’octroi d’un statut de priorité au moyen d’un message V2I. Le système d’octroi d’un statut de priorité aux transports publics traite la demande, l’accepte ou la rejette, et envoie un retour d’informations au véhicule de transport public au moyen d’un message I2V. Si la demande est acceptée, par exemple si les «phases rouges» peuvent être raccourcies et les «phases vertes» prolongées, le véhicule de transport public reçoit un «feu vert» avec un retard minimum à la ligne d’arrêt. Après avoir franchi avec succès l’intersection, le fonctionnement du contrôleur de feux de circulation revient à la normale.

    (329)Le stationID du véhicule ne doit pas changer pendant le traitement d’une demande d’octroi d’un statut de priorité.

    (330)L’authentification et l’autorisation des véhicules de transport public doivent être assurées.

    (331)La demande d’octroi d’un statut de priorité doit être introduite à temps pour permettre au système d’octroi d’un statut de priorité aux transports publics de réagir.

    Top

    ANNEXE II

    1.Introduction

    1.1.Références

    Les références suivantes sont utilisées dans la présente annexe:

    EN 302 636-4-1    ETSI EN 302 636-4-1, «Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule - GeoNetworking (Réseautage géolocalisé) - Partie 4: Adressage géographique et transfert pour communications point-à-point et point-à-multipoint - Sous-partie 1: Fonctionnalité indépendante du support», V1.3.1 (2017-08)

    TS 102 894-2    ETSI TS 102 894-2, «Systèmes de transport intelligents (STI); Exigences liées aux utilisateurs et aux applications; Partie 2: dictionnaire de données commun pour les applications et la couche installations [Intelligent Transport Systems (ITS); Users and applications requirements; Part 2: Applications and facilities layer common data dictionary]», V1.3.1 (2018-08)

    ISO/TS 19091    ISO/TS 19091, «Systèmes intelligents de transport – Coopérative ITS – Utilisation de communications V2I et I2V pour des applications relatives aux intersections signalées», (2017-03)

    EN 302 663    ETSI EN 302 663, «Systèmes de transport intelligents (STI) - Spécification de couche d’accès pour systèmes de transport intelligents fonctionnant dans la bande de fréquence 5 GHz», V1.2.1 (2013-07)

    TS 102 687    ETSI TS 102 687, «Systèmes de transport intelligents (STI); Mécanismes de gestion décentralisée de l’encombrement pour les systèmes de transport intelligents fonctionnant dans la bande de fréquence 5 GHz; Partie relative à la couche d'accès [Intelligent Transport Systems (ITS); Decentralized Congestion Control Mechanisms for Intelligent Transport Systems operating in the 5 GHz range; Access layer part]», V1.2.1 (2018-04)

    TS 102 792    ETSI TS 102 792, «Systèmes de transport intelligents (STI); Techniques d'atténuation pour éviter toute interférence entre l'équipement européen CEN-DSRC (CEN - Communications spécialisées à courte portée) et les systèmes de transport intelligents (STI) fonctionnant dans la bande de fréquence 5 GHz [Intelligent Transport Systems (ITS); Mitigation techniques to avoid interference between European CEN Dedicated Short Range Communication (CEN DSRC) equipment and Intelligent Transport Systems (ITS) operating in the 5 GHz frequency range]», V1.2.1 (2015-06)

    EN 302 637-2    ETSI EN 302 637-2, «Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule - Ensemble d’applications de base - Partie 2: spécification du service de base de sensibilisation coopérative», V1.4.0 (2018-08); cette référence doit s’entendre comme une référence à la version 1.4.1 à compter de la date de publication de cette version.

    TS 102 724    ETSI TS 102 724, «Systèmes de transport intelligents (STI); Spécifications harmonisées en matière de canal pour les systèmes de transport intelligents fonctionnant dans la bande de fréquence 5 GHz [Intelligent Transport Systems (ITS); Harmonized Channel Specifications for Intelligent Transport Systems operating in the 5 GHz frequency band]», V1.1.1 (2012-10)

    EN 302 636-5-1    ETSI EN 302 636-5-1, «Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule - GeoNetworking (Réseautage géolocalisé) - Partie 5: Protocoles de transport - Sous-partie 1: Protocole de transport de base», V2.1.1 (2017-08)

    TS 103 248    ETSI TS 103 248, «Systèmes de transport intelligents (STI); GeoNetworking (Réseautage géolocalisé); Numéros de port pour le protocole de transport de base (BTP) [Intelligent Transport Systems (ITS); GeoNetworking; Port Numbers for the Basic Transport Protocol (BTP)]», V1.2.1 (2018-08)

    EN 302 931    ETSI EN 302 931, «Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule - Définition de la zone géographique», V1.1.1 (2011-7)

    EN 302 637-3    ETSI EN 302 637-3, «Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule - Ensemble d’applications de base - Partie 3: spécifications du service de base de notification environnementale décentralisée», V1.3.0 (2018-08); cette référence doit s’entendre comme une référence à la version 1.3.1 à compter de la date de publication de cette version.

    TS 102 636-4-2    ETSI TS 102 636-4-2, «Systèmes de transport intelligents (STI); Communications de véhicule à véhicule; GeoNetworking (Réseautage géolocalisé); Partie 4: Adressage géographique et transfert pour communications point-à-point et point-à-multipoint; Sous-partie 2: Fonctionnalités dépendantes du support pour l'ITS-G5 [Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Sub-part 2: Media-dependent functionalities for ITS-G5]», V1.1.1 (2013-10)

    SAE J2945/1    SAE J2945/1, «Prescriptions applicables au système embarqué pour les communications de véhicule à véhicule en matière de sécurité (On-board System Requirements for V2V Safety Communications)», (2016-03)

    TS 103 097    ETSI TS 103 097, «Systèmes de transport intelligents (STI); Sûreté; Formats du certificat et de l'en-tête de sûreté [Intelligent Transport Systems (ITS); Security; Security Header and Certificate Formats]», V1.3.1 (2017-10)

    ISO 8855    ISO 8855, «Véhicules routiers — Dynamique des véhicules et tenue de route — Vocabulaire», (2011-12)

    TS 103 301    ETSI TS 103 301, «Systèmes de transport intelligents (STI); Communications de véhicule à véhicule; Ensemble d'applications de base; Protocoles de couche installations et exigences en matière de communication pour les services d’infrastructure [Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services]», V1.2.1 (2018-08)

    TS 103 175    ETSI TS 103 175, «Systèmes de transport intelligents (STI); Entité chargée de la DCC inter-couches pour l'exploitation dans le support ITS-G5A et ITS-G5B [Intelligent Transport Systems (ITS); Cross Layer DCC Management Entity for operation in the ITS G5A and ITS G5B medium]», V1.1.1 (2015-06)

    ISO/TS 19321    ISO/TS 19321, «Systèmes intelligents de transport — Coopérative STI — Dictionnaire de structures de données d’informations dans les véhicules (IVI)», (2015-04-15)

    ISO 3166-1    ISO 3166-1 :2013, «Codes pour la représentation des noms de pays et de leurs subdivisions – Partie 1: Codes de pays»

    ISO 14816    ISO 14816:2005, «Télématique du transport routier et de la circulation routière -- Identification automatique des véhicules et des équipements -- Codification et structure des données»

    ISO/TS 14823    ISO/TS 14823:2017, «Systèmes de transport intelligents -- Dictionnaire de données graphiques»

    IEEE 802.11    IEEE 802.11-2016, «Norme IEEE pour les technologies de l’information — Télécommunications et échange de données entre systèmes, réseaux locaux ou métropolitains — Spécifications, Partie 11: Spécifications relatives à la sous-couche commande d’accès au support (MAC) et à la couche physique (PHY) pour les réseaux locaux sans fil (WLAN) [IEEE Standard for Information technology — Telecommunications and information exchange between systems, local and metropolitan area networks — Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications]», (2016-12-14)

    1.2.Notations et abréviations

    Les notations et abréviations qui suivent apparaissent dans la présente annexe.

    AT    Ticket d’autorisation («Authorization Ticket»)

    BTP    Protocole de transport de base («Basic Transport Protocol»)

    CA    Sensibilisation coopérative («Cooperative Awareness»)

    CAM    Message de sensibilisation coopérative («Cooperative Awareness Message»)

    CBR    Taux d’occupation de canal («Channel Busy Ratio»)

    CCH    Canal de commande («Control Channel»)

    CDD    Dictionnaire de données commun («Common Data Dictionary»)

    CEN-DSRC    Comité européen de normalisation (CEN) - Communications spécialisées à courte portée [«European Committee for Standardisation (CEN)- Dedicated Short Range Communication»]

    STI-C    Systèmes de transport intelligents coopératifs («Cooperative Intelligent Transport Systems»)

    DCC    Gestion décentralisée de l’encombrement («Decentralized Congestion Control»)

    DEN    Notification environnementale décentralisée («Decentralized Environmental Notification»)

    DENM    Message de notification environnementale décentralisée («Decentralized Environmental Notification Message»)

    DP    Profil de gestion décentralisée de l’encombrement («Decentralized Congestion Control Profile»)

    ETSI    Institut européen de normalisation des télécommunications («European Telecommunications Standards Institute»)

    GBC    Diffusion géographique («GeoBroadcast»)

    GN    Réseautage géolocalisé («GeoNetworking»)

    GNSS    Système mondial de radionavigation par satellite («Global Navigation Satellite System»)

    IEEE    Institut des ingénieurs électriciens et électroniciens («Institute of Electrical and Electronics Engineers»)

    IVI    Informations infrastructure à véhicule («Infrastructure to Vehicle Information»)

    IVIM    Message d’information infrastructure à véhicule («Infrastructure to Vehicle Information Message»)

    MAP    Informations topologiques pour l’intersection («Topology information for the intersection»)

    MAPEM    Message MAP étendu («MAP Extended Message»)

    NH    En-tête suivant («Next Header»)

    NTP    Protocole de synchronisation réseau («Network Time Protocol»)

    PAI    Indicateur de précision de position («Position Accuracy Indicator»)

    PoTi    Gestion de la position et du temps («Position and Time»)

    QPSK    Modulation par déplacement de phase quadrivalente («Quadrature Phase-Shift Keying»)

    RLT    Topologie de voie routière («Road Lane Topology»)

    RSU    Unité de bord de route («Road-side Unit»)

    SCF    Stocker, transporter et transférer («Store Carry Forward»)

    SHB    Diffusion à un seul bond («Single Hop Broadcast»)

    SPATEM    Message étendu concernant les phases et le minutage de signalisation («Signal Phase and Timing Extended Message»)

    SREM    Message étendu de demande d’allumage de signal («Signal Request Extended Message»)

    SSEM    Message étendu d’état de demande d’allumage de signal («Signal Request Status Extended Message»)

    TAI    Temps atomique international («International Atomic Time»)

    TAL    Niveau d’assurance de la confiance («Trust Assurance Level»)

    TLM    Manœuvre de feu de signalisation («Traffic Light Manoeuvre»)

    TC    Classe de trafic («Traffic Class»)

    UTC    Temps universel coordonné («Coordinated Universal Time»)

    WGS84    Système géodésique mondial de 84 («World Geodetic System 84»)

    1.3.Définitions

    Les définitions suivantes sont utilisées dans la présente annexe:

    (a)«heure STI-C» ou «base temporelle», le nombre de millisecondes TAI (temps atomique international) écoulées depuis 2004-01-01 00:00:00.000 UTC (temps universel coordonné)+0 tel que défini dans la norme [ETSI EN 302 636-4-1]. Les horodatages tels que définis dans la norme [ETSI TS 102 894-2] suivent ce format d’heure.

    Remarque: «millisecondes TAI», le nombre réel de millisecondes comptées et non altérées par des secondes intercalaires après le 1er janvier 2004.

    (b)«horloge de station», une horloge représentant l’heure des systèmes de transport intelligents coopératifs (STI-C) dans une station STI-C.

    2.Exigences pour les stations STI-C de véhicule conçues pour des communications à courte portée

    Ce profil de système spécifie un ensemble minimal de normes et comble les lacunes dans la mesure nécessaire à la réalisation d’une station STI-C de véhicule interopérable du côté émetteur. Ce profil ne comprend que les exigences en matière d’interopérabilité, en laissant la possibilité d’ajouter des exigences supplémentaires. Par conséquent, il ne décrit pas toutes les fonctionnalités de la station STI-C de véhicule.

    Ce profil de système rend possible le déploiement des services prioritaires (V2V notamment). Il peut prendre en charge d’autres services, mais ceux-ci peuvent requérir des spécifications système supplémentaires.

    Le profil fournit des descriptions, des définitions et des règles pour les couches (Applications, Installations, Mise en réseau et transport, et Accès) de l’architecture de référence de station STI de l’ETSI/STI-S hôte.

    2.1.Définitions

    Les définitions suivantes sont utilisées dans cette partie de l’annexe:

    (a)les «états du véhicule» comprennent la position absolue, le cap et la vitesse à un moment donné;

    (b)les informations fournies avec un «niveau de confiance» de 95 % signifient que la valeur réelle se situe dans la fourchette spécifiée par la valeur estimée plus/moins l’intervalle de confiance pour 95 % des points de données dans une base statistique donnée;

    (c)«obstruction du ciel», la fraction des valeurs d’hémisphère qui sont obstruées pour les satellites Galileo ou d’autres systèmes mondiaux de radionavigation par satellite (GNSS) en raison de la présence de montagnes, de bâtiments, d’arbres, etc.

    (d)«CEN-DSRC» (Comité européen de normalisation - Communications spécialisées à courte portée), une technologie des micro-ondes utilisée dans les systèmes de télépéage pour le financement des infrastructures routières ou pour la perception de redevances d’usage du réseau routier. Aux fins de la présente annexe, le terme «CEN-DSRC» couvre l’ensemble des technologies des micro-ondes de 5,8 GHz visées dans la directive 2004/52/CE du Parlement européen et du Conseil et dans la décision 2009/750/CE de la Commission.

    2.2.Définition des paramètres

    La définition des paramètres dans le tableau 1 est utilisée dans cette partie de l’annexe.

    Tableau 1: Définition des paramètres

    Paramètre

    Valeur

    Unité

    Description

    pAlDataRateCch

    6

    Mbit/s

    Débit de données par défaut pour le canal de commande (CCH)

    pAlDataRateCchHigh

    12

    Mbit/s

    Débit de données supérieur facultatif pour le CCH par rapport à celui par défaut

    pAlDataRateCchLow

    3

    Mbit/s

    Débit de données inférieur facultatif pour le CCH par rapport à celui par défaut

    pBtpCamPort

    2001

    s.o.

    Port de destination bien connu pour les CAM

    pBtpDenmPort

    2002

    s.o.

    Port de destination bien connu pour les DENM

    pBtpDestPortInfo

    0

    s.o.

    Valeur pour l’information de port de destination

    pCamGenNumber

    3

    s.o.

    Nombre de CAM consécutifs générés sans restrictions de temps

    pCamTraceMaxLength

    500

    m

    Longueur maximale d’une trace dans les CAM

    pCamTraceMinLength

    200

    m

    Longueur minimale d’une trace dans les CAM

    pCamTrafficClass

    2

    s.o.

    Valeur de la classe de trafic (TC) avec laquelle des CAM sont envoyés

    pDccCcaThresh

    -85

    dBm

    Sensibilité minimale du canal

    pDccMeasuringInterval

    100

    ms

    Valeur pour l’intervalle dans lequel la charge du canal est fournie

    pDccMinSensitivity

    -88

    dBm

    Valeur pour la sensibilité minimale du récepteur

    pDccProbingDuration

    8

    µs

    Valeur pour la durée de l’échantillon de sondage

    pDccPToll

    10

    dBm

    Valeur pour la puissance de transmission dans les zones protégées

    pDCCSensitivityMargin

    3

    dB

    Valeur pour la marge du paramètre pDccMinSensitivity

    pDenmTraceMaxLength

    1000

    m

    Longueur minimale d’une trace dans les DENM

    pDenmTraceMinLength

    600

    m

    Longueur minimale d’une trace dans les DENM

    pGnAddrConfMode

    ANONYMOUS(2)

    s.o.

    Méthode de configuration de l’adresse GeoNetworking (GN)

    pGnBtpNh

    2

    s.o.

    Valeur pour le champ Next Header (NH) de l’en-tête commun GN

    pGnChannelOffLoad

    0

    s.o.

    Valeur pour le champ Channel Offload

    pGnEtherType

    0x8947

    --

    Valeur pour l’EtherType à utiliser

    pGnGbcHtField

    4

    s.o.

    Valeur pour le champ HeaderType dans les cas de GeoBroadcast (GBC)

    pGnGbcScf

    1

    s.o.

    Valeur pour le champ store-carry-forward dans les cas de GBC

    pGnInterfaceType

    ITS-G5 (1)

    s.o.

    Type d’interface à utiliser par le GN

    pGnIsMobile

    1

    s.o.

    Définit si la station STI-C est mobile ou non

    pGnMaxAreaSize

    80

    km²

    Zone prise en charge à couvrir

    pGnSecurity

    ENABLED (1)

    s.o.

    Définit l’utilisation des en-têtes de sécurité GN

    pGnShbHstField

    0

    s.o.

    Valeur pour le champ HeaderSubType dans les cas de diffusion à un seul bond (SHB)

    pGnShbHtField

    5

    s.o.

    Valeur pour le champ HeaderType dans les cas de SHB

    pGnShbLifeTimeBase

    1

    s.o.

    Valeur pour le champ LifeTimeBase en cas de SHB

    pGnShbLifeTimeMultiplier

    1

    s.o.

    Valeur pour le champ LifeTimeMultiplier dans les cas de SHB

    pPotiMaxTimeDiff

    20

    ms

    Différence de temps maximale entre l’horloge de la station et la base temporelle

    pPotiWindowTime

    120

    s

    Taille de la fenêtre glissante de gestion de la position et du temps (PoTi) en secondes

    pPotiUpdateRate

    10

    Hz

    Rythme de mise à jour des informations relatives à la position et au temps

    pSecCamToleranceTime

    2

    s

    Écart de temps maximal entre le temps indiqué dans l’en-tête de sécurité du message de sensibilisation coopérative (CAM) et l’horloge de la station pour accepter le CAM

    pSecGnScc

    0

    s.o.

    Valeur pour le champ SCC de l’adresse GN

    pSecGnSourceAddressType

    0

    s.o.

    Valeur pour le champ M de l’adresse GN (type de configuration de l’adresse)

    pSecMaxAcceptDistance

    6

    km

    Distance maximale entre l’émetteur et le récepteur pour accepter les messages

    pSecMessageToleranceTime

    10

    min

    Écart de temps maximal entre le temps indiqué dans l’en-tête de sécurité du message (autre que CAM) et l’horloge de la station pour accepter le message

    pSecRestartDelay

    1

    min

    Délai de grâce pour le changement d'AT après le démarrage du terminal d’allumage

    pTraceAllowableError

    0,47

    m

    Paramètre pour le calcul de l’historique de cheminement; voir annexe A.5 de la norme [SAE J2945/1] pour plus de détails.

    pTraceDeltaPhi

    1

    °

    Paramètre pour le calcul de l’historique de cheminement; voir annexe A.5 de la norme [SAE J2945/1] pour plus de détails.

    pTraceEarthMeridian

    6 378,137

    km

    Rayon moyen de la Terre [selon l’Union géodésique et géophysique internationale (UGGI)] Utilisé pour le calcul des traces; voir annexe A.5 de la norme [SAE J2945/1] pour plus de détails.

    pTraceMaxDeltaDistance

    22,5

    m

    Paramètre pour le calcul des traces; voir annexe A.5 de la norme [SAE J2945/1] pour plus de détails.

    2.3.Sécurité

    (1)Une station STI-C de véhicule doit être reliée de manière sécurisée à un véhicule spécifique. Lorsque la station STI-C de véhicule est alimentée, elle doit vérifier qu’elle fonctionne dans le véhicule avec lequel elle a été reliée de manière sécurisée. Si cette condition de fonctionnement correct ne peut être vérifiée, la station STI-C doit être désactivée, de sorte qu’elle ne puisse plus envoyer de messages (c’est-à-dire que le niveau de transmission radio de la station STI-C, au moins, est désactivé).

    (2)La station STI-C de véhicule doit comparer l'horodatage dans l’en-tête de sécurité à l’heure de réception et n’accepter que les CAM dans le dernier temps de pSecCamToleranceTime et les autres messages dans le dernier temps de pSecMessageToleranceTime.

    (3)La station STI-C de véhicule doit contrôler la distance par rapport à la position de l’émetteur — dans l’en-tête de sécurité, si cette information y figure — et ne transmettre que les messages présentant une distance par rapport à l’émetteur égale ou inférieure à la pSecMaxAcceptDistance.

    (4)La vérification d’un message doit comprendre au moins une vérification cryptographique de la signature du message.

    (5)La station STI-C de véhicule ne doit transmettre que des messages ayant fait l’objet d’une vérification.

    (6)La station STI-C de véhicule doit utiliser un en-tête et une signature de sécurité de bout en bout par message conformément aux normes [TS 103 097] et [EN 302 636-4-1].

    (7)La signature doit être générée au moyen d’une clé privée correspondant à un AT valide conformément au paragraphe 7.2.1 de la norme [TS 103 097].

    (8)Toutes les adresses et tous les identificateurs transmis par des communications à courte portée doivent être modifiés lors du changement de l'AT.

    2.4.Gestion de la position et du temps

    (9)Les états du véhicule doivent être cohérents. Par conséquent, le cap et la vitesse doivent se référer au même moment que la position absolue (GenerationDeltaTime dans les CAM, par exemple).

    Remarque: toute imprécision pouvant résulter d’effets liés au temps devrait être prise en compte dans la précision des variables d’état.

    (10)La station STI-C de véhicule doit utiliser le système géodésique mondial de 84 (WGS84) comme système de coordonnées de référence, comme spécifié dans la norme [TS 102 894-2].

    Remarque: sur la base de la dérive de 2,5 cm/an en WGS84 du système européen de référence terrestre (ETRS89), lequel est fixé sur la plaque continentale européenne, il convient de noter que les stations STI-C de véhicule doivent savoir quel système de référencement est utilisé. Lorsqu’un système de référencement amélioré tel qu’un système amélioré de cinématique en temps réel est utilisé pour un géoréférencement de haute précision, il est possible que ce décalage doive être compensé.

    (11)Les informations relatives à l’altitude doivent être interprétées comme étant la hauteur au-dessus de l’ellipsoïde WGS84.

    Remarque: d’autres interprétations de l’altitude utilisant des définitions géoïdes (par exemple, par rapport au niveau moyen de la mer) ne doivent pas être utilisées.

    (12)Pour la position horizontale, on utilise une zone de confiance plutôt qu’un intervalle de confiance unique. La zone de confiance est décrite comme une ellipse délimitée par un grand axe, un petit axe et l’orientation du grand axe par rapport à la direction du Nord, tel que défini au point (10).

    (13)La station STI-C de véhicule doit interpréter le «cap» comme la direction du composant horizontal du vecteur de vitesse. Le point de départ du vecteur de vitesse doit être le point de référence de la station STI-C de véhicule, tel que défini au point B.19 «referencePosition» de la norme [EN 302 637-2].

    Remarque: d’autres interprétations du cap faisant référence à l’orientation de la carrosserie du véhicule ne doivent pas être utilisées.

    Remarque: cette définition implique que la conduite en marche arrière en ligne droite entraîne une différence de 180° entre le cap et l’orientation de la carrosserie du véhicule.

    (14)L’heure STI-C doit servir de base à tous les horodatages de tous les messages transmis par la station STI-C de véhicule dans tous les États membres de l’UE.

    (15)Lorsqu’elles sont actives, les stations STI-C doivent mettre à jour les états du véhicule à une fréquence au moins égale au pPotiUpdateRate.

    (16)Les horodatages des messages doivent être basés sur l’horloge de la station.

    (17)La différence entre l’horloge de la station et l’heure STI-C doit faire l’objet d’une estimation. Si la différence absolue | Heure de l’horloge de la station - Heure STI-C | est supérieure ou égale (>=) à la pPotiMaxTimeDiff, la station STI-C de véhicule ne doit pas être active.

    Remarque: un horodatage précis n’est pas seulement nécessaire pour la synchronisation de l’heure, mais implique également que les états du système sont valides à ce moment précis dans le temps, c’est-à-dire que les états du véhicule restent cohérents.

    (18)À l’arrêt, le système doit rapporter la dernière valeur de cap connue (direction de mouvement du véhicule). La valeur doit être déverrouillée lorsque le véhicule se remet en mouvement.

    2.5.Comportement du système

    (19)La station STI-C de véhicule doit exploiter le service de base de sensibilisation coopérative lorsque le véhicule concerné se trouve sur la voie publique et que sa dynamique de conduite est normale.

    Remarque: l’exploitation du service de base de sensibilisation coopérative comprend la transmission de CAM si toutes les conditions applicables à la génération de CAM sont remplies.

    (20)Les traces et les données de l’historique de cheminement ne doivent être générées que lorsque des informations de confiance relatives à la position du véhicule sont disponibles et que l’horloge de la station respecte les dispositions des points (90) et (91).

    (21)L’occupant d’un véhicule doit pouvoir désactiver facilement et à tout moment la station STI-C du véhicule concerné.

    (22)La station STI-C de véhicule doit traiter les transmissions de CAM de manière à ce qu’aucun message obsolète ne soit transmis même si la gestion de l’encombrement est appliquée.

    2.6.Couche d’accès

    (23)La station STI-C de véhicule doit utiliser le canal de commande G5-CCH comme indiqué dans le tableau 3 de la norme [EN 302 663] pour envoyer des messages à l’appui du service de base de sensibilisation coopérative et des services STI-C prioritaires énumérés à l’annexe I du présent règlement.

    (24)La couche d’accès de la station STI-C de véhicule doit être conforme à la norme [EN 302 663], à l’exception des limites d’émission et des paragraphes 4.2.1, 4.5 et 6.

    (25)La station STI-C de véhicule doit utiliser un débit de transfert par défaut de pAlDataRateCch sur le canal de commande.

    (26)La station STI-C de véhicule doit également prendre en charge les débits de transfert pAlDataRateCchLow et pAlDataRateCchHigh sur le canal de commande.

    (27)La couche d’accès de la station STI-C de véhicule doit être conforme à la norme [TS 102 724].

    (28)La station STI-C de véhicule doit prendre en charge les profils de gestion décentralisée de l’encombrement (DP) suivants définis dans la norme [TS 102 724]: DP0, DP1, DP2 et DP3.

    Ces profils de DCC doivent utiliser les valeurs d’identification de profil de DCC suivantes:

    ·DP0, utilisé uniquement pour les DENM présentant une TC = 0;    

    ·DP1, utilisé pour les DENM présentant une TC = 1;

    ·DP2, utilisé pour les CAM présentant une TC = pCamTrafficClass;

    ·DP3, utilisé pour les DENM transmis et les autres messages de faible priorité.

    (29)Le mécanisme de DCC de la station STI-C de véhicule doit être conforme à la norme [TS 102 687].

    (30)Les paramètres du tableau A.2 de la norme [TS 102 687] doivent être utilisés si l’algorithme de DCC réactif décrit au paragraphe 5.3 de la norme [TS 102 687] est mis en œuvre.

    Remarque: le tableau A.2 de la norme [TS 102 687] est basé sur la diffusion de CAM et de messages de notification environnementale décentralisée (DENM) pour les services STI-C prioritaires avec une Ton (durée de transmission) de 500 μs en moyenne.

    (31)La fonction de lissage suivante des valeurs du taux d’occupation de canal (CBR) doit être exécutée si la station STI-C de véhicule utilise l’algorithme de DCC réactif décrit au paragraphe 5.3 de la norme [TS 102 687]: CBR_now = (CBR(n)+CBR(n-1))/2 (

    Remarque: «n» et «n-1» sont respectivement la période d’échantillonnage CBR actuelle et précédente).

    (32)La station STI-C de véhicule doit pouvoir, au minimum, générer et transmettre le nombre de messages déterminé par la valeur du taux de génération de CAM le plus élevé (soit 10 Hz) et, si des algorithmes de détection sont utilisés, ce nombre doit être augmenté du taux de génération de DENM minimal requis dérivé de ces conditions de déclenchement.

    (33)Si elle utilise l’algorithme de DCC réactif décrit au paragraphe 5.3 de la norme [TS 102 687], la station STI-C de véhicule doit respecter les taux de messages maximaux suivants:

    ·pour l’état au repos: la somme de tous les messages envoyés sur les DP1, DP2 et DP3 ne doit pas dépasser Rmax_relaxed = 16,7 messages par seconde. Les messages en rafale sont autorisés pour le DP0 avec RBurst = 20 messages par seconde, avec une durée maximale de TBurst = 1 seconde, et ne peuvent avoir lieu que toutes les TBurstPeriod = 10 secondes. Ainsi, en ajoutant les messages DP0, le taux maximal de messages est de Rmax_relaxed = 36,7 messages par seconde;

    ·pour les états actifs: le taux maximal de messages pour chaque état est indiqué dans le tableau A.2 de la norme [TS 102 687];

    ·pour l’état restrictif: le taux maximal de messages par station STI-C de véhicule est fixé à 2,2 messages par seconde, c’est-à-dire l’inverse de TTX_MAX = 460 ms.

    (34)La station STI-C de véhicule doit prendre en charge le contrôle de la puissance d’émission par paquet.

    Remarque: la PTx peut dépendre de l’état de DCC actuel (c’est-à-dire au repos, actif ou restrictif) et du profil de DCC (soit DP0, DP1, etc.).

    (35)La station STI-C de véhicule doit réduire sa puissance d’émission à PToll = pDccPToll dès que la zone protégée est pénétrée et sans modifier tout autre paramètre de transmission de DCC conformément au tableau A.2 de la norme [TS 102 687]. Les messages DP0 sont exclus de cette restriction.

    (36)Lorsque la station STI-C de véhicule n’est pas équipée d’un détecteur radio CEN-DSRC tel que décrit au paragraphe 5.2.5 de la norme [TS 102 792], elle doit tenir à jour une liste des positions des zones protégées telles que décrites au paragraphe 5.5.1 de la norme [TS 102 792]. Cette liste doit être composée:

    ·d’un ensemble de zones protégées telles qu’énumérées dans la «dernière version» (disponible au moment du développement du véhicule) de la base de données des zones protégées. La station STI-C de véhicule peut inclure des mécanismes de mise à jour de la base de données;

    ·d'un ensemble de zones protégées telles qu’identifiées par la réception de CAM d’atténuation CEN-DSRC comme décrit aux paragraphes 5.2.5 et 5.2.2.3 de la norme [TS 102 792];

    ·d'une zone temporairement protégée telle qu’identifiée par la réception de CAM d’atténuation CEN-DSRC comme décrit au paragraphe 5.2.2.2 de la norme [TS 102 792].

    (37)Lorsque la station STI-C de véhicule est équipée d’un détecteur radio CEN-DSRC, l’atténuation doit être appliquée comme décrit au paragraphe 5.2.5 de la norme [TS 102 792] et la station STI-C de véhicule doit générer des CAM conformément au paragraphe 5.5.1 de la norme [TS 102 792].

    (38)Lorsque la station STI-C de véhicule n’est pas équipée d’un détecteur radio CEN-DSRC, l’atténuation doit être appliquée conformément à la norme [TS 102 792] sur la base de la liste définie au point (36) et des CAM reçus d’autres usagers de la route qui ont mis en œuvre le point (37).

    Remarque: clarification du paragraphe 5.2.5 de la norme [TS 102 792]: une station STI mobile devrait systématiquement appliquer une atténuation jusqu’à la position centrale de la gare de péage la plus proche. Lorsque plusieurs positions sont données dans la même zone, la station STI mobile doit répondre à chaque position centrale, éventuellement dans une séquence. Les zones protégées présentant un protectedZoneID identique peuvent être considérées comme une station unique. Lorsque la base de données des zones protégées et les CAM d’atténuation CEN-DSRC contiennent une zone protégée valide présentant le protectedZoneID identique, l’atténuation doit uniquement être basée sur le contenu des CAM d’atténuation CEN-DSRC.

    2.7.Couche de mise en réseau et de transport

    (39)La partie indépendante du support de la station STI-C de véhicule de GeoNetworking (GN) doit être conforme à la norme [EN 302 636-4-1].

    (40)Tous les paramètres et constantes par défaut du profil de la station STI-C de véhicule non définis ou remplacés dans le présent règlement doivent être établis conformément à l’annexe H de la norme [EN 302 636-4-1].

    (41)Le GN doit être utilisé avec la constante itsGnSecurity fixée à pGnSecurity.

    (42)Le GN doit être utilisé avec la constante itsGnLocalAddrConfMethod fixée à pGnAddrConfMode.

    (43)Le paramètre GN itsGnMaxGeoAreaSize doit être fixé à pGnMaxAreaSize.

    (44)La répétition de paquets ne doit pas être effectuée par GN dans une station STI-C de véhicule et les étapes correspondantes de répétition dans les procédures de manipulation des paquets décrites au paragraphe 10.3 de la norme [EN 302 636-4-1] ne doivent pas être exécutées.

    Le paramètre «temps de répétition maximal» de la primitive de service GN-DATA.request et la constante de protocole GN itsGnMinPacketRepetitionInterval ne s’appliquent pas à une station STI-C de véhicule.

    (45)Le GN doit être utilisé avec la constante itsGnIfType fixée à pGnInterfaceType.

    (46)La station STI-C de véhicule doit utiliser des en-têtes de paquet SHB (diffusion à un seul bond) tels que définis dans la norme [EN 302 636-4-1] sur tous les paquets CAM qu’elle envoie.

    Par conséquent, l’en-tête GN commun doit utiliser une valeur de pGnShbHtField pour le champ HT et une valeur de pGnShbHstField pour le champ HST lors de la transmission de paquets SHB.

    La station STI-C de véhicule doit utiliser des en-têtes GBC tels que définis dans la norme [EN 302 636-4-1] sur tous les paquets DENM qu’elle envoie.

    Par conséquent, l’en-tête GN commun doit utiliser une valeur de pGnGbcHtField pour le champ HT lors de la transmission de paquets DENM.

    Pour le champ HST, l’une des valeurs suivantes doit être utilisée:

    ·0 pour les zones circulaires;

    ·1 pour les zones rectangulaires;

    ·2 pour les zones ellipsoïdales.

    Remarque: ce profil couvre le traitement des paquets SHB et GBC. Étant donné qu’il ne couvre pas le traitement des autres types de paquets GN définis dans la norme [EN 302 636-4-1], il n’empêche pas leur mise en œuvre.

    (47)La station STI-C de véhicule doit fixer le champ LifeTime de tous les paquets SHB de la manière suivante:

    ·multiplicateur de sous-champ fixé à pGnShbLifeTimeMultiplier et base de sous-champ fixée à pGnShbLifeTimeBase.

    (48)La station STI-C de véhicule doit fixer le champ LifeTime de tous les paquets GBC à la valeur minimale de la ValidityDuration et du RepetitionInterval, la ValidityDuration et le RepetitionInterval étant définis dans le profil de service correspondant. La valeur du champ LifeTime ne doit pas dépasser la constante itsGnMaxPacketLifetime, comme spécifié à l’annexe H de la norme [EN 302 636-4-1].

    (49)La station STI-C de véhicule doit mettre en mémoire tampon les paquets GBC lorsqu’aucun voisin n’est disponible (stocker-transporter-transférer). Par conséquent, le bit Store Carry Forward (SCF) du champ TC des paquets GBC doit être fixé à pGnGbcScf.

    (50)La station STI-C de véhicule n’est pas tenue de décharger des paquets vers un autre canal. Par conséquent, le bit de déchargement vers un canal du champ TC devrait être fixé à pGnChannelOffLoad.

    (51)La station STI-C de véhicule doit utiliser les profils de DCC spécifiés au point (28). Par conséquent, les bits d’identificateur (ID) de profil de DCC du champ TC doivent utiliser les valeurs d’identification de profil de DCC définies au point (28).

    (52)La station STI-C de véhicule doit fixer le bit itsGnIsMobile du champ Flags (Fanions) à pGnIsMobile.

    (53)La station STI-C de véhicule doit prendre en charge le mode opérationnel à plusieurs bonds. Elle doit mettre en œuvre l’algorithme de transfert spécifié dans les annexes D, E.3 et F.3 de la norme [EN 302 636-4-1].

    (54)Lors du transfert de paquets, la station STI-C de véhicule doit utiliser le profil de DCC DP3 tel que défini dans la norme [TS 102 724] et visé au point (28).

    (55)La station STI-C de véhicule doit utiliser la détection de paquets en double sur la couche de mise en réseau et de transport. Par conséquent, l’algorithme spécifié à l’annexe A.2 de la norme [EN 302 636-4-1] doit être utilisé pour détecter les paquets en double.

    (56)Toutes les trames GN envoyées par la station STI-C de véhicule doivent utiliser la valeur EtherType pGnEtherType telle qu’indiquée par l’autorité d’enregistrement Institut des ingénieurs électriciens et électroniciens (IEEE) sous http://standards.ieee.org/develop/regauth/ethertype/eth.txt.

    (57)Le protocole de transport de base (BTP) de la station STI-C de véhicule doit être conforme à la norme [EN 302 636-5-1].

    (58)La station STI-C de véhicule doit utiliser des en-têtes BTP-B. Par conséquent, l’en-tête GN commun doit utiliser une valeur de pGnBtpNh pour le champ NH.

    (59)La station STI-C de véhicule doit fixer le champ Destination port info (Information de port de destination) à la valeur pBtpDestPortInfo.

    (60)Dans l’en-tête BTP-B, la station STI-C de véhicule doit fixer le port de destination à la valeur pBtpCamPort pour les CAM.

    (61)Dans l’en-tête BTP-B, la station STI-C de véhicule doit fixer le port de destination à la valeur pBtpDenmPort pour les DENM.

    (62)La station STI-C de véhicule doit prendre en charge des zones géographiques circulaires, rectangulaires et ellipsoïdales telles que définies dans la norme [EN 302 931]. Chaque cas d’utilisation défini dans le profil de service correspondant doit spécifier l’un des types de zones géographiques ci-dessus indiqués dans l’en-tête GN comme spécifié dans la norme [EN 302 636-4-1].

    (63)Lorsqu’une station STI-C de véhicule calcule la distance entre deux positions à l’aide de coordonnées Galileo ou d’autres coordonnées GNSS (par exemple pour les PathDeltaPoints ou dans les cas de zones de pertinence circulaires), le grand cercle ou une méthode plus précise doit être utilisée.

    2.8.Couche installations

    (64)Le service de base de sensibilisation coopérative (CA) de la station STI-C de véhicule doit être conforme à la norme [EN 302 637-2].

    (65)Le champ de l’historique de cheminement dans le conteneur à basse fréquence de CAM doit être généré selon la méthode spécifiée au point (86) et contenir un élément de données PathHistory couvrant une distance minimale de pCamTraceMinLength (paramètre K_PHDISTANCE_M, comme défini dans l’annexe A.5 de la norme [SAE J2945/1]).

    Une exception à la distance minimale couverte par PathHistory ne doit être faite que si:

    ·le véhicule n’a pas encore physiquement parcouru la distance avec son AT actuel (par exemple, après le démarrage du véhicule ou juste après un changement de l'AT en cours de conduite); ou

    ·le nombre maximal de PathPoints est utilisé, mais la longueur totale couverte par le PathHistory n’atteint toujours pas la pCamTraceMinLength.

    Remarque: cette situation peut se présenter si la topologie de la route présente des virages serrés et si la distance entre les PathPoints consécutifs est réduite.

    Le véhicule ne peut envoyer des informations PathHistory couvrant une distance inférieure à la pCamTraceMinLength que dans les cas susmentionnés.

    (66)Le PathHistory contenu dans les CAM doit couvrir au maximum la pCamTraceMaxLength.

    (67)Le PathHistory contenu dans les CAM doit inclure le PathDeltaTime dans chaque PathPoint. Il doit établir une liste des lieux géographiques effectivement parcourus jusqu’à la position actuelle du véhicule, classés en fonction de l’heure à laquelle le véhicule a atteint ces positions, le premier point étant le point le plus proche, dans le temps, de l’heure actuelle.

    (68)Lorsque la station STI-C de véhicule n’est pas en mouvement, c’est-à-dire lorsque les informations de position du PathPoint ne changent pas, le PathDeltaTime du premier PathPoint continue de devoir être mis à jour avec chaque nouveau CAM.

    (69)Lorsque la station STI-C de véhicule n’est pas en mouvement, c’est-à-dire lorsque les informations de position du PathPoint ne changent pas, pendant une durée supérieure à la valeur maximale du PathDeltaTime (spécifiée dans la norme [TS 102 894-2]), le PathDeltaTime du premier PathPoint du CAM doit être fixé à la valeur maximale.

    (70)Le service de base de CA doit être actif tant que le véhicule se trouve sur la voie publique et présente une dynamique de conduite normale. Tant que le service de base de CA est actif, les CAM doivent être générés conformément aux règles de génération énoncées dans la norme [EN 302 637-2].

    (71)Une station STI-C de véhicule doit transmettre des messages CAM lorsque des informations de confiance relatives à la position sont disponibles et que l’horloge de la station respecte les dispositions du point (91).

    (72)La valeur de la TC des messages CAM doit être fixée à pCamTrafficClass.

    (73)Le paramètre T_GenCam_Dcc (voir la norme [EN 302 637-2]) doit être fixé à la valeur du temps minimal entre deux transmissions, à savoir le Toff, comme indiqué dans le tableau A.2 (mécanismes de DCC) de la norme [TS 102 687].

    (74)Le paramètre réglable N_GenCam (voir la norme [EN 302 637-2]) spécifié dans la gestion de la fréquence de génération de CAM doit être fixé à pCamGenNumber pour la station STI-C de véhicule.

    (75)Le service de base de notification environnementale décentralisée (DEN) de la station STI-C de véhicule doit être conforme à la norme [EN 302 637-3].

    (76)La répétition du DENM doit être effectuée par le service de base DEN comme spécifié dans la norme [EN 302 637-3].

    (77)Le champ de l’historique de cheminement dans les messages DEN doit être généré selon la méthode spécifiée au point (86) et contenir des éléments de données relatifs aux traces couvrant une distance minimale de pDenmTraceMinLength (paramètre K_PHDISTANCE_M défini dans l’annexe A.5 de la norme [SAE J2945/1]).

    Une exception à la distance minimale couverte par les traces doit être accordée uniquement si:

    ·le véhicule n’a pas encore physiquement parcouru la distance avec son AT actuel (par exemple, après le démarrage du véhicule ou juste après un changement de l'AT survenu en cours de conduite); ou

    ·le nombre maximal de PathPoints est utilisé, mais la longueur totale couverte par le PathHistory n’atteint toujours pas la pDenmTraceMinLength.

    Remarque: cette situation peut se présenter si la topologie de la route présente des virages serrés et si la distance entre les PathPoints consécutifs est réduite.

    Le véhicule ne peut envoyer des informations relatives aux traces couvrant une distance inférieure à la pDenmTraceMinLength que dans les deux cas susmentionnés.

    (78)Les traces contenues dans les DENM doivent couvrir au maximum la pDenmTraceMaxLength.

    (79)Une station STI-C de véhicule doit utiliser les traces contenues dans les DENM comme suit:

    ·le premier élément de trace doit établir une liste chronologique des lieux géographiques effectivement parcourus jusqu’à la position de l’événement, comme spécifié au point (67).

    (80)Les éléments de données PathDeltaTime des PathPoints dans le premier élément de traces du DENM ne doivent être mis à jour que si le DENM est mis à jour.

    (81)Lorsque le véhicule détectant l’événement n’est pas en mouvement, c’est-à-dire lorsque les informations de position du PathPoint ne changent pas, le PathDeltaTime du premier PathPoint du premier élément de traces du DENM continue de devoir être mis à jour avec chaque nouvelle DEN_Update.

    Remarque: ce n’est le cas que pour les événements à l’arrêt dans le cadre desquels le véhicule de détection est identique à l’événement, par exemple un avertissement en cas de véhicule à l’arrêt. Ce n’est en revanche pas le cas pour les événements dynamiques, par exemple les situations dangereuses ou les événements qui ne sont pas identiques au véhicule (avertissements en cas de conditions météorologiques défavorables, etc.).

    (82)Lorsque la station STI-C de véhicule n’est pas en mouvement, c’est-à-dire lorsque les informations de position du PathPoint ne changent pas, pendant une durée supérieure à la valeur maximale du PathDeltaTime (spécifiée dans la norme [TS 102 894-2]), le PathDeltaTime du premier PathPoint dans le premier élément de traces du DENM doit être fixé à la valeur maximale.

    (83)Des éléments PathHistory supplémentaires peuvent être présents dans les traces du DENM. Toutefois, contrairement au premier élément, ceux-ci doivent décrire des itinéraires de remplacement vers l’emplacement de l’événement. Ces itinéraires peuvent ou non être disponibles au moment de la détection de l’événement. Dans les itinéraires de remplacement, les PathPoints doivent être classés en fonction de leur position (c’est-à-dire les itinéraires les plus courts) et ne doivent pas inclure le PathDeltaTime.

    (84)Pour les services prioritaires, la station STI-C de véhicule ne doit générer que des DENM comme décrit dans le profil de service correspondant.

    (85)Les éléments de données qui constituent le contenu du CAM et du DENM doivent être conformes à la norme [TS 102 894-2] et utiliser le système de coordonnées spécifié aux points (87), (10) et (11).

    (86)Les traces et les historiques de cheminement utilisés par la station STI-C de véhicule doivent être générés au moyen de la méthode de conception 1, comme spécifié dans l’annexe A.5 de la norme [SAE J2945/1]. La station STI-C de véhicule doit utiliser cette méthode de génération avec les réglages suivants:

    ·K_PHALLOWABLEERROR_M = pTraceAllowableError, où PH_ActualError < K_PHALLOWABLEERROR_M;

    ·distance maximale entre les points de cheminement concis, K_PH_CHORDLENGTHTHRESHOLD = pTraceMaxDeltaDistance;

    ·K_PH_MAXESTIMATEDRADIUS = REarthMeridian;

    ·K_PHSMALLDELTAPHI_R = pTraceDeltaPhi;

    ·REarthMeridian = pTraceEarthMeridian (selon l’UGGI), utilisé pour le calcul du grand cercle ou de la distance orthodromique:

    PH_ActualChordLength =    
    REarthMeridian*cos
    -1[cos(lat1)cos(lat2)cos(long1-long2)+sin(lat1)sin(lat2)]

    (87)La station STI-C de véhicule doit utiliser un système de coordonnées conforme à la section 2.13 de la norme [ISO 8855].

    Remarque: cela signifie que les axes X et Y sont parallèles au plan du sol, l’axe Z est aligné verticalement vers le haut, l’axe Y pointe vers la gauche dans le sens de déplacement avant du véhicule et l’axe X pointe vers le sens de déplacement avant du véhicule.

    2.9.Exigences liées au matériel

    (88)La valeur de confiance de 95 % [voir la section 2.1, point b), et le point(12)] doit être valide dans chacun des scénarios énumérés au point (92). Cela implique que dans le cadre d’un essai d’évaluation de la valeur de confiance (qui peut s’effectuer hors ligne), il n’est pas approprié d’établir une moyenne statistique pour tous les états et scénarios.

    À la place, une fenêtre glissante contenant les états du véhicule [voir la section 2.1, point a)] des dernières secondes de pPotiWindowTime doit être utilisée comme base statistique.

    Remarque: le mécanisme de validation de la confiance proposé au moyen de la fenêtre glissante est généralement effectué hors ligne, en tant que traitement postérieur des données d’essai recueillies. Il n’est pas requis que la station STI-C de véhicule effectue une validation de confiance en ligne, c’est-à-dire lorsqu’elle se trouve sur la voie publique et dans une dynamique de conduite normale.

    Remarque: l’approche de la fenêtre glissante présente les avantages suivants par rapport aux statistiques distinctes pour chaque scénario:

    ·les transitions entre les scénarios sont incluses;

    ·la confiance est valide «immédiatement» («now») plutôt que «pendant l’ensemble de la durée de vie» («over lifetime»). Les «erreurs en rafale» («error bursts», grand nombre de valeurs de confiance non valides dans un court laps de temps) ne sont pas autorisées, ce qui a pour conséquence:

    ·d’améliorer l’utilité de la valeur de confiance pour les applications;

    ·d’exiger une détection rapide de la dégradation de la précision dans la PoTi;

    ·la définition précise des données d’essai n’a aucun effet sur les paramètres de validation de la confiance. Toutefois, les données d’essai doivent contenir tous les scénarios énumérés au point (92);

    ·aucun autre calcul statistique n’est nécessaire; les scénarios couvrent tous les états pertinents;

    ·la longueur de l’intervalle est similaire à celle d’un scénario type (environnement et conditions de conduite) (ex.: tunnel urbain, immobilisation au niveau de feux de signalisation, manœuvres de conduite);

    ·5 % de l’intervalle est similaire aux effets à court terme types (ex.: conduite sous un pont).

    (89)Un véhicule est considéré comme étant soumis à une dynamique de conduite normale lorsque:

    ·il a passé sa phase initiale de démarrage;

    ·son utilisation est conforme à celle prévue par son fabricant;

    ·le contrôle normal du véhicule est possible (ex.: il n’intervient pas directement dans un accident, la surface de la route permet une adhérence normale des pneus);

    ·toutes les conditions (valeurs) suivantes s’appliquent aux voitures particulières:

    ·l’accélération latérale du véhicule est < 1,9 m/s^2;

    ·l’accélération longitudinale du véhicule est > -2,4 m/s^2 (décélération);

    ·l’accélération longitudinale du véhicule est < 2,5 m/s^2;

    ·la vitesse du véhicule est inférieure ou égale (≤), au moins, à (130 km/h, Vmax).

    (90)Dans des conditions GNSS optimales et une dynamique de conduite normale, telle que définie au point (89), les valeurs de confiance doivent être inférieures ou égales aux valeurs suivantes pour au moins 95 % des points de données de position 3D dans un ensemble de données:

    ·confiance de position horizontale de 5 m;

    ·confiance de position verticale de 20 m.

    Dans d’autres scénarios, la diminution des exigences visée au point (92) s’applique. Cette exigence garantit l’utilité des informations envoyées dans tous les messages STI-C.

    (91)L’horloge de la station doit respecter la pPotiMaxTimeDiff de l’heure STI-C, soit Delta t = |heure de l’horloge de la station - heure STI-C| < pPotiMaxTimeDiff.

    (92)Une station STI-C de véhicule doit pouvoir fournir des estimations utiles de l’état du véhicule concerné, même dans des scénarios difficiles. Pour tenir compte des diminutions inévitables, les valeurs de confiance requises sont définies dans le tableau 2 pour différents scénarios.

    «C» représente le maximum du semiMajorConfidence et du semiMinorConfidence. La condition pour «C» doit être remplie pour 95 % des points de données de l’ensemble de données du scénario donné.

    Remarque: les critères doivent être remplis dans le cadre de la dynamique de pente suivante pour la fraction de trace analysée: pente moyenne inférieure ou égale (<=) à 4 % et pente maximale inférieure ou égale (<=) à 15 %.

    Remarque: comme condition préalable, chaque scénario doit commencer par une minute de conduite à ciel dégagé et une dynamique de conduite normale.

    Remarque: aucune valeur C n’indique que le scénario doit être soumis à l’essai pour garantir que l’intervalle de confiance rapporté est valide, mais aucune limite n’est donnée.

    Tableau 2: Scénarios

    ID

    Scénario

    Définition

    Acceptation

    Environnement dans une dynamique de conduite normale

    S1

    Ciel dégagé

    Ciel obstrué à moins de 20 %, le véhicule roulant dans une dynamique de conduite normale et dans des conditions routières normales

    C <= 5 m

    S2

    Tunnel

    Aucun satellite GNSS n’est visible pendant au moins 30 s et 250 m (vmin = 30 km/h); Réflexion du signal GNSS à l’entrée et à la sortie du tunnel

    C < 15 m

    S3

    Structure de stationnement

    Pas de satellites GNSS directs visibles, mais connexion par réflexion, T > 60 s, vmax < 20 km/h, minimum deux virages à 90° et s > 100 m, deux rampes à l’entrée et à la sortie

    toutes les valeurs sont permises

    S4

    Ciel à moitié dégagé

    Le ciel est obstrué de 30 à 50 % (obstruction concentrée sur un côté de la voiture) pendant plus de 30 s; conditions de conduite identiques à celles du S1

    C < 7 m

    S5

    Forêt

    Le ciel est obstrué de 30 à 50 % par des objets, y compris des arbres plus hauts que l’antenne, pendant plus de 30 s

    C < 10 m

    S6

    Montagnes (vallée)

    Le ciel est obstrué de 40 à 60 % par une ou plusieurs haute(s) montagne(s); conditions de conduite identiques à celles du S1

    C < 10 m

    S7

    Ville

    Dans le cadre d’un trajet de 300 s, le ciel était obstrué de 30 à 50 % (de courtes périodes pendant lesquelles le ciel était obstrué à moins de 30 à 50 % étant permises); réflexion fréquente du signal GNSS sur les bâtiments, y compris de courtes pertes du signal GNSS (soit moins de quatre satellites); conditions de conduite identiques à celles du S1

    C < 14 m

    S8

    Zone légèrement urbaine

    Le ciel est obstrué de 20 à -40 %, t > 60 s, s > 400 m. Conditions de conduite identiques à celles du S1, y compris des arrêts, des arbres et/ou des bâtiments, ainsi que des allées

    C < 10 m

    Conditions de conduite sous un ciel dégagé

    S9

    Conduite dynamique

    Conduite d’essai avec des accélérations longitudinales supérieures à -6 m/s² et des accélérations latérales > (±) 5 m/s².

    C < 7 m

    S10

    Statique

    Véhicule immobilisé pendant 30 minutes

    C < 5 m

    S11

    Route difficile

    Conduite d’essai sur route en terre présentant des nids-de-poule, v = 20 à 50 km/h

    C < 10 m

    S12

    Route verglacée

    Conduite d’essai avec des accélérations longitudinales de plus de -0,5 m/s² et des accélérations latérales > (±) 0,5 m/s², µ < 0,15

    C < 7 m

    S13

    Vitesse élevée

    V = minimum de (130 km/h, Vmax) sur route sèche pendant 30 s

    C < 5 m

    (93)Dans des conditions GNSS optimales et une dynamique de conduite normale, telle que définie au point (89), les valeurs de confiance de vitesse doivent être inférieures ou égales aux valeurs suivantes pour au moins 95 % des points de données d’un ensemble de données:

    ·0,6 m/s pour des vitesses comprises entre 1,4 m/s et 12,5 m/s;

    ·0,3 m/s pour des vitesses supérieures à 12,5 m/s.

    (94)Dans des conditions GNSS optimales et une dynamique de conduite normale, telle que définie au point (89), les valeurs de confiance de cap doivent être inférieures ou égales aux valeurs suivantes pour au moins 95 % des points de données d’un ensemble de données:

    ·3° pour des vitesses comprises entre 1,4 m/s et 12,5 m/s;

    ·2° pour des vitesses supérieures à 12,5 m/s.

    3.Exigences pour les stations STI-C de bord de route conçues pour des communications à courte portée

    Ce profil de système spécifie un ensemble minimal de normes et comble les lacunes dans la mesure nécessaire à la réalisation d’une station STI-C de bord de route interopérable du côté émetteur. Ce profil ne comprend que les exigences en matière d’interopérabilité, en laissant la possibilité d’ajouter des exigences supplémentaires. Par conséquent, il ne décrit pas toutes les fonctionnalités de la station STI-C de bord de route.

    Ce profil de système rend possible le déploiement des services prioritaires (I2V notamment). Il peut prendre en charge d’autres services, mais ceux-ci peuvent requérir des spécifications système supplémentaires.

    Le profil fournit des descriptions, des définitions et des règles pour les couches (Applications, Installations, Mise en réseau et transport, et Accès) et la gestion de l’architecture de référence de station STI de l’ETSI/STI-S hôte.

    3.1.Gestion de la position et du temps

    (95)L’heure STI-C d’une station STI-C de bord de route statique doit servir de base à tous les horodatages de toutes les balises GN et de tous les messages transmis.

    Remarque: cela signifie que les horodatages dans l’en-tête GN doivent utiliser la même horloge et la même base temporelle que celles utilisées dans les charges utiles CAM/DENM/IVIM. Pour les messages SPATEM et MAPEM, l'horodatage utilisé devrait être tel que spécifié dans la norme [ISO TS 19091].

    (96)La position des stations STI-C de bord de route statiques doit être mesurée et établie avec précision en permanence.

    Les valeurs de confiance doivent être inférieures ou égales aux valeurs suivantes pour au moins 95 % des ensembles de données:

    ·confiance de position horizontale (latitude, longitude) de 5 m;

    ·confiance de position en altitude de 20 m.

    Remarque: cela permet d’éviter la gigue GNSS dans la précision de la position et augmente la confiance à près de 100 %.

    (97)La différence entre l’horloge de la station et la base temporelle doit faire l’objet d’une estimation. La différence absolue |heure de l’horloge de la station — base temporelle| ne doit pas dépasser 20 ms, mais doit dans tous les cas être inférieure à 200 ms. La station STI-C de bord de route ne doit pas transmettre de messages si l’heure de l’horloge de la station diffère de plus de 200 ms.

    Remarque: un horodatage précis n’est pas seulement nécessaire pour la synchronisation de l’heure, mais implique également que les états du système sont valides à ce moment précis dans le temps, c’est-à-dire que les états du système restent cohérents.

    Remarque: les informations pour la synchronisation de l’heure peuvent être obtenues depuis un récepteur Galileo ou un autre récepteur GNSS ou un service du protocole de synchronisation réseau (NTP).

    3.2.Comportement du système

    (98)Toutes les stations STI-C de bord de route doivent pouvoir transmettre les messages d’infrastructure [par exemple des DENM, des CAM, des messages d’information infrastructure à véhicule (IVIM), des messages étendus concernant les phases et le minutage de signalisation (SPATEM), des messages MAP étendus (MAPEM) et des messages étendus de demande d’état d’allumage de signal (SSEM)].

    (99)Les stations STI-C de bord de route doivent pouvoir recevoir des DENM, des CAM et des messages étendus de demande d’allumage de signal (SREM), comme spécifié à la section 3.6.

    3.3.Couche d’accès

    La couche d’accès comprend les deux couches inférieures de la pile de protocoles, c’est-à-dire la couche physique (PHY) et la couche liaison de données, cette dernière étant encore subdivisée en commande d’accès au support (MAC) et en commande de liaison logique (LLC).

    (100)Les stations STI-C de bord de route doivent utiliser les prescriptions améliorées facultatives relatives à l’efficacité du récepteur, comme spécifié dans les tableaux 17 à 19 de la norme IEEE 802.11.

    (101)Les stations STI-C de bord de route doivent utiliser le canal de commande G5-CCH comme spécifié dans le tableau 3 de la norme [EN 302 663] pour envoyer des messages afin de prendre en charge les services STI-C prioritaires spécifiés dans l’annexe 3, en utilisant un débit de transfert par défaut de 6 Mbit/s [modulation par déplacement de phase quadrivalente (QPSK) 1/2].

    (102)La couche d’accès de la station STI-C de bord de route doit être conforme à la norme [EN 302 663], à l’exception des limites d’émission et des paragraphes 4.2.1, 4.5 et 6.

    (103)Les stations STI-C de bord de route doivent être conformes à la norme [TS 102 687].

    (104)Les stations STI-C de bord de route devraient gérer les ressources matérielles et logicielles limitées dont elles disposent et peuvent procéder à une modulation du trafic ou à un transfert sélectif conformément au principe du «meilleur effort».

    Remarque: la modulation du trafic est particulièrement pertinente pour les messages de DENM relayés, car, dans certaines situations (comme les graves encombrements du trafic ou d’autres scénarios extrêmes de réseau de véhicules), il est prévu que la charge du DENM puisse augmenter brusquement. Dans de tels cas, les stations STI-C de bord de route sont explicitement autorisées à renoncer au transfert de messages DENM étrangers.

    (105)La station STI-C de bord de route doit pouvoir, au minimum, générer et transmettre le nombre de messages déterminé par la valeur du taux de génération de CAM le plus élevé (soit 10 Hz) et, si des algorithmes de détection sont utilisés, ce nombre doit être augmenté du taux de génération de DENM minimal requis dérivé de ces conditions de déclenchement.

    (106)Une station STI-C de bord de route doit prendre en charge le mode de radiodiffusion défini dans la norme [EN 302 663].

    (107)Une zone protégée doit être définie comme suit:

    ·lorsqu’un lieu de péage est constitué d’une seule unité de bord de route (RSU) CEN-DSRC, une zone protégée présentant un rayon par défaut de 55 m doit être définie, la position centrale étant le lieu de la RSU CEN-DSRC.

    ·lorsque plusieurs RSU CEN-DSRC se trouvent à proximité, il conviendrait, dans la mesure du possible, d’éviter les chevauchements de zones protégées en utilisant une zone protégée combinée. Une zone protégée combinée doit utiliser le centre géographique (centre du cercle circonscrit) de toutes les RSU DSRC concernées comme position centrale; le rayon doit être donné par le rayon du cercle circonscrit + 55 m. Dans tous les cas, un rayon maximal de 255 m ne doit pas être dépassé.

    Remarque: en raison du rayon maximal de 255 m, les chevauchements ne peuvent pas toujours être évités.

    (108)Lorsqu’une station STI-C de bord de route est située à proximité d’un équipement de péage basé sur des CEN-DSRC (au moins dans la zone protégée), elle doit appliquer les techniques d’atténuation définies dans la norme [TS 102 792].

    (109)Les stations STI-C de bord de route mobiles doivent appliquer des méthodes d’atténuation sur la base de messages d’annonce de zone de péage.

    (110)Lorsque la station STI-C de bord de route est utilisée pour indiquer la présence d’une gare de péage, elle doit transmettre des CAM comprenant les zones protégées conformément à la technique définie dans la norme [TS 102 792] et au format de message de CA spécifié dans la norme [EN 302 637-2]. Elle doit transmettre ces CAM sur le canal de commande, avant qu’une station STI-C de véhicule ne pénètre dans la zone protégée.

    (111)La couche d’accès des stations STI-C de bord de route doit être conforme à la norme [TS 102 724].

    (112)Les stations STI-C de bord de route doivent appliquer des techniques de DCC conformément à la norme [TS 102 687].

    3.4.Couche de mise en réseau et de transport

    (113)Les stations STI-C de bord de route doivent appliquer le GN comme protocole de réseautage conformément à la norme [EN 302 636-4-1].

    (114)Tous les paramètres et constantes par défaut du profil de bord de route de l’infrastructure non spécifiés dans la présente annexe doivent être établis conformément aux spécifications de l’annexe H de la norme [EN 302 636-4-1].

    (115)La répétition de paquets ne doit pas être effectuée par GN et les étapes correspondantes dans les procédures de manipulation des paquets définies dans le paragraphe 10.3 de la norme [EN 302 636-4-1] ne doivent pas être exécutées. Le paramètre «temps de répétition maximal» («maximum repetition time») de la primitive de service GN-DATA.request et la constante de protocole GN itsGnMinPacketRepetitionInterval ne s’appliquent pas.

    (116)Les stations STI-C de bord de route peuvent choisir la «configuration anonyme de l’adresse» («anonymous address») pour la configuration de l’adresse GN [itsGnLocalAddrConfMethod fixée à ANONYMOUS(2)].

    (117)Les stations STI-C de bord de route doivent utiliser le GN avec itsGnIfType fixé à ITS-G5(1).

    (118)Lorsque la répétition de paquets GN est désactivée, la constante itsGnMinPacketRepetitionInterval n’est pas applicable.

    (119)Le champ LifeTime de tous les paquets SHB doit être fixé à une seconde.

    (120)Le champ LifeTime de tous les paquets GBC doit être fixé au minimum de la ValidityDuration et du RepetitionInterval, mais ne doit pas dépasser le paramètre itsGnMaxPacketLifetime spécifié à l’annexe H de la norme [EN 302 636-4-1].

    (121)Lorsque «stocker-transporter-transférer» («store-carry-forward») est activé, le bit SCF dans le champ TC doit être mis à un.

    Remarque: par conséquent, les paquets peuvent être mis en mémoire tampon si aucun voisin n’est disponible.

    (122)Une station STI-C de bord de route n’est pas tenue de décharger des paquets vers un autre canal. Par conséquent, le bit de déchargement vers un canal du champ TC devrait être mis à 0 pour tous les types de messages.

    (123)La station STI-C de bord de route à l’arrêt doit mettre le bit itsGnIsMobile du champ Flags à 0. La station STI-C de bord de route mobile doit mettre le bit itsGnIsMobile du champ Flags à 1.

    (124)Les stations STI-C de bord de route doivent prendre en charge le mode opérationnel à plusieurs bonds en utilisant les algorithmes spécifiés dans les annexes E.3 et F.3 de la norme [EN 302 636-4-1], sur la base des principes de sélection définis dans l’annexe D de cette même norme.

    (125)Les stations STI-C de bord de route doivent utiliser la détection de paquets en double sur la couche de mise en réseau et de transport. Pour la détection des paquets en double, l’algorithme spécifié à l’annexe A.2 de la norme [EN 302 636-4-1] doit être utilisé.

    (126)Les stations STI-C de bord de route ne peuvent envoyer que des balises GN dont l’indicateur de précision de position (PAI) est mis à 1.

    (127)Les trames GN envoyées par la station STI-C de bord de route doivent utiliser la valeur EtherType 0x8947 telle qu’indiquée par l’autorité d’enregistrement IEEE sous http://standards.ieee.org/develop/regauth/ethertype/eth.txt. 

    (128)Les stations STI-C de bord de route doivent mettre en œuvre le BTP conformément à la norme [EN 302 636-5-1].

    (129)Les stations STI-C de bord de route doivent utiliser des en-têtes BTP-B. Par conséquent, l’en-tête GN commun doit utiliser une valeur de 2 pour le champ NH.

    (130)Les stations STI-C de bord de route doivent fixer le champ Destination port info (Information de port de destination) à la valeur 0.

    (131)Les stations STI-C de bord de route doivent fixer le port de destination en fonction du message établi tel que spécifié dans la norme [TS 103 248].

    (132)Les zones géographiques doivent être appliquées conformément à la norme [EN 302 931].

    (133)Les stations STI-C de bord de route doivent prendre en charge, au moins, des zones géographiques circulaires, rectangulaires et ellipsoïdales telles que définies dans la norme [EN 302 931]. Chaque service STI-C doit spécifier l’un des types de zones géographiques susmentionnés, indiqués dans l’en-tête GN comme spécifié dans la norme [EN 302 636-4-1].

    (134)Lorsqu’une station STI-C de bord de route calcule la distance entre deux positions à l’aide de coordonnées Galileo ou d’autres coordonnées GNSS (par exemple pour les PathDeltaPoints ou dans les cas de zones de pertinence circulaires), il est recommandé d’utiliser le grand cercle ou une méthode plus précise. Des précautions doivent être prises (en utilisant la formule de Haversine, par exemple) pour éviter les grandes erreurs d’arrondi sur les systèmes à virgule flottante de faible précision.

    Lorsque la zone de pertinence est une ellipse ou un rectangle, les coordonnées cartésiennes du centre de la zone et de la position actuelle doivent être calculées comme spécifié dans la norme [EN 302 931], pour évaluer si un bond du paquet est nécessaire. À cette fin, il est recommandé d’utiliser la méthode du «plan tangent local» ou une autre méthode offrant un même niveau de précision.

    3.5.Couche installations

    (135)Le service de base DEN des stations STI-C de bord de route doit être conforme à la norme [EN 302 637-3].

    (136)La station STI-C de bord de route doit mettre en œuvre la répétition du DENM comme spécifié dans la norme [EN 302 637-3].

    (137)Les cas dans lesquels les mises à jour du DENM sont déclenchées sont spécifiés dans le profil de service correspondant de l’annexe I.

    (138)Lorsqu’une station STI-C de bord de route envoie un DENM, les traces doivent être décrites sous la forme d’une liste de lieux géographiques allant de la position de l’événement au premier point de cheminement.

    (139)Lorsqu’une station STI-C de bord de route mobile se retrouve à l’arrêt, le PathDeltaTime du premier PathPoint du premier élément de traces du DENM doit être fixé à la valeur maximale spécifiée dans la norme [EN 302 637-3]. Par conséquent, les PathPoints ne «s’écartent» pas du premier élément de traces du DENM. Cela s’applique uniquement aux services STI-C sur remorque.

    (140)Des éléments PathHistory supplémentaires peuvent être présents dans les traces du DENM. Toutefois, contrairement au premier élément, ceux-ci doivent décrire des itinéraires de remplacement vers l’emplacement de l’événement. Ces itinéraires peuvent ou non être disponibles au moment de la détection de l’événement.

    (141)Pour les stations STI-C de bord de route, la valeur de TC d’un message est spécifique au service basé du format du message ou au service STI-C lui-même et est donc spécifiée dans le profil de service correspondant de l’annexe I. La valeur de TC sélectionnée doit être conforme aux classifications de message spécifiées dans les normes [TS 102 636-4-2] et [TS 103 301]; cependant, les messages d’information infrastructure à véhicule (IVI) relatifs aux limitations de vitesse variables sont des équivalents DENM de faible priorité et peuvent donc présenter la même valeur de TC.

    (142)Le système d’infrastructure doit utiliser un système de coordonnées conforme à la section 2.13 de la norme [ISO 8855].

    Remarque: cela signifie que les axes X et Y sont parallèles au plan du sol, l’axe Z est aligné verticalement vers le haut, l’axe Y pointe vers la gauche dans le sens de déplacement avant du véhicule et l’axe X pointe vers le sens de déplacement avant du véhicule.

    (143)Pour la transmission de messages par les systèmes d’infrastructure, le protocole de couche installations et le paramètre de profil de communication CPS_001 doivent être utilisés comme spécifié dans la norme [TS 103 301].

    (144)Les données des zones protégées fournies dans un CAM envoyé par une station STI-C de bord de route ne doivent pas entrer en conflit avec les informations des zones protégées fournies dans la base de données des zones protégées ou dans une base de données équivalente. Si la même zone est définie dans la base de données des zones protégées, le même ID doit être utilisé en tant que protectedZoneID. Autrement, un ID supérieur à 67108863 qui n’est pas employé dans la base de données doit être utilisé.

    (145)Les stations STI-C de bord de route destinées à diffuser des données de zones protégées doivent transmettre régulièrement des CAM contenant des données de zones protégées en utilisant le format de message spécifié par la norme [EN 302 637-2]. La terminaison des CAM n’est pas utilisée.

    Remarque: les éléments de données spécifiques au service STI-C de coexistence sont situés dans les trames de données highFrequencyContainer et rsuContainerHighFrequency.

    Remarque: un CAM peut contenir d’autres éléments de données qui ne sont pas liés au service STI-C de coexistence.

    (146)L’antenne d’une station STI-C de bord de route destinée à diffuser des données de zones protégées doit être placée de manière à ce que les CAM de zone de protection puissent être reçus à temps avant la pénétration dans la zone protégée.

    Remarque: les dispositions prises pour se conformer à cette exigence doivent tenir compte du temps de traitement dont l’équipement de l’usager de la route a besoin pour traiter les informations reçues. Un temps de 300 ms devrait être utilisé comme référence.

    (147)Une station STI-C de bord de route destinée à diffuser des données de zones protégées doit transmettre des CAM contenant des données de zones protégées avec une fréquence de transmission qui garantit que les stations STI-C mobiles peuvent détecter à temps la présence de zones protégées.

    (148)Une station STI-C de bord de route destinée à diffuser des données de zones protégées doit être installée en dehors des zones protégées ou configurée conformément à la norme [TS 102 792].

    (149)Un CAM ne doit contenir pas plus d’une zone protégée temporaire (soit ProtectedCommunicationZone avec ProtectedZoneType = 1).

    Remarque: cela est propre au péage temporaire et aux véhicules des forces de l’ordre. Les stations STI-C mobiles sont tenues de ne stocker qu’une seule zone protégée temporaire conformément au paragraphe 5.2.2.2 de la norme [TS 102 792], afin d’éviter toute ambiguïté.

    (150)Lorsque les services de coexistence de la couche installations (ITS-G5 — CEN-DSRC) sont utilisés, ils doivent être appliqués conformément à la norme [EN 302 637-2] et comme spécifié dans la norme [TS 102 792].

    (151)La norme [ISO/TS 19321] renvoie à une version antérieure (1.2.1) du dictionnaire de données commun (CDD) de la norme [TS 102 894-2] pour les données de la charge utile. Tous les services STI-C IVI basés sur la norme [ISO/TS 19321] doivent donc être basés sur la version mise à jour (1.3.1), jusqu’à ce que la norme [ISO/TS 19321] soit mise à jour en conséquence.

    (152)Le service de base de CA doit être actif tant que la station STI-C de bord de route mobile fonctionne sur la voie publique et présente une dynamique de conduite normale. Tant que le service de base de CA est actif, les CAM doivent être générés conformément aux règles de génération énoncées dans la norme [EN 302 637-2].

    (153)Les stations STI-C de bord de route doivent transmettre des messages CAM lorsque des informations de confiance relatives à la position sont disponibles et que l’horloge de la station respecte les dispositions du point (97).

    (154)Le paramètre T_GenCam_Dcc doit être fixé à la valeur du temps minimal entre deux transmissions, à savoir le Toff, tel que fourni par le mécanisme de DCC spécifié au point (103).

    (155)Le paramètre réglable N_GenCam spécifié dans la gestion de la fréquence de génération de CAM doit être mis à 0 pour la station STI-C de bord de route, sauf si l’objectif est de diffuser des données de zones protégées comme défini au point (145).

    3.6.Gestion

    Il n’est pas requis de mettre en œuvre tous les services de sécurité spécifiés. En outre, pour certains services, la mise en œuvre est définie en interne par l’exploitant de station STI-C.

    (156)Les stations STI-C de bord de route mettant en œuvre les fonctionnalités ITS-G5 doivent mettre en œuvre une couche de gestion comprenant une entité DCC_CROSS comme spécifié dans la norme [TS 103 175].

    3.7.Éléments de service

    3.7.1.Service de base DEN

    Le service de base DEN utilise les services fournis par les entités de protocole de la couche de mise en réseau et de transport STI pour diffuser des DENM.

    Un DENM contient des informations relatives à un événement présentant une incidence potentielle sur la sécurité routière ou les conditions de trafic. Un événement est caractérisé par un type d’événement, une position d’événement, une heure de détection et une durée. Ces attributs peuvent changer dans l’espace et dans le temps. Dans certaines situations, la transmission de DENM peut être indépendante de la station STI-C d’origine.

    Quatre types de DENM sont générés par le service de base DEN:

       nouveaux DENM;

       DENM de mise à jour;

       DENM d’annulation;

       DENM de négation.

    (157)L’en-tête du DENM doit être tel que spécifié dans le dictionnaire de données de la norme [TS 102 894-2].

    (158)Les éléments de données, les trames de données et les paramètres de service du DENM doivent être établis conformément au tableau 3. En outre, pour les services STI-C concernant les avertissements en cas de travaux routiers, les trames de données et les paramètres de service du DENM doivent être définis conformément au tableau 4.

    Tableau 3: Éléments du DENM en général

    Nom

    Utilisation

    Usage

    Conteneur de gestion

    Obligatoire

    actionID

    Obligatoire

    Contenu:

    L’actionID est l’identificateur unique d’un DENM et se compose des éléments de données originatingStationID et sequenceNumber. L’originatingStationID est l’identificateur unique de la station STI-C dont la couche installations a créé le message, qui peut être la station STI-C centrale ou de bord de route. S’ils ne sont pas établis par la station STI-C centrale, les messages dont le contenu est généré de manière centralisée, mais qui sont diffusés depuis différentes stations STI-C de bord de route disposeront de différents originatingStationID, ce qui résultera en différents actionID.

    Si l’originatingStationID et le sequenceNumber sont donnés par la station STI-C centrale où le contenu généré de manière centralisée est (potentiellement) envoyé par l’intermédiaire de plusieurs stations STI-C de bord de route, le système fournit le même actionID pour tous les messages relatifs au même événement, quelle que soit la station STI-C de bord de route qui envoie le message. Une fois l’actionID établi, il ne changera pas pour les messages relatifs au même événement, même s’ils sont fréquemment mis à jour.

    Valeur:

    non prédéfinie, établie par le système

    detectionTime

    Obligatoire

    Initialement, ce DE doit être fixé au moment auquel l’événement a été détecté. L’heure doit provenir d’une horloge locale dans la station STI-C de bord de route dans des scénarios de cas d’utilisation distincts. Dans les scénarios de cas d’utilisation avec connexion à la station STI-C centrale, le detectionTime doit d’abord être fixé au moment auquel l’application qui crée le DENM reçoit les informations pertinentes, c’est-à-dire au moment où des travaux routiers ou un endroit dangereux commencent/sont détectés à un niveau fonctionnel.

    Valeur:

    le detectionTime est initialement fixé à l’heure de début de l’événement (nouveau DENM) puis réinitialisé à chaque mise à jour du DENM. Pour la terminaison du DENM, ce DE doit correspondre au moment auquel la terminaison de l’événement est détectée.

    referenceTime

    Obligatoire

    Contenu:

    Le referenceTime doit être fixé au moment auquel le message DENM est généré ou mis à jour.

    Valeur:

    établie automatiquement

    termination

    Facultatif

    Service STI-C spécifique

    eventPosition

    Obligatoire

    Dans le scénario de cas d’utilisation I2V, le DF eventPosition est utilisé pour localiser les blocages de voies ou de chaussées ou les endroits dangereux. Il représente la position à laquelle commence le blocage physique sur la voie (y compris l’accotement) ou la chaussée ou l’endroit dangereux. La précision devrait être au niveau de la voie, mais doit être au moins au niveau de la chaussée.

    Les DE d’altitude et de confiance peuvent être utilisées ou fixés aux valeurs correspondant à «non disponible».

    relevanceDistance

    Facultatif

    Facultatif

    relevanceTrafficDirection

    Obligatoire

    Contenu:

    Valeur fixe. Pour les autoroutes, cette valeur est mise à 1 (trafic en amont).

    Ce DF indique pour quel sens de trafic le message est pertinent (du point de vue de l’eventPosition).

    validityDuration

    Obligatoire

    Les événements sont représentés par des messages DEN. La durée d’un DENM unique est basée sur la valeur (configurable) de la «validityDuration». Tant qu’un événement est valide pour l’exploitant routier, il sera envoyé en continu (au moyen d’une répétition de ce DENM) et mis à jour (au moyen d’une mise à jour du DENM, en renouvelant, au cours du processus, la «validityDuration», le «detectionTime» et le «referenceTime»). Une mise à jour du message sera déclenchée par le passage sous un certain seuil (également configurable) de la «validityDuration». Si l’événement n’est plus valide, il expire ou est annulé de manière active (annulation du DENM).

    Contenu:

    Le DE validityDuration est établi à une valeur fixe.

    Valeur:

    Service STI-C spécifique.

    TransmissionInterval

    Non utilisé

    Non utilisé

    stationType

    Obligatoire

    Contenu:

    Valeur fixe, mise à 15 (roadSideUnit). C’est le cas des stations STI-C de bord de route fixes et mobiles. La valeur peut être mise à 9 [trailer (remorque)] ou à 10 [specialVehicles (véhicules spéciaux)] dans le cas de véhicules d’exploitants routiers.

    Valeur:

    Mise à 9, 10 ou 15.

    Conteneur de situation

    Obligatoire

    informationQuality

    Obligatoire

    La qualité des informations est la probabilité d’occurrence d’un événement, dans une fourchette de 0 à 7.

    Valeurs: risk (2), probable (4), certain (6)

    si la valeur reçue est de (0), elle devrait être rejetée; si la valeur reçue est de (7), elle devrait être considérée comme certaine.

    eventType

    Obligatoire

    Combinaison des DE causeCode et subCauseCode. Service STI-C spécifique.

    linkedCause

    Facultatif

    Possibilité de lier le message actuel à un ensemble de causeCode/subCauseCode (similaire à eventType) pour fournir des informations supplémentaires.

    eventHistory

    Facultatif

    Contenu:

    Ce profil utilise, de manière optionnelle, ce DE lorsqu’il est possible de déterminer le point d’extrémité du blocage physique. Le cas échéant, il décrit le début d’un blocage jusqu’à la fin du blocage, ou jusqu’au début d’un nouveau blocage (autre DENM). Dans un tel contexte, les valeurs eventPoint sont fournies sans eventDeltaTime correspondant étant donné que les points décrivent une étendue géospatiale et non une trajectoire.

    Le DE informationQuality dans l’eventHistory sera fixé à la même valeur que la valeur informationQuality spécifiée ci-dessus de l’ensemble du DENM.

    Lorsque des projections cartographiques sont utilisées, elles doivent se référer à des points situés au milieu de la voie ou de la chaussée.

    L’écart maximal entre la réalité et les projections cartographiques ne doit pas dépasser un quart de la largeur de la chaussée.

    Conteneur de localisation

    Facultatif

    eventSpeed

    Facultatif

    Ce DF, s’il est disponible, ne doit être fourni qu’en cas d’événement en mouvement. Il ne doit pas être fourni en cas d’événements statiques.

    eventPositionHeading

    Facultatif

    Des informations de cap ne seront fournies que pour les événements en mouvement au moyen de l’eventPositionHeading. Les événements à l’arrêt basés sur des DENM n’utiliseront pas ce DF.

    traces

    Obligatoire

    Le premier point de trace du message est le point le plus proche de la position de l’événement. Ce point se trouve au milieu de la voie ou de la chaussée en amont de la position de l’événement, en tenant compte de la courbe de la route. Il est codé comme une position décalée ou différentielle par rapport à la position de l’événement. Les points de trace supplémentaires sont définis comme des positions décalées ou différentielles par rapport à leurs points de trace précédents. La liste des points de trace sera établie en fonction de leur ordre d’apparition en amont, définissant ainsi également le cap de l’événement.

    Jusqu’à sept traces peuvent être présentes.

    Lorsque des projections cartographiques sont utilisées, elles doivent se référer à des points situés au milieu de la voie ou de la chaussée.

    L’écart maximal entre la réalité et les projections cartographiques ne doit pas dépasser un quart de la largeur de la chaussée.

    roadType

    Facultatif

    Facultatif

    Conteneur à la carte

    Facultatif

    lanePosition

    Facultatif

    Service STI-C spécifique.

    impactReduction

    Non utilisé

    Non utilisé

    externalTemperature

    Non utilisé

    Non utilisé

    lightBarSirenInUse

    Non utilisé

    Non utilisé



    Tableau 4: Éléments du DENM propres aux avertissements en cas de travaux routiers

    Nom

    Utilisation

    Usage

    Conteneur à la carte

    Facultatif

    lanePosition

    Facultatif

    facultatif

    closedLanes

    Facultatif

    Les voies sont comptées à partir de la bordure intérieure de la route, à l’exclusion de l’accotement.

    Ce DF est constitué du drivingLaneStatus et du hardShoulderStatus.

    speedLimit

    Facultatif

    facultatif

    recommendedPath

    Facultatif

    facultatif

    startingPointSpeedLimit

    Facultatif

    facultatif

    trafficFlowRule

    Facultatif

    facultatif

    passToRight(2) ou passToLeft(3) sont généralement pris en charge dans tous les scénarios de service STI-C.

    referenceDenms

    Facultatif

    Les DENM d’avertissement en cas de travaux routiers appartenant à la même situation de travaux routiers seront reliés dans la station STI-C centrale en énumérant tous les actionID appartenant ensemble à l’élément de données referenceDenms de chaque message.

    3.7.2.Service IVI

    Le service IVI utilise les services fournis par les entités de protocole de la couche de mise en réseau et de transport STI pour diffuser des IVIM.

    Un IVIM prend en charge la signalisation routière obligatoire et consultative telle que les avertissements contextuels sur les vitesses et les travaux routiers. Un IVIM fournit des informations sur les panneaux de signalisation routière physiques tels que les travaux routiers, les panneaux virtuels ou les panneaux de signalisation routière statiques ou variables.

    Le service IVI instancié dans une station STI-C doit fournir le service de transmission ou celui de réception.

    Le service IVI génère quatre types d’IVIM:

    ·nouveaux IVIM;

    ·IVIM de mise à jour;

    ·IVIM d’annulation;

    ·IVIM de négation.

    (159)L’en-tête de l’IVIM doit être tel que spécifié dans la norme [TS 102 894-2].

    (160)Les éléments de données de la charge utile du message IVIM sont définis dans la norme [ISO/TS 19321].

    (161)Les éléments de données de l’IVIM, les trames de données de l’IVIM et les paramètres de service doivent être établis conformément au tableau 5.

    Tableau 5

    Nom

    Utilisation

    Usage

    Conteneur de gestion IVI

    Obligatoire

    serviceProviderId

    Obligatoire

    Le serviceProviderID se compose des éléments de données «countryCode» et «providerIdentifier».

    L’élément countryCode est une chaîne de bits conforme à la norme [ISO 3166-1]. Pour l’Autriche, par exemple, la chaîne de bits correspond à «AT» (code de la chaîne de bits: A (11000) et T (00001) 1100000001 conformément à la norme [ISO 14 816]).

    Avec iviIdentificationNumber, il s’agit de l’identificateur unique des messages pour la station STI-C de véhicule réceptrice.

    iviIdentificationNumber

    Obligatoire

    Ce DE est l’identificateur de la structure IVI, tel qu’attribué par le fournisseur de services. Ce composant sert d’ID du message par serviceProvider et peut être utilisé comme référence par d’autres messages connexes.

    timestamp

    Obligatoire

    Ce DE constitue l’horodatage représentant le moment auquel le message IVI est généré ou le moment de la dernière modification du contenu des messages.

    validFrom

    Obligatoire

    Ce composant peut comprendre l’heure de début de la période de validité du message. Si l’heure de début n’est pas pertinente ou si elle n’est pas connue par le système, l’élément validFrom n’apparaît pas ou est égal à l’horodatage.

    validTo

    Obligatoire

    Ce DE doit toujours être utilisé pour déterminer la validité. Une mise à jour doit être envoyée avant l’expiration du message.

    Valeur: établie par l’application

    La période de validité par défaut est définie par l’exploitant routier.

    connectedIviStructures (1..8)

    Non utilisé

    Non utilisé.

    iviStatus

    Obligatoire

    Ce composant détient le statut de la structure IVI. Ce statut peut être établi comme suit: new(0), update(1), cancellation(2) ou negation(3). Il est utilisé pour le traitement des messages.

    Conteneur de localisation géographique (GLC)

    Obligatoire

    referencePosition

    Obligatoire

    Ce DE est utilisé comme point de référence pour toutes les zones dans le GLC.

    Le point de référence IVI est le milieu de la chaussée, au niveau d’un portique, et est le premier point des définitions de zone pour les zones de pertinence et les zones de détection.

    Si elle est n’est pas connue, l’altitude peut être établie comme non disponible. Si l’altitude est fournie, il s’agit de l’altitude de la route.

    Valeur: établie par l’application

    referencePositionTime

    Non utilisé

    Non utilisé.

    referencePositionHeading

    Non utilisé

    Non utilisé

    referencePositionSpeed

    Non utilisé

    Non utilisé.

    GlcPart

    Obligatoire

    parties (1..16). Jusqu’à 16 parties peuvent être définies dans chaque GLC. Le GLC comprend au moins deux zones: une pour la pertinence et une pour la détection.

    Valeur: établie par l’application

    zoneId

    Obligatoire

    Au moins une zone de détection et une zone de pertinence doivent être fournies pour chaque message.

    laneNumber

    Facultatif

    Obligatoire si des voies uniques sont décrites dans ce conteneur de localisation. Valeur par défaut est absente (aucune information sur la voie).

    zoneExtension

    Non utilisé

    Non utilisé.

    zoneHeading

    Obligatoire

    Obligatoire

    zone

    Obligatoire

    Définition d’une zone utilisant le DF zone constitué d’un DF segment, d’un DF polygonalLine ou d’un DF computedSegment choisi.

    L’option de segment doit être utilisée avec polygonalLine en tant que ligne (construite avec deltaPosition comme pour les traces du DENM) et, de manière optionnelle, avec laneWidth (utilisé uniquement lorsqu’une voie unique est référencée dans la zone).

    Conteneur d’application IVI

    Obligatoire

    detectionZoneIds

    Obligatoire

    Liste du ou des identificateur(s) de la ou des définition(s) de la ou des zone(s) de détection, au moyen du DE Zid (1..8)

    its-Rrid

    Non utilisé

    Non utilisé.

    relevanceZoneIds

    Obligatoire

    Liste du ou des identificateur(s) de la ou des définition(s) de la ou des zone(s) de pertinence auxquels le conteneur IVI s’applique, au moyen du DE Zid (1..8)

    direction

    Obligatoire

    Sens de circulation pertinent par rapport au sens de circulation (implicitement) défini par la zone utilisant le DE direction. Toujours fixé à sameDirection(0).

    driverAwarnessZoneIds

    Non utilisé

    Non utilisé.

    minimumAwarenessTime

    Non utilisé

    Non utilisé.

    applicableLanes (1..8)

    Facultatif

    Liste des identificateurs de la ou des voie(s) auxquels le conteneur IVS s’applique en utilisant le DE LanePosition (1..8).

    iviType

    Obligatoire

    Fournit le type d’IVI (par exemple message d’avertissement en cas de danger immédiat, message réglementaire, message d’information sur le trafic) pour permettre la classification et la hiérarchisation de l’IVI à la station STI-C réceptrice.

    iviPurpose

    Non utilisé

    Non utilisé.

    laneStatus

    Facultatif

    Indique l’état de la voie [(open) ouverte, (closed) fermée, (mergeL) fusionnée à gauche, (mergeR) fusionnée à droite, par exemple] des applicableLanes.

    completeVehicleCharacteristics

    Facultatif

    completeVehicleCharacteristics doit comprendre la définition des caractéristiques des véhicules auxquels un conteneur d’application est applicable. Le composant «train» (s’il apparaît) doit comprendre les caractéristiques applicables à l’ensemble du train de véhicules.

    driverVehicleCharacteristics

    Non utilisé

    Non utilisé.

    layoutId

    Non utilisé

    Non utilisé.

    preStoredLayoutId

    Non utilisé

    Non utilisé.

    roadSignCodes

    Obligatoire

    Doit contenir la définition du code de panneau de signalisation routière. Rend possible différentes options indiquant différents catalogues de pictogrammes.

    Ce composant spécifie quels sont les panneaux de signalisation routière qui sont applicables pour une zone de pertinence. Les codes de panneaux de signalisation routière sont dépendants du schéma de classification référencé.

    Des attributs supplémentaires au code de panneaux de signalisation routière peuvent être ajoutés conformément aux dispositions des options.

    Liste des RSCode 1..4

    RSCode

    Obligatoire

    Contient layoutComponentId et un code.

    layoutComponentId

    Non utilisé

    Cette trame de données peut être utilisée pour associer le RSCode au composant de disposition de la disposition référencée.

    code

    Obligatoire

    Pour le codage des panneaux de signalisation, la norme [ISO/TS 14 823] doit être utilisée.

    ISO 14823Code

    Obligatoire

    Pour le signcoding, la norme [ISO/TS 14 823] doit être utilisée.

    Cette trame de données comprend plusieurs DF et DE.

    Elle comprend le pictogramCode (countryCode, serviceCategorycode et pictogramCategoryCode).

    Les attributs SET (section) et NOL [«number of lane» (nombre de voies)] ne sont pas pris en charge, car ils dupliquent des informations qui sont déjà prises en charge dans le conteneur d’application.

    extraText ((1..4),...)

    Facultatif

    Liste des lignes de texte associées à la liste ordonnée des codes de panneaux de signalisation routière. Chaque pièce contient le code de langue plus un texte supplémentaire de taille limitée dans la langue sélectionnée utilisant le texte du DF.

    Remarque: ce DF peut être surchargé en toute sécurité pour inclure davantage de lignes de texte.

    3.7.3.Service de topologie de voie routière (RLT)

    Le service de RLT utilise les services fournis par les entités de protocole de la couche de mise en réseau et de transport STI pour diffuser la RLT.

    Il comprend la topologie des voies pour les véhicules, les bicyclettes, le stationnement, les transports publics et les chemins pour les passages pour piétons, par exemple, ainsi que les manœuvres autorisées dans une zone d’intersection ou sur un tronçon routier. Dans le cadre d’améliorations futures, la carte numérique comprendra des descriptions topologiques supplémentaires, comme des ronds-points.

    (162)Les en-têtes du MAPEM doivent être tels que spécifiés dans la norme [ETSI TS 102 894-2].

    (163)Les éléments de données du MAPEM, les trames de données du MAPEM et les paramètres de service doivent être établis conformément au tableau 6.

    Tableau 6: Éléments de données du MAPEM

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    mapData

    DF

    Obligatoire

    **

    timeStamp

    DE

    Non utilisé

    Non utilisé.

    **

    msgIssue Revision

    DE

    Obligatoire

    Obligatoire et mis à 0. Tel que défini dans la norme [ISO TS 19091].

    **

    layerType

    DE

    Non utilisé

    Non utilisé.

    **

    layerID

    DE

    Facultatif

    Facultatif. Tel que défini dans la norme [ISO TS 19091].

    **

    intersections
    (1..32)

    DF

    Obligatoire

    IntersectionGeometryList::=SEQUENCE (SIZE(1..32)) OF IntersectionGeometry (voir le tableau 6.1)

    Obligatoire pour la Traffic Light Manouvre (TLM, manœuvre de feu de signalisation)/les services STI-C RLT

    **

    roadSegments
    (1..32)

    DF

    Non utilisé

    Non utilisé. Les éléments de données ne sont pas profilés davantage.

    **

    dataParameters

    DF

    Facultatif

    Facultatif.

    ***

    processMethod

    DE

    Non utilisé

    Non utilisé.

    ***

    processAgency

    DE

    Facultatif

    Facultatif.

    ***

    lastCheckedDate

    DE

    Facultatif

    Facultatif, selon le format aaaa-mm-jj

    ***

    geoidUsed

    DE

    Non utilisé

    Non utilisé.

    **

    restriction List
    (1..32)

    DF

    Facultatif

    RestrictionClassList::= SEQUENCE (SIZE(1..254)) OF RestrictionClassAssignment (voir le tableau 6.3).

    Facultatif.

    **

    regional

    DE

    Non utilisé

    REGION.Reg-MapData.

    Non utilisé.

    Tableau 6.1: IntersectionGeometryList -> Intersection Geometry

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    intersectionGeometry

    DF

    Obligatoire

    Obligatoire si «intersections» est utilisé.

    **

    name

    DE

    Facultatif

    Facultatif. Généralement lisible par l’homme et reconnaissable pas l’autorité routière.

    **

    id

    DF

    Obligatoire

    (IntersectionReferenceID)

    Obligatoire. Doit être le même que dans le SPATEM. L’association de «region» et d’«id» doit être unique dans un même pays.

    ***

    region

    DE

    Facultatif

    Facultatif.

    ***

    id

    DE

    Obligatoire

    Obligatoire.

    **

    revision

    DE

    Obligatoire

    Obligatoire. Le numéro de la révision doit être augmenté de 1 lors de chaque modification des MapData de l’intersection. Les numéros des révisions de SPATEM et de MAPEM doivent être identiques afin d’indiquer que la révision appropriée de MAPEM est utilisée. Tel que défini dans la norme [ISO TS 19091].

    **

    refPoint

    DF

    Obligatoire

    Obligatoire.

    ***

    lat

    DE

    Obligatoire

    Obligatoire.

    ***

    long

    DE

    Obligatoire

    Obligatoire.

    ***

    elevation

    DE

    Non utilisé

    Non utilisé. Remplacé par la RegPosition3D régionale.

    ***

    regional

    DF

    Facultatif

    REGION.Reg-Position3D.

    Facultatif. Lorsqu’elle est connue, fournir l’altitude.

    ****

    altitude

    DF

    Obligatoire

    Obligatoire. Constitué de l’altitudeValue et de l’alitudeConfidence

    *****

    altitudeValue

    DE

    Obligatoire

    Obligatoire.

    *****

    altitudeConfidence

    DE

    Facultatif

    Obligatoire; si non disponible, mettre à (15) = non disponible.

    **

    laneWidth

    DE

    Facultatif

    Facultatif.

    **

    speedLimits
    (1..9)

    DF

    Facultatif

    SpeedLimitList::= SEQUENCE (SIZE(1..9)) OF RegulatorySpeedLimit (voir le tableau 6.2).

    Facultatif.

    **

    laneSet
    (1..255)

    DF

    Obligatoire

    LaneList::= SEQUENCE (SIZE(1..255)) OF GenericLane (voir le tableau 6.4).

    Obligatoire.

    **

    preemptPriorityData
    (1..32)

    DF

    Non utilisé

    Non utilisé. Les éléments de données ne sont pas profilés davantage.

    **

    Regional

    DF

    Non utilisé

    REGION.Reg- IntersectionGeometry). Non utilisé.

    Tableau 6.2: SpeedLimitList -> RegulatorySpeedLimit

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    regulatory SpeedLimit

    DF

    Obligatoire

    Obligatoire si «speedLimits» est utilisé.

    **

    type

    DE

    Obligatoire

    Obligatoire.

    **

    speed

    DE

    Obligatoire

    Obligatoire.

    Tableau 6.3: RestrictionClassList -> RestrictionClassAssignment

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    restriction ClassAssignment

    DF

    Obligatoire

    Obligatoire si «restrictionList» est utilisé.

    **

    id

    DE

    Obligatoire

    Obligatoire.

    **

    users

    DF

    Obligatoire

    RestrictionUserTypeList::= SEQUENCE (SIZE(1..16)) OF RestrictionUserType

    Obligatoire.

    ***

    restrictionUserType

    DF

    Obligatoire

    ****

    basicType

    DE

    Facultatif

    Utilisé.

    ****

    regional
    (1..4)

    DF

    Facultatif

    REGION.Reg-RestrictionUserType-addGrpC. Facultatif pour fournir des restrictions en matière d’émissions.

    *****

    emission

    DE

    Facultatif

    Facultatif.

    Tableau 6.4: LaneList -> GenericLane

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    genericLane

    DF

    Obligatoire

    Obligatoire si «laneSet» est utilisé.

    **

    laneID

    DE

    Obligatoire

    Obligatoire.

    **

    name

    DE

    Facultatif

    Facultatif.

    **

    ingressApproach

    DE

    Facultatif

    Facultatif. Si utilisé, les approches d’entrée et de sortie du même bras présentent le même ApproachID.

    **

    egressApproach

    DE

    Facultatif

    Facultatif. Si utilisé, les approches d’entrée et de sortie du même bras présentent le même ApproachID.

    **

    laneAttributes

    DF

    Obligatoire

    Obligatoire.

    ***

    directional Use

    DE

    Obligatoire

    Obligatoire.

    ***

    sharedWith

    DE

    Obligatoire

    Obligatoire.

    Les bits étant définis comme suit: overlappingLaneDescriptionProvided(0) multipleLanesTreatedAsOneLane(1)

    -- non permis dans le profil, étant donné que toutes les voies doivent être décrites.

    otherNonMotorizedTrafficTypes(2)

    -- tiré par des chevaux, par exemple

    individualMotorizedVehicleTraffic(3)

    -- voitures particulières

    busVehicleTraffic(4)

    taxiVehicleTraffic(5)

    pedestriansTraffic(6)

    cyclistVehicleTraffic(7)

    trackedVehicleTraffic(8) pedestrianTraffic(9)
    -- utiliser 6 à la place (erreur)

    ***

    laneType

    DF

    Obligatoire

    Obligatoire. Utilisé dans les profils suivants:

    vehicle (véhicule)

    crosswalk (passage pour piétons)

    bikeLane (piste cyclable)

    trackedVehicle (véhicule à chenilles)

    -- voir la norme [ISO TS 19091] pour des exemples de passage pour piétons.

    ****

    Vehicle

    DE

    Facultatif

    Facultatif (choix).

    ****

    crosswalk

    DE

    Facultatif

    Facultatif (choix).

    ****

    bikeLane

    DE

    Facultatif

    Facultatif (choix).

    ****

    sidewalk

    DE

    Non utilisé

    Non utilisé.

    ****

    median

    DE

    Non utilisé

    Non utilisé.

    ****

    striping

    DE

    Non utilisé

    Non utilisé.

    ****

    trackedVehicle

    DE

    Facultatif

    Facultatif (choix).

    ****

    parking

    DE

    Non utilisé

    Non utilisé.

    ***

    regional

    DF

    Non utilisé

    Reg-laneAttributes. Non utilisé.

    **

    maneuvers

    DE

    Non utilisé

    Non utilisé.

    **

    nodeList

    DF

    Obligatoire

    Obligatoire.

    ***

    nodes

    (2..63)

    DF

    Obligatoire

    NodeSetXY::= SEQUENCE (SIZE(2..63)) OF NodeXY (voir le tableau 6.5)

    Obligatoire si «nodeList» est utilisé.

    L’utilisation recommandée pour les voies courbes consiste à ajouter un nœud supplémentaire lorsque la ligne centrale de la GenericLane s’écarte de plus de 0,5 m de la ligne centrale réelle.

    ***

    computed

    DF

    Non utilisé

    Non utilisé.

    **

    connectsTo
    (1..16)

    DF

    Facultatif

    ConnectsToList::= SEQUENCE (SIZE(1..16)) OF Connection (voir le tableau 6.6).

    Facultatif. Par exemple pour la ou les voie(s) de sortie non équipée(s) d’un feu de signalisation.

    **

    overlays

    DF

    Non utilisé

    Non utilisé.

    **

    regional

    DF

    Non utilisé

    REGION-Reg-GenericLane. Non utilisé (jusqu’à la publication à venir de la norme [ISO TS 19091]). Pour fournir ConnectionTrajectory-addGrpC. Pertinent pour un scénario de cas d’utilisation de manœuvre sûre à une intersection.

    Tableau 6.5: NodeSetXY -> NodeXY

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    nodeXY

    DF

    Obligatoire

    Obligatoire si «nodes» est utilisé.

    **

    delta

    DF

    Obligatoire

    Obligatoire.

    ***

    node-XY1

    DF

    Facultatif

    Facultatif (choix).

    DF composé de X et Y, tous deux obligatoires.

    ***

    node-XY2

    DF

    Facultatif

    Facultatif (choix).

    DF composé de X et Y, tous deux obligatoires.

    ***

    node-XY3

    DF

    Facultatif

    Facultatif (choix).

    DF composé de X et Y, tous deux obligatoires.

    ***

    node-XY4

    DF

    Facultatif

    Facultatif (choix).

    DF composé de X et Y, tous deux obligatoires.

    ***

    node-XY5

    DF

    Facultatif

    Facultatif (choix).

    DF composé de X et Y, tous deux obligatoires.

    ***

    node-XY6

    DF

    Facultatif

    Facultatif (choix).

    DF composé de X et Y, tous deux obligatoires.

    ***

    node-LatLon

    DF

    Non utilisé

    Non utilisé pour les intersections. Une utilisation pour les autoroutes, par exemple, est acceptable.

    ***

    regional

    DF

    Non utilisé

    REGION.Reg-NodeOffsetPointXY.

    Non utilisé.

    **

    attributes

    DF

    Facultatif

    Ce DE fournit tous les attributs facultatifs qui sont nécessaires, parmi lesquels les changements de la largeur et de l’élévation de la voie actuelle. Tous les attributs sont fournis dans l’ordre des nœuds (par opposition au sens de déplacement). Les indications gauche/droite par attributs doivent également être interprétées sur la base de l’ordre des nœuds.

    ***

    localNode

    (1..8)

    DF

    Facultatif

    NodeAttributeXYList::=

    SEQUENCE (SIZE(1..8)) OF

    NodeAttributeXY

    Facultatif. Soumis au cas. Stopline obligatoire lorsqu’elle apparaît dans le champ.

    ****

    nodeAttributeXY

    DE

    Obligatoire

    Obligatoire si «localNode» est utilisé.

    ***

    disabled

    (1..8)

    DF

    Facultatif

    SegmentAttributeXYList::=

    SEQUENCE (SIZE(1..8)) OF

    SegmentAttributeXY

    Facultatif. Soumis au cas.

    ****

    segmentAttributeXY

    DE

    Obligatoire

    Obligatoire si «disabled» est utilisé.

    ***

    enabled

    (1..8)

    DF

    Facultatif

    SegmentAttributeXYList::=

    SEQUENCE (SIZE(1..8)) OF

    SegmentAttributeXY

    Facultatif. Soumis au cas.

    ****

    segmentAttributeXY

    DE

    Obligatoire

    Obligatoire si «enabled» est utilisé.

    ***

    data

    DF

    Facultatif

    Facultatif.

    ****

    pathEndPointAngle

    DE

    Non utilisé

    Non utilisé.

    ****

    pathEndPointAngle

    DE

    Non utilisé

    Non utilisé.

    ****

    laneCrownPointCenter

    DE

    Non utilisé

    Non utilisé.

    ****

    laneCrownPointLeft

    DE

    Non utilisé

    Non utilisé.

    ****

    laneCrownPointRight

    DE

    Non utilisé

    Non utilisé.

    ****

    laneAngle

    DE

    Non utilisé

    Non utilisé.

    ****

    speedLimits (1..9)

    DE

    Facultatif

    SpeedLimitList::= SEQUENCE

    (SIZE(1..9)) OF

    RegulatorySpeedLimit

    (voir le tableau 6.2).

    Facultatif (choix).

    ****

    regional

    DF

    Non utilisé

    REGION.Reg-
    LaneDataAttribute.
    Non utilisé.

    ***

    dWidth

    DE

    Facultatif

    Facultatif.

    ***

    dElevation

    DE

    Facultatif

    Facultatif.

    ***

    regional

    DF

    Non utilisé

    REGION.Reg-NodeAttributeSetXY.
    Non utilisé.

    Tableau 6.6: ConnectsToList -> Connection

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    connection

    DF

    Facultatif

    Obligatoire si «connectsTo» est utilisé.

    **

    connectingLane

    DF

    Obligatoire

    Obligatoire.

    ***

    lane

    DE

    Obligatoire

    Obligatoire.

    ***

    maneuver

    DE

    Facultatif

    Facultatif.

    **

    remoteIntersection

    DF

    Facultatif

    Facultatif. Uniquement utilisé si l’intersection référencée fait partie du même MAPEM.

    ***

    Region

    DE

    Facultatif

    Facultatif.

    ***

    Id

    DE

    Obligatoire

    Obligatoire.

    **

    signalGroup

    DE

    Facultatif

    Facultatif, car il se peut que toutes les connexions ne disposent pas de signalgroups liés. Toutefois, pour les connexions contrôlées par un feu de signalisation, le signalgroup doit être établi.

    **

    userClass

    DE

    Facultatif

    Facultatif.

    **

    connectionID

    DE

    Obligatoire

    Obligatoire.

    3.7.4.Service TLM

    Le service TLM utilise les services fournis par les entités de protocole de la couche de mise en réseau et de transport STI pour diffuser des TLM.

    Il comprend des informations relatives à la sécurité visant à aider les participants au trafic (véhicules, piétons, etc.) à exécuter des manœuvres sûres dans une zone d’intersection. L’objectif est de pénétrer dans une zone d’intersection «conflictuelle» et d’en sortir de manière contrôlée. Le service TLM fournit des informations en temps réel sur les états opérationnels du contrôleur de feux de signalisation, l’état actuel du signal, le temps résiduel de l’état avant de passer à l’état suivant, les manœuvres autorisées et les aides au franchissement.

    (164)L’en-tête du SPATEM doit être tel que spécifié dans la norme [TS 102 894-2].

    (165)Les éléments de données du SPATEM, les trames de données et les paramètres de service doivent être établis conformément au tableau 7.

    Tableau 7: Éléments de données du SPATEM

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    Spat

    DF

    Obligatoire

    **

    timeStamp

    DE

    Facultatif

    Non utilisé, mais maintenu facultatif.

    **

    name

    DE

    Facultatif

    Non utilisé, mais maintenu facultatif.

    **

    Intersections

    (1..32)

    DF

    Obligatoire

    IntersectionStateList::= SEQUENCE (SIZE(1..32)) OF IntersectionState (voir le tableau 7.1).

    Obligatoire

    **

    regional (1..4)

    DF

    Non utilisé

    REGION.Reg-SPAT.

    Non utilisé.

    Tableau 7.1: IntersectionStateList -> IntersectionState

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    intersectionState

    DF

    Obligatoire

    **

    name

    DE

    Facultatif

    Utilisé, mais maintenu facultatif.

    Sur la base d’un schéma de numérotation utilisé par l’autorité routière.

    **

    id

    DF

    Obligatoire

    (IntersectionReferenceID)

    Obligatoire. Doit être le même que dans le MAPEM. L’association de région et d’ID doit être unique dans un même pays.

    ***

    region

    DE

    Facultatif

    Facultatif.

    ***

    id

    DE

    Obligatoire

    Obligatoire.

    **

    revision

    DE

    Obligatoire

    Obligatoire. Le numéro de la révision doit être augmenté de 1 lors de chaque modification des MapData de l’intersection. Les numéros des révisions de SPATEM et de MAPEM doivent être identiques afin d’indiquer que la révision appropriée de MAPEM est utilisée. Tel que défini dans la norme [ISO TS 19091].

    **

    status

    DE

    Obligatoire

    Obligatoire. Sont généralement utilisés sur la base de la norme EN 12675:

    manualControlIsEnabled(0);

    fixedTimeOperation(5);

    trafficDependentOperation(6);

    standbyOperation(7);

    failureMode(8).

    **

    moy

    DE

    Obligatoire

    Obligatoire. Également utilisé pour valider l’instant de référence des TimeMarks.

    **

    timeStamp

    DE

    Obligatoire

    Obligatoire.

    **

    enabledLanes

    DF

    Facultatif

    Obligatoire si le bit «revocableLane» est utilisé dans une des descriptions de voies; dans le cas inverse, non utilisé.

    **

    states

    (1..16)

    DF

    Obligatoire

    MovementList::= SEQUENCE (SIZE(1..255)) OF MovementState (voir le tableau 7.2).

    Obligatoire.

    **

    maneuverAs sistList

    (1..16)

    DF

    Non utilisé

    ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (voir le tableau 7.5).

    Non utilisé et donc non profilé davantage à ce niveau.

    **

    Regional (1..4)

    DF

    Facultatif

    REGION.Reg-IntersectionState.

    Facultatif, pour garantir l’interopérabilité avec les systèmes existants de priorité des transports publics.

    Tableau 7.2: MovementList -> MovementState

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    movementState

    DF

    Obligatoire

    Obligatoire si «states» est utilisé.

    **

    movementName

    DE

    Facultatif

    Facultatif.

    **

    signalGroup

    DE

    Obligatoire

    Obligatoire.

    **

    state-time-speed

    DF

    Obligatoire

    MovementEventList::= SEQUENCE (SIZE(1..16)) OF MovementEvent.

    Obligatoire (1-16).

    (voir le tableau 7.3).

    **

    maneuverAssistList

    (1..16)

    DF

    Facultatif

    ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (voir le tableau 7.5).

    Facultatif.

    **

    regional

    (1..4)

    DF

    Non utilisé

    REGION.Reg-MovementState.

    Non utilisé.

    Tableau 7.3: MovementEventList -> MovementEvent

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    movementEvent

    DF

    Obligatoire

    Obligatoire si «state-time-speed» est utilisé.

    **

    eventState

    DE

    Obligatoire

    Obligatoire et défini comme suit:

    (0)«unavailable» (non connu ou erreur);

    (1)«dark» (non utilisé dans l’UE);

    (2)«stop-then-Proceed» (par exemple, un feu rouge associé à un panneau de signalisation routière marqué d’une flèche verte pour indiquer un virage);

    (3)«stop-and-remain» (par exemple, un feu rouge);

    (4)«pre-Movement» (par exemple, signal rouge/orange tel qu’utilisé dans certains pays de l’UE avant un signal vert);

    (5)«permissive-Movement-Allowed» (par exemple, feu vert circulaire «plein», avec conflit de trafic potentiel, notamment lors d’un virage);

    (6)«protected-Movement-Allowed» (par exemple, feu vert en forme de «flèche», sans conflit de trafic ni piétons lors du franchissement de la zone conflictuelle);

    (7)«permissive clearance» (par exemple, feu orange circulaire «plein» indiquant qu’il convient de se préparer à l’arrêt. Utilisé après un signal «vert»);

    (8)«protected clearance» (par exemple, feu orange en forme de «flèche», signal directionnel indiquant qu’il convient de se préparer à l’arrêt. Utilisé après un signal «vert en forme de flèche»);

    (9)«caution-Conflicting-Traffic» (par exemple voyant clignotant orange; prudence, un conflit de trafic est possible dans la zone d’intersection conflictuelle).

    **

    timing

    DF

    Facultatif

    Facultatif. Par exemple, des données de minutage peuvent ne pas être disponibles lorsque «status» est mis à 0, 1 ou 9.

    Tous les TimeMarks (horodatages) sont définis comme un décalage par rapport à l’heure UTC complète (voir la norme [ISO TS 19091]) et non pour la sécurité fonctionnelle, mais pour des informations relatives au minutage du signal. «likelyTime» avec «confidence» (confiance) ou «minEndTime» avec «maxEndTime» sont toutes deux des mesures de probabilité et peuvent être utilisées de manière interchangeable selon leur disponibilité.

    ***

    startTime

    DE

    Non utilisé

    Non utilisé.

    ***

    minEndTime

    DE

    Obligatoire

    Obligatoire. Valeur préconfigurée ou calculée avec une probabilité élevée, mais parfois non disponible (36001). Dans le cas de contrôles à heure fixe, par exemple, identique à maxEndTime, ce qui indique une probabilité élevée.

    ***

    maxEndTime

    DE

    Obligatoire

    Obligatoire. Valeur préconfigurée ou calculée avec une probabilité élevée, mais parfois non disponible (36001). Dans le cas de contrôles à heure fixe, par exemple, identique à minEndTime, ce qui indique une probabilité élevée.

    ***

    likelyTime

    DE

    Facultatif

    Facultatif.

    ***

    confidence

    DE

    Facultatif

    Obligatoire si «likelyTime» est fourni.

    La définition de «confidence» (confiance) dans la norme de base n’est pas utilisable. À la place, la confiance est définie par l’écart type (sigma) du likelyTime en secondes. La valeur fournie par cet élément de données, qui se situe entre 0 et 15, représente 1 sigma (arrondi). 15 = non connu. Dès lors, le tableau de conversion avec probabilités prévu dans la norme SAE J2735 n’est pas utilisé.

    En supposant une distribution normale et un écart type de 3,6 secondes, le likelyTime est le suivant:

    de 26 à 34 secondes (1 sigma), avec une probabilité de 68,27 %;

    de 22 à 38 secondes (2 sigma), avec une probabilité de 95,44 %;

    de 18 à 42 secondes (3 sigma), avec une probabilité de 99,73 %.

    ***

    nextTime

    DE

    Facultatif

    Facultatif.

    **

    speeds

    (1..16)

    DF

    Facultatif

    AdvisorySpeedList::= SEQUENCE (SIZE(1..16)) OF AdvisorySpeed (voir le tableau 7.4).

    Facultatif.

    **

    regional

    (1..4)

    DF

    Facultatif

    REGION.Reg-MovementEvent, facultatif.

    Tableau 7.4: AdvisorySpeedList -> AdvisorySpeed

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    advisorySpeed

    DF

    Obligatoire

    Obligatoire si «speeds» est utilisé.

    **

    type

    DE

    Obligatoire

    Obligatoire.

    greenwave(1) = vitesse pour une séquence d’intersections coordonnées (répétée à chaque intersection).

    ecoDrive(2) = vitesse de l’intersection actuelle.

    transit(3) = limité à un type de véhicule spécifique.

    **

    speed

    DE

    Facultatif

    Facultatif.

    **

    confidence

    DE

    Non utilisé

    Non utilisé.

    **

    distance

    DE

    Facultatif

    Facultatif.

    Non utilisé pour greenwave(1). Dans les autres cas, la distance est spécifiée en amont de la barre d’arrêt le long de la voie d’accès.

    **

    class

    DE

    Facultatif

    Facultatif.

    **

    regional
    (1..4)

    DF

    Non utilisé

    REGION.Reg-AdvisorySpeed.

    Non utilisé.

    Tableau 7.5: ManeuverAssistList -> ConnectionManeuverAssist

    Niveau

    Nom

    Type

    Utilisation

    Usage

    *

    connection ManeuverAssist

    DF

    Obligatoire

    Obligatoire si «maneuverAssistList» est utilisé.

    **

    connectionID

    DE

    Obligatoire

    Obligatoire.

    **

    queueLength

    DE

    Facultatif

    Facultatif.

    **

    availableStorageLength

    DE

    Non utilisé

    Non utilisé.

    **

    waitOnStop

    DE

    Non utilisé

    Non utilisé.

    **

    pedBicycleDetect

    DE

    Non utilisé

    Non utilisé.

    **

    regional

    (1..4)

    DF

    Non utilisé

    REGION.Reg-ConnectionManeuverAssist.

    Non utilisé.

    Top

    TABLE DES MATIÈRES

    1.Introduction

    1.1.Aperçu et champ d’application de la présente politique

    1.2.Définitions et acronymes

    1.3.Participants à la PKI

    1.3.1.Introduction

    1.3.2.Autorité de politique de certification des STI-C

    1.3.3.Gestionnaire de la liste de confiance (TLM)

    1.3.4.Auditeur agréé de la PKI

    1.3.5.Point de contact des STI-C (CPOC)

    1.3.6.Rôles opérationnels

    1.4.Usage des certificats

    1.4.1.Domaines d’utilisation applicables

    1.4.2.Limites de responsabilité

    1.5.Administration de la politique de certification

    1.5.1.Mise à jour des CPS des CA énumérées dans l’ECTL

    1.5.2.Procédure d’approbation des CPS

    2.Responsabilités en matière de publication et de répertoires

    2.1.Méthodes de publication des informations des certificats

    2.2.Date ou fréquence de publication

    2.3.Répertoires

    2.4.Contrôles d’accès sur les répertoires

    2.5.Publication des informations des certificats

    2.5.1.Publication des informations des certificats par le TLM

    2.5.2.Publication des informations des certificats par les CA

    3.Identification et authentification

    3.1.Nommage

    3.1.1.Types de nom

    3.1.1.1.Noms pour les TLM, les CA racine, les EA et les AA

    3.1.1.2.Noms des entités finales

    3.1.1.3.Identification des certificats

    3.1.2.Nécessité d’utiliser des noms explicites

    3.1.3.Anonymat et emploi de pseudonymes pour les entités finales

    3.1.4.Règles d’interprétation des diverses formes de noms

    3.1.5.Unicité des noms

    3.2.Validation initiale de l’identité

    3.2.1.Méthode visant à prouver la possession d’une clé privée

    3.2.2.Authentification de l’identité d’une organisation

    3.2.2.1.Authentification de l’identité d’une organisation de CA racine

    3.2.2.2.Authentification de l’identité d’une organisation de TLM

    3.2.2.3.Authentification de l’identité d’une organisation de sous-CA

    3.2.2.4.Authentification de l’organisation du souscripteur des entités finales

    3.2.3.Authentification de l’entité individuelle

    3.2.3.1.Authentification de l’entité individuelle du TLM/de la CA

    3.2.3.2.Authentification de l’identité du souscripteur des stations STI-C

    3.2.3.3.Authentification de l’identité des stations STI-C

    3.2.4.Renseignements non vérifiés sur le souscripteur

    3.2.5.Validation de l’autorité

    3.2.5.1.Validation du TLM, de la CA racine, de l’EA et de l’AA

    3.2.5.2.Validation des souscripteurs de la station STI-C

    3.2.5.3.Validation des stations STI-C

    3.2.6.Critères d’interopérabilité

    3.3.Identification et authentification des demandes de régénération de clés

    3.3.1.Identification et authentification pour régénération de clé courante

    3.3.1.1.Certificats du TLM

    3.3.1.2.Certificats de la CA racine

    3.3.1.3.Régénération de clé ou renouvellement du certificat d’EA /AA

    3.3.1.4.Authentifiants d’inscription des entités finales

    3.3.1.5.Tickets d’autorisation des entités finales

    3.3.2.Identification et authentification pour régénération de clés après révocation

    3.3.2.1.Certificats de CA

    3.3.2.2.Authentifiants d’inscription des entités finales

    3.3.2.3.Demandes d’autorisation des entités finales

    3.4.Identification et authentification des demandes de révocation

    3.4.1.Certificats de CA racine/EA /AA

    3.4.2.Authentifiants d’inscription de la station STI-C

    3.4.3.Tickets d’autorisation de la station STI-C

    4.Exigences opérationnelles du cycle de vie des certificats

    4.1.Demande de certificat

    4.1.1.Qui peut présenter une demande de certificat

    4.1.1.1.CA racine

    4.1.1.2.TLM

    4.1.1.3.EA et AA

    4.1.1.4.Station STI-C

    4.1.2.Processus d’inscription et responsabilités

    4.1.2.1.CA racine

    4.1.2.2.TLM

    4.1.2.3.EA et AA

    4.1.2.4.Station STI-C

    4.2.Traitement des demandes de certificat

    4.2.1.Exécution des fonctions d’identification et d’authentification

    4.2.1.1.Identification et authentification des CA racine

    4.2.1.2.Identification et authentification du TLM

    4.2.1.3.Identification et authentification de l’EA et l’AA

    4.2.1.4.Identification et authentification du souscripteur EE

    4.2.1.5.Tickets d’autorisation

    4.2.2.Approbation ou rejet des demandes de certificat

    4.2.2.1.Approbation ou rejet des certificats de la CA racine

    4.2.2.2.Approbation ou rejet du certificat du TLM

    4.2.2.3.Approbation ou rejet des certificats de l’EA et de l’AA

    4.2.2.4.Approbation ou rejet de l’EC

    4.2.2.5.Approbation ou rejet de l’AT

    4.2.3.Délai de traitement des demandes de certificat

    4.2.3.1.Demande de certificat de CA racine

    4.2.3.2.Demande de certificat du TLM

    4.2.3.3.Demande de certificat de l’EA et de l’AA

    4.2.3.4.Demande d’EC

    4.2.3.5.Demande d’AT

    4.3.Délivrance des certificats

    4.3.1.Tâches de la CA lors de la délivrance des certificats

    4.3.1.1.Délivrance de certificat par la CA racine

    4.3.1.2.Délivrance de certificat du TLM

    4.3.1.3.Délivrance de certificat d’EA et AA

    4.3.1.4.Délivrance de l’EC

    4.3.1.5.Délivrance d’AT

    4.3.2.Notification au souscripteur de la délivrance des certificats par la CA

    4.4.Acceptation des certificats

    4.4.1.Acceptation des certificats

    4.4.1.1.CA racine

    4.4.1.2.TLM

    4.4.1.3.EA et AA

    4.4.1.4.Station STI-C

    4.4.2.Publication du certificat

    4.4.3.Notification de la délivrance des certificats

    4.5.Utilisation des paires de clés et des certificats

    4.5.1.Utilisation de la clé privée et du certificat

    4.5.1.1.Utilisation de la clé privée et du certificat pour le TLM

    4.5.1.2.Utilisation de la clé privée et du certificat pour les CA racine

    4.5.1.3.Utilisation de la clé privée et du certificat pour les EA et les AA

    4.5.1.4.Utilisation de la clé privée et du certificat pour l’entité finale

    4.5.2.Utilisation du certificat et de la clé publique par une partie utilisatrice

    4.6.Renouvellement de certificat

    4.7.Régénération de clés de certificat

    4.7.1.Circonstances de la régénération des clés de certificat

    4.7.2.Qui peut demander la régénération

    4.7.2.1.CA racine

    4.7.2.2.TLM

    4.7.2.3.EA et AA

    4.7.2.4.station STI-C

    4.7.3.Traitement des demandes de régénération des clés de certificat

    4.7.3.1.Certificat du TLM

    4.7.3.2.Certificat de CA racine

    4.7.3.3.certificats d’EA et d’AA

    4.7.3.4.Certificats de la station STI-C

    4.8.Modification d’un certificat

    4.9.Révocation et suspension de certificat

    4.10.Services d’état des certificats

    4.10.1.Caractéristiques opérationnelles

    4.10.2.Disponibilité du service

    4.10.3.Caractéristiques optionnelles

    4.11.Fin de la souscription

    4.12.Séquestre et récupération des clés

    4.12.1.Souscripteur

    4.12.1.1.Quelles paires de clés peuvent être mises sous séquestre

    4.12.1.2.Qui peut présenter une demande de récupération

    4.12.1.3.Processus de récupération et responsabilités

    4.12.1.4.Identification et authentification

    4.12.1.5.Approbation ou rejet des demandes de récupération

    4.12.1.6.Actions KEA et KRA pendant la récupération de la paire de clés

    4.12.1.7.Disponibilité de KEA et KRA

    4.12.2.Politique et pratiques d’encapsulation et de récupération des clés de session

    5.Installation, gestion et contrôles opérationnels

    5.1.Contrôles physiques

    5.1.1.Emplacement et construction des installations

    5.1.1.1.CA racine, CPOC, TLM

    5.1.1.2.EA/AA

    5.1.2.Accès physique

    5.1.2.1.CA racine, CPOC, TLM

    5.1.2.2.EA/AA

    5.1.3.Alimentation électrique et climatisation

    5.1.4.Exposition à l’eau

    5.1.5.Prévention et protection contre les incendies

    5.1.6.Gestion des supports

    5.1.7.Élimination des déchets

    5.1.8.Sauvegarde hors site

    5.1.8.1.CA racine, CPOC et TLM

    5.1.8.2.EA/AA

    5.2.Contrôles des procédures

    5.2.1.Rôles de confiance

    5.2.2.Nombre de personnes requises par tâche

    5.2.3.Identification et authentification pour chaque rôle

    5.2.4.Rôles nécessitant une séparation des tâches

    5.3.Contrôles du personnel

    5.3.1.Exigences en matière de qualifications, d’expérience et d’habilitation de sécurité

    5.3.2.Procédures de vérification des antécédents

    5.3.3.Exigences en matière de formation

    5.3.4.Fréquence et exigences en matière de recyclage

    5.3.5.Fréquence et séquence de rotation des postes

    5.3.6.Sanctions pour des actions non autorisées

    5.3.7.Exigences concernant les contractants indépendants

    5.3.8.Documentation fournie au personnel

    5.4.Procédures relatives aux journaux d’audit

    5.4.1.Types d’événements à enregistrer et à signaler par chaque CA

    5.4.2.Fréquence de traitement des journaux

    5.4.3.Période de conservation des journaux d’audit

    5.4.4.Protection des journaux d’audit

    5.4.5.Procédures de sauvegarde des journaux d’audit

    5.4.6.Système de collecte des audits (interne ou externe)

    5.4.7.Notification du sujet ayant causé un événement

    5.4.8.Évaluation des vulnérabilités

    5.5.Archivage des enregistrements

    5.5.1.Types d’enregistrements archivés

    5.5.2.Période de conservation des archives

    5.5.3.Protection des archives

    5.5.4.Archives système et stockage

    5.5.5.Exigences d’horodatage des enregistrements

    5.5.6.Système de collecte des archives (interne ou externe)

    5.5.7.Procédures d’obtention et de vérification des informations archivées

    5.6.Changement de clés pour les éléments du modèle de confiance des STI-C

    5.6.1.TLM

    5.6.2.CA racine

    5.6.3.Certificat d’EA/AA

    5.6.4.Auditeur

    5.7.Compromission et reprise après sinistre

    5.7.1.Traitement des incidents et des compromissions

    5.7.2.Corruption des ressources informatiques, des logiciels et/ou des données

    5.7.3.Procédures en cas de compromission de la clé privée d’une entité

    5.7.4.Capacités en matière de continuité des activités après un sinistre

    5.8.Cessation et transfert

    5.8.1.TLM

    5.8.2.CA racine

    5.8.3.EA/AA

    6.Contrôles techniques de sécurité

    6.1.Génération et installation des paires de clés

    6.1.1.TLM, CA racine, EA et AA

    6.1.2.EE — station STI-C mobile

    6.1.3.EE — station STI-C fixe

    6.1.4.Exigences cryptographiques

    6.1.4.1.Algorithme et longueur de la clé - algorithmes de signature

    6.1.4.2.Algorithme et longueur de la clé - algorithmes de chiffrement pour l’inscription et l’autorisation

    6.1.4.3.Crypto-agilité

    6.1.5.Stockage sécurisé de clés privées

    6.1.5.1.Niveau CA racine, sous-CA et TLM

    6.1.5.2.Entité finale

    6.1.6.Sauvegarde de clés privées

    6.1.7.Destruction de clés privées

    6.2.Données d’activation

    6.3.Contrôles de sécurité informatique

    6.4.Contrôles techniques tout au long du cycle de vie

    6.5.Contrôles de sécurité du réseau

    7.Profils de certificats, CRL et ECTL

    7.1.Profil de certificats

    7.2.Validité des certificats

    7.2.1.Certificats de pseudonymes

    7.2.2.Tickets d’autorisation pour les stations STI-C fixes

    7.3.Révocation de certificats

    7.3.1.Révocation de certificats de la CA, l’EA et l’AA

    7.3.2.Révocation de certificats d’inscription

    7.3.3.Révocation de tickets d’autorisation

    7.4.Liste de révocation de certificats

    7.5.Liste de confiance européenne des certificats

    8.Vérification de la conformité et autres évaluations

    8.1.Sujets faisant l’objet d’audits et fondement des audits

    8.2.Fréquence des audits

    8.3.Identité/qualifications de l’auditeur

    8.4.Lien entre l’auditeur et l’entité soumise à audit

    8.5.Mesures prises à la suite du constat de lacunes

    8.6.Communication des résultats

    9.Autres dispositions

    9.1.Redevances

    9.2.Responsabilité financière

    9.3.Confidentialité des informations opérationnelles

    9.4.Plan en matière de protection de la vie privée

    10.Références



    ANNEXE III

    1.Introduction

    1.1.Aperçu et champ d’application de la présente politique

    La présente politique de certification définit le modèle de confiance européen des STI-C sur la base de l’infrastructure à clés publiques (PKI) dans le cadre du système de l’UE pour la gestion des authentifiants de sécurité des services STI-C (CCMS de l’UE). Elle définit les exigences de gestion des certificats de clé publique pour les applications STI-C par les entités qui les ont délivrés et leur usage par les entités finales en Europe. À son plus haut niveau, la PKI est composée d’un ensemble de CA racine «activées» à la suite de l’insertion par le gestionnaire de la liste de confiance (TLM) des certificats dans une liste de confiance européenne des certificats  (ECTL), qui est établie et publiée par le TLM de l’entité centrale (voir sections  1.2 et 1.3).

    La politique est contraignante pour l’ensemble des entités participant au système de confiance des STI-C en Europe. Elle est utile pour l’évaluation du niveau de confiance que tout récepteur d’un message authentifié par un certificat d’entité finale de la PKI peut accorder aux informations reçues. Pour permettre l’évaluation de la confiance dans les certificats fournis par le CCMS de l’UE, la politique énonce une série contraignante d’exigences pour le fonctionnement du TLM de l’entité centrale et l’établissement et la gestion de l’ECTL. Par conséquent, le présent document régit les aspects suivants liés à l’ECTL:

    ·identification et authentification des donneurs d’ordre obtenant les rôles de PKI pour le TLM, y compris des déclarations des privilèges octroyés à chaque rôle;

    ·exigences minimales relatives aux pratiques de sécurité locale pour le TLM, notamment les contrôles physiques, du personnel et des procédures;

    ·exigences minimales relatives aux pratiques de sécurité technique pour le TLM, y compris les contrôles techniques de sécurité informatique, de sécurité réseau et des modules cryptographiques;

    ·exigences minimales relatives aux pratiques opérationnelles pour le TLM, y compris l’enregistrement de nouveaux certificats de CA racine, la radiation temporaire ou permanente des CA racine existantes incluses, et la publication et la répartition des mises à jour de l’ECTL;

    ·un profil ECTL, y compris tous les champs de données obligatoires et optionnels dans l’ECTL, les algorithmes cryptographiques à utiliser, le format ECTL exact et les recommandations pour le traitement de l’ECTL;

    ·gestion du cycle de vie des certificats ECTL, y compris la répartition des certificats ECTL, leur activation, leur expiration et leur révocation;

    ·gestion de la révocation de la confiance des CA racine si nécessaire.

    Étant donné que la fiabilité de l’ECTL ne dépend pas uniquement de l’ECTL en elle-même mais aussi, dans une large mesure, des CA racine qui composent la PKI et leurs sous-CA, la présente politique énonce également des exigences minimales, qui sont impératives pour toutes les CA participantes (CA racine et sous-CA). Les exigences sont les suivantes:

    ·identification et authentification des donneurs d’ordre obtenant les rôles de la PKI (par exemple, agent de sécurité, agent chargé de la protection de la vie privée, administrations chargées de la sécurité, administrateur de registre et utilisateur final), y compris une déclaration des tâches, des responsabilités, des engagements et des privilèges associés à chaque rôle;

    ·gestion des clés, y compris des algorithmes de signature de données et de signature de certificats acceptables et obligatoires, et des périodes de validité des certificats;

    ·exigences minimales relatives aux pratiques de sécurité locale, notamment des contrôles physiques, du personnel et des procédures;

    ·exigences minimales relatives aux pratiques de sécurité technique, telles que les contrôles techniques de sécurité informatique, de sécurité réseau et des modules cryptographiques;

    ·exigences minimales relatives aux pratiques opérationnelles de la CA, l’EA, l’AA et des entités finales, y compris les aspects liés à l’enregistrement, l’annulation de l’enregistrement (c’est-à-dire la radiation), la révocation, la compromission des clés, le licenciement motivé, la mise à jour du certificat, les pratiques de vérification et la non-divulgation des informations relatives à la vie privée;

    ·certificat et profil de la CRL, y compris les formats, les algorithmes acceptables, les champs de données obligatoires et optionnels et leur plage de valeurs valides, ainsi que la manière dont les vérificateurs doivent traiter les certificats;

    ·opérations régulières de suivi, notification, alerte et tâches de rétablissement des entités du modèle de confiance des STI-C afin d’établir un fonctionnement sécurisé, y compris en cas de comportement répréhensible.

    Outre ces exigences minimales, les entités qui gèrent les CA racine et les sous-CA peuvent décider de leurs propres exigences supplémentaires et les établir dans les déclarations de pratiques de certification (CPS) concernées, à condition qu’elles ne contredisent pas les exigences établies dans la politique de certification (CP). Voir section 1.5 pour obtenir des précisions sur la manière dont les CPS sont vérifiées et publiées.

    La CP énonce également les fins auxquelles les CA racine, les sous-CA et leurs certificats délivrés peuvent être utilisés. Elle présente les engagements assumés par:

    ·le TLM;

    ·chaque CA racine dont les certificats sont énumérés dans l’ECTL;

    ·les sous-CA de la CA racine (EA et AA);

    ·chaque membre ou organisation responsable ou gestionnaire de l’une des entités du modèle de confiance des STI-C.

    La CP définit également les obligations impératives s’appliquant:

    ·au TLM;

    ·chaque CA racine dont les certificats sont énumérés dans l’ECTL;

    ·à chaque sous-CA certifié par une CA racine;

    ·à l’ensemble des entités finales;

    ·à chaque membre ou organisation responsable ou gestionnaire de l’une des entités du modèle de confiance des STI-C.

    Enfin, la CP établit les exigences relatives à la documentation des limitations des responsabilités et obligations figurant dans la CPS de chaque CA racine dont les certificats sont énumérés dans l’ECTL.

    La présente CP est conforme à la politique de certification et au cadre de pratiques de certification adoptés par l’Internet Engineering Task Force (IETF) [3].

    1.2.Définitions et acronymes

    Les définitions de [2], [3] et [4] sont applicables.

    AA

    Autorité d’autorisation (authorisation authority)

    AT

    Ticket d’autorisation (authorisation ticket)

    CA

    Autorité de certification (certification authority)

    CP

    Politique de certification (certificate policy)

    CPA

    Autorité de politique de certification des STI-C (C-ITS certificate policy authority)

    CPOC

    Point de contact STI-C (C-ITS point of contact)

    CPS

    Déclaration de pratiques de certification (certificate practice statement)

    CRL

    Liste de révocation de certificats (certificate revocation list)

    EA

    Autorité d’inscription (enrolment authority)

    EC

    Authentifiant d’inscription (enrolment credential)

    ECIES

    Système de chiffrement intégré à base de courbes elliptiques (Elliptic curve integrated encryption scheme)

    EE

    Entité finale (station STI-C par exemple) (end-entity)

    ECTL

    Liste de confiance européenne des certificats (European certificate trust list)

    CCMS de l’UE

    Système de l’UE pour la gestion des authentifiants de sécurité des services STI-C (EU C-ITS security credential management system)

    RGPD

    Règlement général sur la protection des données

    HSM

    Module matériel de sécurité (Hardware security module)

    PKI

    Infrastructure à clés publiques (public key infrastructure)

    RA

    Autorité d’enregistrement (registration authority)

    sous-CA

    EA et AA

    TLM

    Gestionnaire de liste de confiance (trust list manager)



    Glossaire

    demandeur

    La personne physique ou l’entité juridique qui demande un certificat ou le renouvellement de ce dernier. Lorsque le certificat initial est créé (initialisation), le demandeur est désigné comme étant le souscripteur.

    Pour les certificats délivrés aux entités finales, le souscripteur (demandeur du certificat) est l’entité chargée de contrôler ou de diriger/maintenir l’entité finale à laquelle le certificat est délivré, même si l’entité finale envoie la demande effective de certificat.

    autorité d’autorisation

    Dans le présent document, le terme «autorité d’autorisation» (AA) fait référence non seulement à la fonction spécifique de l’AA, mais également à l’entité juridique et/ou opérationnelle qui la gère.

    autorité de certification

    l’autorité de certification racine, l’autorité d’inscription et l’autorité d’autorisation sont conjointement désignées sous la dénomination «autorité de certification» (CA).

    modèle de confiance des STI-C

    Le modèle de confiance des STI-C est chargé d’établir une relation de confiance entre les stations STI-C. Il est mis en œuvre au moyen d’une PKI composée des CA racine, du CPOC, du TLM, des EA, des AA et d’un réseau sécurisé.

    crypto-agilité

    La capacité des entités du modèle de confiance des STI-C à adapter la CP aux environnements changeants ou à de nouvelles exigences futures, par exemple grâce à un changement des algorithmes cryptographiques et de la longueur de clé au fil du temps.

    module cryptographique

    Un élément sécurisé basé sur le matériel informatique au sein duquel des clés sont générées et/ou stockées, des nombres aléatoires sont générés et des données sont signées ou chiffrées.

    autorité d’inscription

    Dans le présent document, le terme «autorité d’inscription» (EA) fait référence non seulement à la fonction spécifique de l’EA, mais également à l’entité juridique et/ou opérationnelle qui la gère.

    participants à la PKI

    entités du modèle de confiance des STI-C, à savoir le TLM, les CA racine, les EA, les AA et les stations STI-C.

    régénération de la clé

    Ce sous-composant est utilisé pour décrire certains éléments liés à un souscripteur ou à un autre participant générant une nouvelle paire de clés et demandant la délivrance d’un nouveau certificat attestant la nouvelle clé publique, conformément à la description figurant à [3].

    répertoire

    Le répertoire utilisé pour le stockage des certificats et des informations figurant sur les certificats fournis par les entités du modèle de confiance des STI-C, tel que défini à la section 2.3.

    autorité de certification racine

    Dans le présent document, le terme «autorité de certification racine» (CA) fait référence non seulement à la fonction spécifique de la CA, mais également à l’entité juridique et/ou opérationnelle qui la gère.

    sujet

    La personne physique, le dispositif, le système, l’unité ou l’entité juridique indiquée dans un certificat comme étant le sujet, à savoir soit le souscripteur soit un dispositif contrôlé et exploité par le souscripteur.

    souscripteur

    Une personne physique ou une entité juridique à laquelle est délivré un certificat et qui est légalement liée par un accord de souscription ou sur les conditions d’utilisation.

    Accord de souscription

    Un accord entre la CA et le demandeur/le souscripteur qui spécifie les droits et responsabilités des parties.

    1.3.Participants à la PKI

    1.3.1.Introduction

    Les participants à la PKI jouent un rôle dans la PKI définie par la présente politique. À moins que cela ne soit explicitement interdit, un participant peut jouer plusieurs rôles en même temps. Jouer plusieurs rôles en même temps peut être interdit afin d’éviter des conflits d’intérêts ou de garantir la séparation des tâches.

    Les participants peuvent également déléguer une partie de leurs rôles à d’autres entités dans le cadre d’un contrat de service. Par exemple, lorsque des informations sur l’état de révocation sont fournies au moyen de CRL, la CA est également l’émetteur de la CRL, mais elle peut déléguer la responsabilité de délivrer les CRL à une autre entité.

    Les rôles de la PKI consistent en:

    ·des rôles d’autorité (chaque rôle est instancié de façon unique);

    ·des rôles opérationnels (des rôles pouvant être instanciés dans une ou plusieurs entités).

    Par exemple, une CA racine peut être mise en œuvre par une entité commerciale, un groupe d’intérêt commun, une organisation nationale et/ou une organisation européenne.

    La figure 1 montre l’architecture du modèle de confiance des STI-C sur la base de [2]. L’architecture est brièvement décrite ici, mais les principaux éléments sont décrits de façon plus détaillée aux sections  1.3.2 à 1.3.6.

    La CPA nomme le TLM, qui est donc une entité de confiance pour l’ensemble des participants à la PKI. La CPA approuve le fonctionnement de la CA racine et confirme que le TLM peut faire confiance à la/aux CA racine. Le TLM délivre l’ECTL qui permet à tous les participants à la PKI de faire confiance aux CA racine approuvées. La CA racine délivre des certificats aux EA et AA, ce qui permet de se fier à leur fonctionnement. L’EA délivre des certificats d’inscription aux stations STI-C émettrices et de relais (en tant qu’entités finales), ce qui permet de se fier à leur fonctionnement. L’AA délivre des AT aux stations STI-C sur la base de la confiance dans l’EA.

    La station STI-C réceptrice et de relais (en tant que partie de relais) peut faire confiance à d’autres stations STI-C, étant donné que les AT sont délivrés par une AA à laquelle une CA racine fait confiance, cette CA racine bénéficiant également de la confiance du TLM et de la CPA.

    Il convient de noter que la  Figure 1 décrit uniquement le niveau de la CA racine du modèle de confiance des STI-C. Des détails relatifs aux couches inférieures sont fournis dans les sections suivantes de la présente CP ou dans les CPS des CA racine spécifiques.

    La Figure 2 offre un aperçu des flux d’informations entre les participants à la PKI. Les points verts indiquent des flux nécessitant des communications entre machines. Les flux d’informations en rouge ont des exigences de sécurité particulières.

    Le modèle de confiance des STI-C repose sur une architecture de CA racine multiple, où les certificats de CA racine sont transmis régulièrement (comme établi ci-après) au point de contact central (CPOC) au moyen d’un protocole sécurisé (par exemple des certificats de lien) défini par le CPOC.

    Une CA racine peut être exploitée par une organisation publique ou privée. L’architecture du modèle de confiance des STI-C contient au moins une CA racine (la CA racine de l’UE avec le même niveau que les autres CA racine). La CA racine de l’UE est déléguée par l’ensemble des entités qui participent au modèle de confiance des STI-C et ne souhaitent pas mettre en place leur propre CA racine. Le CPOP transmet les certificats de CA racine reçus au TLM, qui est chargé de les recueillir et de signer la liste des certificats de CA racine ainsi que de les renvoyer au CPOC, qui les rend universellement accessibles (voir ci-après).

    Les relations de confiance entre les entités dans le modèle de confiance des STI-C sont décrites aux figures, tableaux et sections ci-après.

    Figure 1: Architecture du modèle de confiance des STI-C

    Figure 2: Flux d’informations du modèle de confiance des STI-C



    Numéro d’identification du flux

    De

    À

    Contenu

    Référence

    (1).

    CPA

    TLM

    approbation de la demande de CA racine

    8

    (2).

    CPA

    TLM

    informations relatives à la révocation de la CA racine

    8.5

    (3).

    CPA

    CA racine

    mises à jour de la CP

    1.5

    (4).

    CPA

    CA racine

    Approbation/rejet du formulaire de demande de CA racine ou des changements de la demande de CPS ou du processus de vérification.

    8.5, 8.6

    (5).

    TLM

    CPA

    notification de changement de l’ECTL

    4, 5.8.1

    (6).

    TLM

    CPOC

    Certificat du TLM

    4.4.2

    (7).

    TLM

    CPOC

    ECTL

    4.4.2

    (8).

    CPOC

    TLM

    informations du certificat de CA racine

    4.3.1.1

    (9).

    CPOC

    TLM

    révocation du certificat de CA racine

    7.3

    (10).

    CPOC

    toutes les entités finales

    Certificat du TLM

    4.4.2

    (11).

    CA racine

    CPOC

    informations du certificat de CA racine

    4.3.1.1

    (12).

    CA racine

    CPOC

    révocation du certificat de CA racine

    7.3

    (13).

    CA racine

    Auditeur

    Commande d’audit

    8

    (14).

    CA racine

    CPA

    formulaire de demande de CA racine — demande initiale

    4.1.2.1

    (15).

    CA racine

    CPA

    formulaire de demande de CA racine — changements de CPS

    1.5.1

    (16).

    CA racine

    CPA

    formulaire de demande de CA racine — rapport d’audit

    8.6

    (17).

    CA racine

    CPA

    rapports d’incidents de la CA racine, y compris la révocation d’une sous-CA (EA, AA)

    Annexe III, 7.3.1

    (18).

    CA racine

    EA

    réponse de certificat d’EA

    4.2.2.3

    (19).

    CA racine

    AA

    réponse de certificat d’AA

    4.2.2.3

    (20).

    CA racine

    Tous

    certificat d’EA/AA, CRL

    4.4.2

    (21).

    EA

    CA racine

    demande de certificat d’EA

    4.2.2.3

    (22).

    EA

    station STI-C

    réponse d’authentifiant d’inscription

    4.3.1.4

    (23).

    EA

    AA

    réponse d’autorisation

    4.2.2.5

    (24).

    AA

    CA racine

    demande de certificat d’AA

    4.2.2.3

    (25).

    AA

    EA

    demande d’autorisation

    4.2.2.5

    (26).

    AA

    station STI-C

    réponse de ticket d’autorisation

    4.3.1.5

    (27).

    EA

    CA racine

    présentation de demande

    4.1.2.3

    (28).

    AA

    CA racine

    présentation de demande

    4.1.2.3

    (29).

    CA racine

    EA

    réponse

    4.12 et 4.2.1

    (30).

    CA racine

    AA

    réponse

    4.12 et 4.2.1

    (31).

    station STI-C

    EA

    demande d’authentifiant d’inscription

    4.2.2.4

    (32).

    station STI-C

    AA

    demande de ticket d’autorisation

    4.2.2.5

    (33).

    fabricant/exploitant

    EA

    enregistrement

    4.2.1.4

    (34).

    fabricant/exploitant

    EA

    désactivation

    7.3

    (35).

    EA

    fabricant/exploitant

    réponse

    4.2.1.4

    (36).

    auditeur

    CA racine

    rapport

    8.1

    (37).

    tous

    CPA

    demandes de changement de la CP

    1.5

    (38).

    TLM

    CPA

    formulaire de demande

    4.1.2.2

    (39).

    CPA

    TLM

    approbation/rejet

    4.1.2.2

    (40).

    TLM

    CPA

    rapport d’audit

    4.1.2.2

    Tableau 1:    Description détaillée des flux d’informations dans le modèle de confiance des STI-C

    1.3.2.Autorité de politique de certification des STI-C

    (1)L’autorité de politique de certification (CPA) des STI-C est composée des représentants des parties prenantes publiques et privées (par exemple, les États membres, les constructeurs de véhicules, etc.) participant au modèle de confiance des STI-C. Elle est responsable de deux sous-rôles:

    (1)la gestion de la politique de certification, notamment:

    ·l’approbation des demandes de modification des CP actuelle et future;

    ·la décision d’examiner les demandes de modification de la CP et les recommandations soumises par d’autres entités ou participants à la PKI;

    ·la décision de publier de nouvelles versions de la CP;

    (2)la gestion de l’autorisation de la PKI, notamment:

    ·la définition, la décision et la publication des procédures d’approbation des CPS et d’audit des CA (désignées collectivement sous la dénomination «procédures d’approbation des CA»);

    ·l’autorisation du CPOC à agir et à présenter des rapports de façon régulière;

    ·l’autorisation du TLM à agir et à présenter des rapports de façon régulière;

    ·l’approbation de la CPS des CA racine, si elle est conforme à la CP commune et valide;

    ·l’examen des rapports de l’auditeur agréé d’une PKI pour l’ensemble des CA racine;

    ·la notification au TLM de la liste de CA racine approuvées ou non et de leurs certificats sur la base des rapports d’approbation reçus des CA racine et des rapports réguliers sur le fonctionnement.

    (2)Le mandataire de la CPA est chargé de l’authentification du mandataire du TLM et de l’approbation du formulaire de demande de processus d’inscription du TLM. La CPA est chargée d’autoriser le TLM à agir comme mentionné dans la présente section.

    1.3.3.Gestionnaire de la liste de confiance (TLM)

    (3)Le TLM est une entité unique nommée par la CPA.

    (4)Le TLM est chargé:

    ·du fonctionnement de l’ECTL conformément à la CP commune valide et de rapports réguliers à la CPA pour le fonctionnement global sécurisé du modèle de confiance des STI-C;

    ·De la réception de certificats de CA racine émanant du CPOC;

    ·de l’inclusion dans l’ECTL/l’exclusion de l’ECTL de certificats de CA racine dès la notification de la CPA;

    ·de la signature de l’ECTL;

    ·de la transmission régulière et en temps utile de l’ECTL au CPOC.

    1.3.4.Auditeur agréé de la PKI

    (5)L’auditeur agréé de la PKI est chargé de:

    ·réaliser ou organiser les audits des CA racine, du TLM et des sous-CA;

    ·transmettre le rapport d’audit à la CPA (à partir d’un audit initial ou périodique) conformément aux exigences établies à la section 8 ci-après. Le rapport d’audit doit inclure les recommandations de l’auditeur agréé de la PKI;

    ·notifier à l’entité qui gère la CA racine de l’exécution réussie ou non d’un audit initial ou périodique des sous-CA;

    ·évaluer la conformité des CPS à la présente CP.

    1.3.5.Point de contact des STI-C (CPOC)

    (6)Le CPOC est une entité unique nommée par la CPA. Le mandataire de la CPA est chargé de l’authentification du mandataire du CPOC et de l’approbation du formulaire de demande de processus d’inscription du CPOC. La CPA est chargée d’autoriser le CPOC à agir comme établi dans la présente section.

    (7)Le CPOC est chargé:

    ·d’établir l’échange de communication sécurisé entre l’ensemble des entités du modèle de confiance des STI-C et d’y contribuer de manière rapide et efficace;

    ·d’examiner les demandes de changement de procédure et les recommandations soumises par d’autres participants au modèle de confiance (par exemple les CA racine);

    ·de transmettre les certificats de CA racine au TLM;

    ·de publier le certificat approuvé commun («trust anchor») (clé publique actuelle et certificat de lien du TLM);

    ·de publier l’ECTL.

    Tous les détails concernant l’ECTL figurent à la section 7.

    1.3.6.Rôles opérationnels

    (8)Les entités suivantes définies à [2] jouent un rôle opérationnel, tel que défini dans le RFC 3647:

    Élément fonctionnel

    Rôle dans la PKI ([3] et [4])

    Rôle détaillé ([2])

    autorité de certification racine

    CA/RA (autorité d’enregistrement)

    Apporte à l’EA et à l’AA la preuve qu’elles peuvent délivrer des EC ou des AT

    Autorité d’inscription

    Souscripteur à la CA racine/sujet du certificat de l’EA

    CA/RA

    Authentifie une station STI-C et lui donne accès aux communications STI

    Autorité d’autorisation

    Souscripteur à la CA racine/sujet du certificat de l’AA

    CA/RA

    Fournit à une station STI-C la preuve faisant autorité qu’elle peut utiliser des services STI spécifiques

    Station STI-C émettrice

    Sujet d’un certificat (EC) d’entité finale (EE)

    Acquiert des droits auprès de l’EA pour avoir accès aux communications STI

    Négocie des droits auprès de l’AA pour invoquer les services STI

    Envoie des messages de diffusion relayés et à un seul bond

    station STI-C de relais (transfert)

    Partie relais/ sujet du certificat d’EE

    Reçoit des messages de diffusion provenant de la station STI-C émettrice et les transfère à la station STI-C réceptrice si nécessaire

    Station STI-C réceptrice

    Partie relais

    Reçoit des messages de diffusion provenant de la station STI-C émettrice ou de relais

    Fabricant

    Souscripteur de l’EA

    Établit les informations nécessaires pour la gestion de la sécurité dans la station STI-C lors de la production

    Exploitant

    Souscripteur de l’EA/AA

    Organise et met à jour les informations nécessaires pour la gestion de la sécurité dans la station STI-C lors du fonctionnement.

    Tableau 2: Rôles opérationnels

    Remarque: conformément à [4], différents termes sont utilisés dans la présente CP pour désigner le «souscripteur» qui signe un contrat avec la CA pour la délivrance de certificats et le «sujet» auquel le certificat s’applique. Les souscripteurs sont toutes les entités ayant une relation contractuelle avec une CA. Les sujets sont les entités auxquelles le certificat s’applique. Les EA/AA sont les souscripteurs et les sujets de la CA racine et elles peuvent demander des certificats d’EA/AA. Les stations STI-C sont des sujets et peuvent demander des certificats d’entité finale.

    (9)Autorités d’enregistrement:

    L’EA doit jouer le rôle d’une autorité d’enregistrement pour les entités finales. Seul un souscripteur authentifié et autorisé peut enregistrer de nouvelles entités finales (stations STI-C) au sein d’une EA. Les CA racine pertinentes doivent jouer le rôle d’autorités d’enregistrement pour les EA et les AA.

    1.4.Usage des certificats

    1.4.1.Domaines d’utilisation applicables

    (10)Les certificats délivrés dans le cadre de la présente CP sont destinés à être utilisés pour valider les signatures numériques dans le cadre de la communication coopérative STI conformément à l’architecture de référence de [2].

    (11)Les profils de certificats dans [5] déterminent les utilisations des certificats pour le TLM, les CA racine, les EA, les AA et les entités finales.

    1.4.2.Limites de responsabilité

    (12)Les certificats ne sont pas destinés, ni autorisés, à être utilisés dans:

    ·des circonstances qui sont contraires ou contreviennent à tout règlement (par exemple, le RGPD), décret, arrêté ou loi applicable ou les enfreignent.

    ·des circonstances qui portent atteinte, contreviennent aux droits d’autrui ou les enfreignent;

    ·des circonstances qui portent atteinte à la présente CP ou à l’accord de souscription pertinent;

    ·toute circonstance dans laquelle leur utilisation pourrait directement entraîner un décès, des dommages corporels ou des dommages graves à l’environnement (par exemple, en cas de défaillance dans le fonctionnement d’installations nucléaires, de la communication ou de la navigation aérienne ou de systèmes de contrôle d’armement);

    ·des circonstances contraires aux objectifs généraux de renforcement de la sécurité routière et de plus grande efficacité du transport routier en Europe.

    1.5.Administration de la politique de certification

    1.5.1.Mise à jour des CPS des CA énumérées dans l’ECTL

    (13)Chaque CA racine énumérée dans l’ECTL publie sa propre CPS, qui doit être conforme à la présente politique. Une CA racine peut ajouter des exigences supplémentaires, mais veille à ce que toutes les exigences de la présente CP soient satisfaites à tout moment.

    (14)Chaque CA racine énumérée dans l’ECTL met en œuvre un processus de modification approprié pour son document CPS. Les caractéristiques principales du processus de modification sont documentées dans la partie publique de la CPS.

    (15)Dans le cadre du processus de modification, on veille à ce que toutes les modifications apportées à la présente CP soient attentivement analysées et, à ce que la CPS soit mise à jour, si c’est nécessaire pour assurer la conformité avec la CP modifiée, dans les délais prévus lors de l’étape de mise en œuvre du processus de modification de la CP. Ce processus comprend, en particulier, les procédures de modification d’urgence permettant d'assurer que les modifications apportées à la CP ayant une influence sur la sécurité sont mises en œuvre en temps utile.

    (16)Le processus de modification inclut des mesures appropriées permettant de vérifier que toutes les modifications apportées à la CPS sont conformes à la CP. Toute modification apportée à la CPS est clairement documentée. Avant la mise en œuvre d’une nouvelle version d’une CPS, un auditeur agréé de la PKI doit vérifier sa conformité à la CP.

    (17)La CA racine notifie à la CPA toute modification apportée à la CPS en précisant au moins les informations suivantes:

    ·une description précise de la modification;

    ·la justification de la modification;

    ·un rapport d’un auditeur agréé de la PKI confirmant la conformité à la CP;

    ·les coordonnées de la personne responsable de la CPS;

    ·le délai prévu pour la mise en œuvre.

    1.5.2.Procédure d’approbation des CPS

    (18)Avant le début de ses activités, une CA racine éventuelle présente sa CPS à un auditeur agréé de la PKI dans le cadre d’une commande d’audit de la conformité (flux 13) ainsi qu’à la CPA pour approbation (flux 15).

    (19)Une CA racine présente les modifications apportées à sa CPS à un auditeur agréé de la PKI dans le cadre d’une commande d’audit de la conformité (flux 13) et à la CPA pour approbation (flux 15) avant que ces modifications ne prennent effet.

    (20)Une EA/AA présente sa CPS ou les modifications apportées à celle-ci à la CA racine. Cette dernière peut demander un certificat de conformité auprès de l’organisme national ou de l’entité privée chargé de l’approbation de l’EA/AA, tel que défini aux sections 4.1.2 et 8.

    (21)L’auditeur agréé de la PKI évalue la CPS conformément aux dispositions de la section 8.

    (22)L’auditeur agréé de la PKI communique les résultats de l’évaluation de la CPS dans le cadre du rapport d’audit, conformément aux dispositions de la section 8.1. La CPS est acceptée ou rejetée dans le cadre de l’acceptation du rapport d’audit visée aux sections 8.5 et 8.6.

    2.Responsabilités en matière de publication et de répertoires

    2.1.Méthodes de publication des informations des certificats

    (23)Les informations des certificats peuvent être publiées conformément à la section 2.5:

    ·de manière régulière ou périodique; ou

    ·en réponse à une demande émise par l’une des entités participantes.

    Selon les cas, les degrés d’urgence pour la publication et, par conséquent, les calendriers applicables varient, mais les entités doivent être préparées aux deux types de situations.

    (24)La publication régulière des informations des certificats permet de déterminer un délai maximal au cours duquel les informations des certificats sont mises à jour pour l’ensemble des nœuds du réseau STI-C. La fréquence de publication de l’ensemble des informations des certificats est établie à la section 2.2.

    (25)À la demande des entités participant au réseau STI-C, tout participant peut commencer à publier des informations des certificats à tout moment et, en fonction de son statut, demander un jeu d’informations de certificats en cours afin de devenir un nœud totalement digne de confiance du réseau STI-C. Cette publication vise principalement à informer les entités du statut global actuel des informations des certificats dans leur réseau et à leur permettre de communiquer en toute confiance jusqu’à la prochaine publication régulière des informations.

    (26)Une CA racine unique peut également lancer la publication des informations des certificats à tout moment en envoyant un jeu actualisé de certificats à l’ensemble des «membres souscripteurs» du réseau STI-C qui reçoivent régulièrement ces informations. Cela permet aux CA, tout en soutenant leur action, de s’adresser aux membres entre les dates régulières et programmées pour la publication des certificats.

    (27)La section 2.5 établit le mécanisme et l’ensemble des procédures relatifs à la publication des certificats de CA racine et de l’ECTL.

    (28)Le CPOC publie les certificats de CA racine (tels qu’ils figurent dans l’ECTL et destinés au public), le certificat du TLM et l’ECTL qu’il délivre.

    (29)Les CA racine publient leurs certificats d’EA/AA et les CRL, et sont capables de prendre en charge les trois mécanismes visés dans le présent document en ce qui concerne leur publication à l’intention de leurs membres souscripteurs et des parties utilisatrices, en prenant toutes les mesures nécessaires pour veiller à la transmission sécurisée, comme établi à la section 4.

    2.2.Date ou fréquence de publication

    (30)Les exigences relatives au calendrier de publication pour les certificats et les CRL doivent être déterminées en fonction des différents facteurs limitatifs des nœuds STI-C uniques, et l’objectif global consiste à exploiter un «réseau de confiance» et à publier des mises à jour le plus vite possible ainsi qu’à les communiquer à l’ensemble des stations STI-C concernées.

    ·Aux fins de la publication régulière des informations des certificats mises à jour (par exemple, les modifications relatives à la composition de la CRL ou de l’ECTL), une période maximale de trois mois est nécessaire pour l’exploitation en toute sécurité du réseau STI-C.

    ·Les CA racine publient leurs certificats de CA et leurs CRL le plus rapidement possible après la délivrance.

    ·Pour la publication de la CRL, il convient d’utiliser le répertoire de CA racine.

    En outre, la CPS relative à chaque CA précise le délai dans lequel un certificat sera publié après la délivrance du certificat par la CA.

    Cette section précise uniquement la date ou la fréquence de la publication régulière. Les moyens de connectivité pour mettre à jour les stations STI-C avec l’ECTL et les CRL dans un délai d’une semaine suivant leur publication (dans des conditions normales de fonctionnement, par exemple avec une couverture cellulaire, un véhicule en fonctionnement effectif, etc.) sont mis en œuvre conformément aux exigences établies dans le présent document.

    2.3.Répertoires

    (31)Les exigences relatives à la structure du répertoire utilisé pour stocker les certificats et aux informations fournies par les entités du réseau STI-C sont les suivantes pour les entités uniques:

    ·en général, chaque CA racine devrait utiliser un répertoire de ses propres informations de certificats d’EA/AA en cours et une CRL pour publier des certificats à l’intention d’autres participants à la PKI (par exemple, un service d’annuaire LDAP). Le répertoire de chaque CA racine autorise tous les contrôles d’accès (section 2.4) et délais de transmission nécessaires (section 2.2) pour chaque méthode de diffusion des informations liées aux STI-C.

    ·Le répertoire du TLM (qui stocke l’ECTL et les certificats du TLM publiés par le CPOC, par exemple) devrait être fondé sur un mécanisme de publication en mesure d'assurer le respect des délais de transmission fixés à la section 2.2 pour chaque méthode de diffusion.

    Les exigences des AA ne sont pas définies, mais elles doivent prendre en charge les mêmes niveaux de sécurité que les autres entités et ces niveaux doivent figurer dans leur CPS.

    2.4.Contrôles d’accès sur les répertoires

    (32)Les exigences relatives au contrôle d’accès des répertoires d’informations des certificats sont au moins conformes aux normes générales de traitement sécurisé des informations définies dans la norme ISO/IEC 27001 et aux exigences établies à la section 4. En outre, elles reflètent les besoins du processus en matière de sécurité à déterminer pour les différentes étapes du processus relatives à la publication des informations des certificats.

    ·Ces besoins comprennent la mise en œuvre du répertoire pour les certificats du TLM et l’ECTL dans le TLM/CPOC. Chaque CA ou chaque exploitant de répertoire met en œuvre des contrôles d’accès en ce qui concerne l’ensemble des entités STI-C et des parties externes pour au moins trois niveaux différents (par exemple, niveau public, niveau limité aux entités STI-C ou niveau CA racine) afin d’empêcher les entités d’ajouter, de modifier ou de supprimer des entrées du répertoire.

    ·Les mécanismes exacts de contrôle d’accès de l’entité unique devraient faire partie de la CPS respective.

    ·Pour chaque CA racine, les répertoires d’EA et d’AA respectent les mêmes exigences en matière de procédures de contrôle d’accès quel que soit le lieu où le lien contractuel avec le fournisseur de service exploitant le répertoire.

    Chaque CA racine ou chaque exploitant de répertoire devrait fournir au moins trois niveaux différents (par exemple, niveau public, niveau limité aux entités STI-C ou niveau CA racine) qui serviront de points de départ pour les niveaux de contrôle d’accès.

    2.5.Publication des informations des certificats

    2.5.1.Publication des informations des certificats par le TLM

    (33)Le TLM dans le domaine de confiance européen commun des STI-C publie les informations suivantes via le CPOC:

    ·l’ensemble des certificats du TLM actuellement valides pour la prochaine période d’exploitation (certificat de lien et certificat en vigueur si disponible);

    ·les informations relatives aux points d’accès pour le répertoire du CPOC afin de fournir la liste signée des CA racine (ECTL);

    ·point d’informations général pour le déploiement de l’ECTL et des STI-C.

    2.5.2.Publication des informations des certificats par les CA

    (34)Les CA racine dans le domaine de confiance des STI-C européen commun publient les informations suivantes:

    ·les certificats de CA racine (actuellement valides) (certificats en vigueur et correctement régénérés, y compris un certificat de lien) dans le répertoire visé à la section 2.3;

    ·l’ensemble des entités EA et AA valides, ainsi que le code d’identification de l’exploitant et la période d’exploitation prévue;

    ·les certificats de CA délivrés dans les répertoires visés à la section 2.3;

    ·les CRL pour l’ensemble des certificats de CA révoqués couvrant leurs EA et AA subalternes;

    ·les informations relatives au point d’accès de la CA racine aux informations de la CA et de la CRL.

    L’ensemble des informations des certificats sont classées selon trois niveaux de confidentialité et les documents à l’intention du grand public doivent être accessibles sans restrictions.

    3.Identification et authentification

    3.1.Nommage

    3.1.1.Types de nom

    3.1.1.1.Noms pour les TLM, les CA racine, les EA et les AA

    (35)Dans le certificat du TLM, le nom est composé d’un seul attribut subject_name avec la valeur réservée «EU_TLM».

    (36)Pour les CA racine, le nom est composé d’un seul attribut subject_name avec une valeur octroyée par la CPA. L’unicité des noms est établie sous la seule responsabilité de la CPA et le TLM maintient le registre des noms de CA racine dès la notification de la CPA (approbation, révocation/suppression d’une CA racine). Les noms de sujets dans les certificats sont limités à 32 octets. Chaque CA racine propose son nom à la CPA dans le formulaire de demande (flux 14). La CPA est chargée de la vérification de l’unicité des noms. Si le nom n’est pas unique, le formulaire de demande est rejeté (flux 4).

    (37)Le nom dans chaque certificat d’EA/AA peut être composé d’un seul attribut subject_name avec une valeur générée par l’émetteur du certificat. L’unicité des noms relève de la seule responsabilité de la CA racine chargée de la délivrance.

    (38)Les certificats d’EA et d’AA n’utilisent pas de nom d’une taille supérieure à 32 octets, car les subject_name des certificats sont limités à 32 octets.

    (39)Les AT ne contiennent pas de nom.

    3.1.1.2.Noms des entités finales

    (40)Deux types d’identifiants (ID) uniques sont attribués à chaque station STI-C:

    ·un ID canonique qui est stocké lors de l’enregistrement initial de la station STI-C sous la responsabilité du fabricant. Cet ID contient une sous-chaîne qui identifie le fabricant ou l’exploitant de sorte que cet identifiant puisse être unique;

    ·un attribut subject_name, qui peut faire partie de l’EC de la station STI-C, sous la responsabilité de l’EA.

    3.1.1.3.Identification des certificats

    (41)Les certificats qui respectent le format de [5] sont identifiés en calculant une valeur HashedId8 telle que définie dans [5].

    3.1.2.Nécessité d’utiliser des noms explicites

    Aucune disposition.

    3.1.3.Anonymat et emploi de pseudonymes pour les entités finales

    (42)L’AA veille à ce que l’emploi de pseudonymes d’une station STI-C soit établi en fournissant à la station STI-C des AT qui ne contiennent aucun nom et aucune information permettant d’établir le lien entre le sujet et son identité réelle.

    3.1.4.Règles d’interprétation des diverses formes de noms

    Aucune disposition.

    3.1.5.Unicité des noms

    (43)Les noms du TLM, des CA racine, des EA, des AA et des ID canoniques pour les stations STI-C sont uniques.

    (44)Lors du processus d’enregistrement d’une CA racine donnée dans l’ECTL, le TLM veille à l’unicité de l’identifiant du certificat (HashedId8). Lors du processus de délivrance, la CA racine veille à ce que l’identifiant de certificat (HashedId8) de chaque CA subalterne soit unique.

    (45)Le HashedId8 d’un EC est unique au sein de la CA chargée de la délivrance. Le HashedId8 d’un AT ne doit pas nécessairement être unique.

    3.2.Validation initiale de l’identité

    3.2.1.Méthode visant à prouver la possession d’une clé privée

    (46)La CA racine démontre qu’elle détient légitimement la clé privée correspondant à la clé publique dans le certificat autosigné. Le CPOC vérifie cette preuve.

    (47)L’EA/AA prouve qu’elle détient légitimement la clé privée correspondant à la clé publique devant figurer dans le certificat. La CA racine vérifie cette preuve.

    (48)La possession d’une nouvelle clé privée (pour la régénération) est démontrée par la signature de la demande avec la nouvelle clé privée (signature interne) suivie de la génération d’une signature externe sur la demande signée avec la clé privée actuelle valide (pour garantir l’authenticité de la demande). Le demandeur soumet la demande de certificat signée à la CA chargée de la délivrance au moyen d’une communication sécurisée. La CA chargée de la délivrance vérifie que la signature numérique du demandeur sur le message de demande a été créée à l’aide de la clé privée correspondant à la clé publique jointe à la demande de certificat. La CA racine précise les réponses et la demande de certificat qu’elle soutient dans sa CPS.

    3.2.2.Authentification de l’identité d’une organisation

    3.2.2.1.Authentification de l’identité d’une organisation de CA racine

    (49)Dans un formulaire de demande destiné à la CPA (à savoir flux 14), la CA racine communique l’identité de l’organisation et les informations relatives à l’enregistrement, composées des éléments suivants:

    ·nom de l’organisation;

    ·adresse postale;

    ·adresse électronique;

    ·nom d’une personne physique à contacter au sein de l’organisation;

    ·numéro de téléphone;

    ·empreinte numérique (par exemple la valeur de hachage SHA 256) du certificat de la CA racine en version imprimée;

    ·informations cryptographiques (par exemple des algorithmes cryptographiques, des longueurs de clé) dans le certificat de CA racine;

    ·toutes les autorisations que la CA racine est autorisée à utiliser et à communiquer aux sous-CA.

    (50)La CPA vérifie l’identité de l’organisation et d’autres informations relatives à l’enregistrement fournies par le demandeur du certificat pour l’ajout d’un certificat de CA racine dans l’ECTL.

    (51)La CPA recueille des éléments d’identification directs ou une attestation fournie par une source appropriée et autorisée de l’identité (par exemple le nom) et, le cas échéant, des caractéristiques spécifiques des sujets auxquels un certificat est délivré. Les éléments d'identification peuvent être soumis sous forme de documentation papier ou électronique.

    (52)L’identité du sujet doit être vérifiée au moment de l’enregistrement par des moyens appropriés et conformément à la présente politique de certification.

    (53)Lors de chaque demande de certificat, les éléments d’identification suivants doivent être fournis:

    ·nom complet de l’entité organisationnelle (organisation privée, entité publique ou entité non commerciale);

    ·enregistrement reconnu au niveau national ou autres attributs pouvant être utilisés, dans la mesure du possible, afin de distinguer l’entité organisationnelle d’autres portant le même nom.

    Les règles énoncées ci-dessus reposent sur le document TS 102 042 [4]: La CA veille à ce que les éléments d’identification du souscripteur et du sujet et la précision de leurs noms et des données associées soient soit dûment examinés dans le cadre du service défini soit, le cas échéant, jugés concluants à l’issue de l’examen des attestations fournies par des sources appropriées et autorisées. Elle doit également veiller à ce que les demandes de certificat soient exactes, autorisées et complètes, conformément à l’attestation ou aux éléments d’identification recueillis.

    3.2.2.2.Authentification de l’identité d’une organisation de TLM

    (54)L’organisation exploitant le TLM fournit des éléments d’identification et des éléments attestant de l’exactitude du nom et des données associées afin de permettre une vérification appropriée lors de la création initiale et de la régénération de clé du certificat du TLM.

    (55)L’identité du sujet est vérifiée au moment de la création du certificat ou de la régénération de clé par des moyens appropriés et conformément à la présente PC.

    (56)Les éléments d’identification de l’organisation doivent être fournis conformément à la section 3.2.2.1.

    3.2.2.3.Authentification de l’identité d’une organisation de sous-CA

    (57)La CA racine vérifie l’identité de l’organisation et d’autres informations relatives à l’enregistrement fournies par les demandeurs du certificat pour les certificats de sous-CA (EA/AA).

    (58)Au minimum, la CA racine:

    ·détermine que l’organisation existe en utilisant au moins une base de données ou un service tiers de preuve d’identité ou bien de la documentation organisationnelle fournie par l’autorité reconnue ou l’agence gouvernementale concernée qui confirme l’existence de l’organisation ou déposée auprès de celle-ci;

    ·utilise la voie postale ou une procédure comparable pour demander au demandeur du certificat de confirmer certaines informations relatives à l’organisation, de confirmer qu’il a autorisé la demande de certificat et que la personne qui soumet la demande au nom du demandeur est autorisée à le faire. Lorsque le nom d’une personne agissant en qualité de mandataire de l’organisation figure sur le certificat, le demandeur confirme également qu’il emploie cette personne et l’a autorisée à agir en son nom.

    (59)Les procédures de validation pour la délivrance de certificats de CA sont documentées dans une CPS de la CA racine.

    3.2.2.4.Authentification de l’organisation du souscripteur des entités finales

    (60)Avant que le souscripteur des entités finales (fabricant/exploitant) ne puisse s’enregistrer auprès de l’EA de confiance pour permettre à ses entités finales d’envoyer les demandes de certificats EC, l’EA:

    ·vérifie l’identité de l’organisation du souscripteur et d’autres informations relatives à l’enregistrement fournies par le demandeur du certificat;

    ·vérifie que le type de station STI-C (à savoir le produit concret sur la base de la marque, du modèle et de la version de la station STI-C) satisfait à l’ensemble des critères d’évaluation de la conformité.

    (61)Au minimum, l’EA:

    ·détermine que l’organisation existe en utilisant au moins une base de données ou un service tiers de preuve d’identité ou bien de la documentation organisationnelle fournie par l’autorité reconnue ou l’agence gouvernementale concernée qui confirme l’existence de l’organisation ou déposée auprès de celle-ci;

    ·utilise la voie postale ou une procédure comparable pour demander au demandeur du certificat de confirmer certaines informations relatives à l’organisation, de confirmer qu’il a autorisé la demande de certificat et que la personne qui soumet la demande en son nom est autorisée à le faire. Lorsque le nom d’une personne agissant en qualité de mandataire de l’organisation figure sur le certificat, le demandeur confirme également qu’il emploie cette personne et l’a autorisée à agir en son nom.

    (62)Les procédures de validation pour l’enregistrement d’une station STI-C par son souscripteur sont documentées dans une CPS de l’EA.

    3.2.3.Authentification de l’entité individuelle

    3.2.3.1.Authentification de l’entité individuelle du TLM/de la CA

    (63)Pour l’authentification d’une entité individuelle (personne physique) identifiée en association avec une personne morale ou une entité organisationnelle (par exemple le souscripteur), les éléments d’identification à fournir sont les suivants:

    ·nom complet du sujet (y compris le nom de famille et les prénoms, conformément à la législation applicable et aux pratiques nationales d’identification);

    ·date et lieu de naissance, référence à un document d’identité reconnu au niveau national ou autres caractéristiques de l’abonné pouvant être utilisées, dans la mesure du possible, pour distinguer la personne d’autres portant le même nom;

    ·nom complet et statut juridique de la personne morale associée ou d’une autre entité organisationnelle (par exemple le souscripteur);

    ·toute information pertinente relative à l’enregistrement (par exemple le registre des sociétés) de la personne morale associée ou d’une autre entité organisationnelle;

    ·des éléments prouvant que le sujet est associé à la personne morale ou à une autre entité organisationnelle.

    Les éléments peuvent être soumis sous forme de documentation papier ou électronique.

    (64)Pour vérifier son identité, le mandataire d’une CA racine, d’une EA, d’une AA ou d’un souscripteur fournit des documents démontrant qu’il travaille pour l’organisation (certificat d’autorisation). Il fournit également un document d’identité officiel.

    (65)Pour le processus d’inscription initial (flux 31/32), un représentant de l’EA/AA fournit à la CA racine correspondante toutes les informations nécessaires (voir section 4.1.2).

    (66)Le personnel de la CA racine vérifie l’identité du mandataire du demandeur du certificat ainsi que tous les documents associés, en appliquant les exigences relatives au «personnel de confiance», énoncées dans la section 5.2.1. (Le processus de validation des informations relatives à la demande et de génération du certificat par la CA racine est effectué par des «personnes de confiance» à la CA racine, sous la supervision d’au moins deux personnes, étant donné qu’il s’agit d’opérations sensibles au sens de la section 5.2.2).

    3.2.3.2.Authentification de l’identité du souscripteur des stations STI-C

    (67)Les souscripteurs sont représentés par des utilisateurs finaux autorisés au sein de l’organisation, qui sont enregistrés auprès de l’EA et de l’EA chargées de la délivrance. Ces utilisateurs finaux désignés par des organisations (fabricants ou exploitants) prouvent leur identité et font l’objet d’une authentification avant:

    ·l’enregistrement de l’EE auprès de son EA correspondante, y compris sa clé publique canonique, son ID canonique (identifiant unique) et les autorisations conformément à l’EE;

    ·l’enregistrement auprès de l’AA et l’obtention de la preuve d’un accord de souscription qui peut être envoyée à l’EA.

    3.2.3.3.Authentification de l’identité des stations STI-C

    (68)Les sujets de EE des entités finales s’authentifient lors de la demande d’EC (flux 31) en utilisant leur clé privée canonique pour l’authentification initiale. L’EA vérifie l’authentification à l’aide de la clé publique canonique correspondant à l’EE. Les clés publiques canoniques des EE sont apportées à l’EA avant l’exécution de la demande initiale, par un canal sécurisé entre le fabricant ou l’exploitant de la station STI-C et l’EA (flux 33).

    (69)Les sujets d’AT d’entité finale s’authentifient lors de la demande d’AT (flux 32) en utilisant leur clé privée unique d’inscription. L’AA envoie la signature à l’EI (flux 25) pour validation; l’EA la valide et confirme le résultat à l’AA (flux 23).

    3.2.4.Renseignements non vérifiés sur le souscripteur

    Aucune disposition.

    3.2.5.Validation de l’autorité

    3.2.5.1.Validation du TLM, de la CA racine, de l’EA et de l’AA

    (70)Chaque organisation recense dans la CPS au moins un représentant (par exemple un officier de sécurité) chargé de demander de nouveaux certificats et des renouvellements. Les règles en matière de nommage établies à la section 3.2.3 sont applicables.

    3.2.5.2.Validation des souscripteurs de la station STI-C

    (71)Au moins une personne physique chargée d’enregistrer les stations STI-C auprès d’une EA (par exemple un agent de sécurité) est reconnue par l’EA et approuvée par cette autorité (voir section 3.2.3).

    3.2.5.3.Validation des stations STI-C

    (72)Un souscripteur de station STI-C peut enregistrer des stations STI-C auprès d’une EA spécifique (flux 33) pour autant qu’il soit authentifié auprès de cette EA.

    Lorsque la station STI-C est enregistrée auprès d’une EA avec un ID canonique unique et une clé publique canonique, elle peut demander un EC à l’aide d’une demande signée avec la clé privée canonique liée à la clé publique canonique enregistrée précédemment.

    3.2.6.Critères d’interopérabilité

    (73)Pour la communication entre les stations STI-C et les EA (ou AA), la station STI-C doit être en mesure d’établir une communication sécurisée avec les EA (ou AA), c’est-à-dire de mettre en œuvre des fonctions d’authentification, de confidentialité et d’intégrité, comme spécifié à [1]. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre. L’EA et l’AA prennent en charge cette communication sécurisée.

    (74)L’EA et l’AA prennent en charge les demandes de certificat et les réponses conformées à [1], qui prévoit un protocole sécurisé de réponse/demande d’AT assurant l’anonymat du demandeur vis-à-vis de l’AA et la séparation des tâches entre l’AA et l’EA. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre. Afin d’empêcher la divulgation de l’identité à long terme des stations STI-C, la communication entre une station STI-C mobile et une EA est confidentielle (par exemple, les données de communication sont chiffrées de bout en bout).

    (75)L’AA soumet une demande de validation de l’autorisation (flux 25) pour chaque demande d’autorisation reçue de la part d’un sujet de certificat d’EE. L’EA valide cette demande en ce qui concerne:

    ·le statut de l’EE à l’EA ;

    ·la validité de la signature;

    ·les autorisations et ITS-AID requises,

    ·le statut de la fourniture d’un service de l’AA au souscripteur.

    3.3.Identification et authentification des demandes de régénération de clés

    3.3.1.Identification et authentification pour régénération de clé courante

    3.3.1.1.Certificats du TLM

    (76)Le TLM génère une paire de clés et deux certificats: Un certificat autosigné et un certificat de lien, tel que visé à la section 7.

    3.3.1.2.Certificats de la CA racine

    Sans objet.

    3.3.1.3.Régénération de clé ou renouvellement du certificat d’EA /AA

    (77)Avant l’expiration d’un certificat d’EA /AA, l’EA /AA demande un nouveau certificat (flux 21/flux 24) afin de maintenir la continuité de l’usage des certificats. L’EA /AA génère une nouvelle paire de clés pour remplacer celle qui expire et signe la demande de régénération contenant la nouvelle clé publique avec la clé privée actuelle valide («régénération»). L’EA ou l’AA génère une nouvelle paire de clés et signe la demande avec la nouvelle clé privée (signature interne) pour prouver la possession de la nouvelle clé privée. Toute la demande est signée (contresignée) avec la clé privée actuelle valide (signature externe) pour garantir l’intégrité et l’authenticité de la demande. En cas d’utilisation d’une paire de clés de chiffrement et de déchiffrement, il faut prouver la possession de clés privées de déchiffrement prouvée (pour une description détaillée de la régénération, voir section 4.7.3.3).

    (78)La méthode d’identification et d’authentification pour la régénération courante est similaire à celle énoncée à la section 3.2.2 en ce qui concerne la délivrance initiale d’une validation initiale de certificat de CA racine.

    3.3.1.4.Authentifiants d’inscription des entités finales

    (79)Avant l’expiration d’un EC existant, l’EE demande un nouveau certificat (flux 31) afin de maintenir la continuité de l’usage des certificats. L’EE génère une nouvelle paire de clés pour remplacer celle qui expire et demande un nouveau certificat contenant la nouvelle clé publique; la demande est signée avec la clé privée d’EC valide en vigueur.

    (80)L’EE peut signer la demande avec la clé privée nouvellement créée (signature interne) pour prouver la possession de la nouvelle clé privée. Toute la demande est ensuite signée (contresignée) avec la clé privée actuelle valide (signature externe) et chiffrée à l’intention de l’EA réceptrice comme spécifié dans [1] pour garantir la confidentialité, l’intégrité et l’authenticité de la demande. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    3.3.1.5.Tickets d’autorisation des entités finales

    (81)La régénération de clés de certificat pour les AT repose sur le même processus que l’autorisation initiale, tel que défini dans [1]. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    3.3.2.Identification et authentification pour régénération de clés après révocation

    3.3.2.1.Certificats de CA

    (82)L’authentification d’une organisation de CA pour la régénération de clés de certificats de CA racine, d’EA et d’AA après révocation est gérée de la même manière que la délivrance initiale d’un certificat de CA, conformément aux dispositions de la section 3.2.2.

    3.3.2.2.Authentifiants d’inscription des entités finales

    (83)L’authentification d’une EE pour la régénération de clés de l’EC après révocation est gérée de la même manière que la délivrance initiale d’un certificat d’EE, conformément aux dispositions de la section 3.2.2.

    3.3.2.3.Demandes d’autorisation des entités finales

    Ne s’applique pas, étant donné que les AT ne sont pas révoqués.

    3.4.Identification et authentification des demandes de révocation

    3.4.1.Certificats de CA racine/EA /AA

    (84)Les demandes de suppression d’un certificat de CA racine de l’ECTL sont authentifiées par la CA racine auprès du TLM (flux 12 et 9). Les demandes de révocation d’un certificat d’EA/AA sont authentifiées par la CA racine concernée et la sous-CA elle-même.

    (85)Les procédures acceptables pour l’authentification des demandes de révocation d’un souscripteur comprennent:

    ·un message écrit et signé sur du papier à lettres d’entreprise émanant du souscripteur qui demande la révocation, faisant référence au certificat à révoquer;

    ·la communication avec le souscripteur qui fournit des assurances raisonnables que la personne ou l’organisation qui demande la révocation est réellement le souscripteur. En fonction des circonstances, cette communication peut inclure un ou plusieurs des éléments suivants: adresse électronique, adresse postale ou service de messagerie.

    3.4.2.Authentifiants d’inscription de la station STI-C

    (86)Le souscripteur de la station STI-C peut révoquer l’EC d’une station STI-C précédemment enregistrée auprès d’une EA (flux 34). Le souscripteur qui demande la révocation crée une demande de révocation d’une station STI-C donnée ou d’une liste de stations STI-C. L’EA authentifie la demande de révocation avant de la traiter et confirme la révocation des stations STI-C et de leurs EC.

    (87)L’EA peut révoquer l’EC d’une station STI-C conformément aux dispositions de la section 7.3.

    3.4.3.Tickets d’autorisation de la station STI-C

    (88)Les AT n’étant pas révoqués, leur validité est limitée à une période spécifique. La plage des périodes de validité acceptables dans la présente politique de certification est spécifiée à la section 7.

    4.Exigences opérationnelles du cycle de vie des certificats

    4.1.Demande de certificat 

    (89)La présente section définit les exigences applicables à une première demande de délivrance du certificat.

    (90)Le terme «demande de certificat» se réfère aux processus suivants:

    ·enregistrement et mise en place d’un rapport de confiance entre le TLM et la CPA;

    ·enregistrement et mise en place d’un rapport de confiance entre la CA racine, la CPA et le TLM, y compris l’insertion du premier certificat de CA racine dans l’ECTL;

    ·enregistrement et mise en place d’un rapport de confiance entre l’EA/AA et la CA racine, y compris la délivrance d’un nouveau certificat EA/AA;

    ·enregistrement de la station STI-C auprès de l’EA par le fabricant/l’exploitant;

    ·demande d’EC/AT par la station STI-C.

    4.1.1.Qui peut présenter une demande de certificat

    4.1.1.1.CA racine

    (91)Les CA racine génèrent leurs propres paires de clés et délivrent leur certificat racine elles-mêmes. Une CA racine peut soumettre une demande de certificat par l’intermédiaire de son représentant désigné (flux 14).

    4.1.1.2.TLM

    (92)Le TLM génère ses propres paires de clés et délivre son certificat lui-même. La création initiale du certificat du TLM est traitée par un représentant de l’organisation du TLM sous le contrôle de la CPA.

    4.1.1.3.EA et AA

    (93)Un mandataire de l’EA ou l’AA peut soumettre la demande de certificat de la sousCA (EA et/ou AA) au mandataire de la CA racine concernée (flux 27/28).

    4.1.1.4.Station STI-C

    (94)Les souscripteurs enregistrent chaque station STI-C auprès de l’EA conformément à la section 3.2.5.3.

    (95)Chaque station STI-C enregistrée auprès de l’EA peut envoyer des demandes d’EC (flux 31).

    (96)Chaque station STI-C peut envoyer des demandes d’AT (flux 32) sans demander l’interaction d’un souscripteur. Avant de demander un AT, une station STI-C doit avoir un EC.

    4.1.2.Processus d’inscription et responsabilités

    (97)Les autorisations pour la délivrance de certificats par les CA racine et les sous-CA à des fins spéciales (des pouvoirs publics) (c’est-à-dire les stations STI-C mobiles et fixes spéciales) ne peuvent être accordées que par les États membres dans lesquels les organisations sont situées.

    4.1.2.1.CA racine

    (98)Après avoir été auditées (flux 13 et 36, section 8), les CA racine peuvent demander l’insertion de leur(s) certificat(s) dans l’ECTL auprès de la CPA (flux 14). Le processus d’inscription est fondé sur un formulaire signé de demande manuelle qui doit être physiquement remis à la CPA par le mandataire de la CA racine et qui contient au moins les renseignements mentionnés dans les sections 3.2.2.1, 3.2.3 et 3.2.5.1.

    (99)Le formulaire de demande de la CA racine est signé par son mandataire.

    (100)Outre le formulaire de demande, le mandataire de la CA racine fournit une copie de la CPS de la CA racine (flux 15) et de son rapport d’audit à la CPA pour approbation (flux 16). En cas d’approbation positive, la CPA génère et envoie un certificat de conformité au CPOC/TLM et à la CA racine correspondante.

    (101)Le mandataire des CA racine introduit ensuite son formulaire de demande (contenant l’empreinte numérique du certificat autosigné), le document d’identité officiel et une preuve de l’autorisation au CPOC/TLM. Le certificat autosigné est transmis sous forme électronique au CPOC/TLM. Le CPOC/TLM vérifie tous les documents et le certificat autosigné.

    (102)Si les vérifications donnent des résultats positifs, le TLM ajoute le certificat de la CA racine à l’ECTL sur la base de la notification de la CPA (flux 1 et 2). Le processus détaillé est décrit dans la CPS du TLM

    (103)Une procédure supplémentaire pour obtenir une approbation de la CPS et du rapport d’audit d’une CA racine auprès d’un organisme national de certains pays devrait être possible.

    4.1.2.2.TLM

    (104)Après avoir été audité, le TLM peut s’inscrire auprès de la CPA. Le processus d’inscription est fondé sur un formulaire signé de demande manuelle qui est physiquement remis à la CPA (flux 38) par le mandataire du TLM et qui contient au moins les renseignements mentionnés dans les sections 3.2.2.2 et 3.2.3.

    (105)Le formulaire de demande du TLM est signé par son mandataire.

    (106)Premièrement, le TLM génère son certificat autosigné et le transmet de façon sécurisée à la CPA. Le TLM transmet ensuite son formulaire de demande (contenant l’empreinte numérique du certificat autosigné), une copie de sa CPS, un document d’identité officiel, une preuve d’autorisation et son rapport d’audit à la CPA (flux 40). La CPA vérifie tous les documents et le certificat autosigné. Si toutes les vérifications de documents, du certificat autosigné et de l’empreinte donnent des résultats positifs, la CPA confirme le processus d’inscription en envoyant son approbation au TLM et au CPOC (flux 39). La CPA conserve les renseignements relatifs à la demande envoyés par le TLM. Le certificat du TLM est ensuite émis via le CPOC.

    4.1.2.3.EA et AA

    (107)Au cours du processus d’inscription, l’EA /AA transmet les documents pertinents (par exemple, la CPS et le rapport d’audit) à la CA racine correspondante pour approbation (flux 27/28). Si les contrôles de ces documents sont positifs, la CA racine envoie une approbation aux sous-CA racine correspondantes (flux 29/30). La sous-CA (EA ou AA) transmet ensuite sa demande signée par voie électronique, et remet physiquement son formulaire de demande (conformément à la section 3.2.2.1), la preuve de l’autorisation et le document d’identité à la CA racine correspondante. Cette dernière vérifie la demande et les documents reçus (formulaire de demande contenant l’empreinte numérique, à savoir la valeur de hachage SHA 256 de la demande de la sous CA, la preuve de l’autorisation et le document d’identité). Si tous les contrôles aboutissent à un résultat positif, la CA racine délivre le certificat à la sous-CA correspondante. Des informations détaillées sur la façon d’effectuer une demande initiale figurent dans sa CPS spécifique.

    (108)Outre le formulaire de demande de la sous-CA, le mandataire de la sous-CA joint une copie de la CPS transmise à la CA racine.

    (109)Des informations sont communiquées à un auditeur agréé de la PKI aux fins de l’audit conformément à la section 8.

    (110)Si une sous-CA est détenue par une entité différente de l’entité qui détient une CA racine, avant l’émission d’une demande de certificat de la sous-CA, l’entité de la sous-CA signe un contrat concernant le service de la CA racine.

    4.1.2.4.Station STI-C

    (111)L’inscription initiale des sujets des entités finales (stations STI-C) est effectuée auprès de l’EA (flux 33 et 35) par le souscripteur responsable (fabricant/exploitant) après l’authentification réussie de l’organisation du souscripteur et de l’un de ses représentants conformément aux sections 3.2.2.4 et 3.2.5.2.

    (112)Une station STI-C peut générer une paire de clés EC (voir section 6.1) et créer une demande d’EC signée conformément à [1]. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    (113)Lors de l’enregistrement d’une station STI-C normale (par opposition à une station STI-C fixe ou mobile spéciale), l’EA doit vérifier que les autorisations dans la demande initiale ne sont pas destinées à une utilisation par les pouvoirs publics. Les autorisations pour une utilisation par les pouvoirs publics sont définies par les États membres correspondants. La procédure détaillée pour l’enregistrement et la réponse de l’EA au fabricant/à l’exploitant (flux 33 et 35) est exposée dans la CPS correspondante de l’EA.

    (114)Une station STI-C doit être inscrite auprès d’une EA (section 3.2.5.3) par envoi de sa demande EC initiale, conformément à [1].

    (115)Lors de l’enregistrement initial par le représentant d’un souscripteur authentifié, l’EA approuve les AT que le sujet de l’entité finale (c’est-à-dire la station STI-C) pourrait obtenir. En outre, chaque entité finale se voit attribuer un niveau de garantie de la confiance, lequel est lié à la certification de l’entité finale conformément à l’un des profils de protection énumérés à la section 6.1.5.2.

    (116)Les véhicules ordinaires n’ont qu’une station STI-C enregistrée auprès d’une EA. Les véhicules à usage spécial (tels que les voitures de police et autres véhicules à usage spécial dotés de droits spécifiques) peuvent être inscrits auprès d’une EA supplémentaire ou avoir une station STI-C supplémentaire pour des autorisations dans le cadre de cet usage spécial. Les véhicules bénéficiant d’une telle dérogation sont définis par les États membres responsables. Les autorisations pour les stations STI-C mobiles et fixes spéciales ne sont accordées que par les États membres responsables. La CPS des CA racine ou des sousCA délivrant des certificats pour ce type de véhicules dans ces États membres détermine la façon dont le processus de certification s’applique à ces véhicules.

    (117)Lorsque le souscripteur est en train de migrer une station STI-C d’une EA à une autre, la station STI-C peut être enregistrée auprès de deux EA (similaires).

    (118)Une station STI-C génère une paire de clés AT (voir section 6.1) et crée une demande d’AT conformément à [1]. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    (119)Les stations STI-C adressent une demande d’autorisation à l’URL de l’AA (flux 32 et 26) en envoyant au moins les renseignements mentionnés dans la section 3.2.3.3). L’AA et l’EA valident l’autorisation pour chaque demande conformément aux sections 3.2.6 et 4.2.2.5.

    4.2.Traitement des demandes de certificat

    4.2.1.Exécution des fonctions d’identification et d’authentification

    4.2.1.1.Identification et authentification des CA racine

    (120)Le mandataire de la CPA est chargé de l’authentification du mandataire de la CA racine et de l’approbation de son processus d’inscription conformément à la section 3.

    4.2.1.2.Identification et authentification du TLM

    (121)Le mandataire de la CPA est chargé de l’authentification du mandataire du TLM et de l’approbation de son formulaire de demande de processus d’inscription conformément à la section 3.

    4.2.1.3.Identification et authentification de l’EA et l’AA

    (122)La CA racine correspondante est chargée de l’authentification du mandataire de l’EA/AA et de l’approbation de son formulaire de demande de processus d’inscription conformément à la section 3.

    (123)La CA racine confirme sa validation positive du formulaire de demande à l’EA/AA. L’EA/AA peut ensuite envoyer une demande de certificat à la CA racine (flux 21/24), qui délivre les certificats à l’EA/AA correspondante (flux 18/19).

    4.2.1.4.Identification et authentification du souscripteur EE

    (124)Avant qu’une station STI-C puisse demander un certificat EC, le souscripteur EE transmet de façon sécurisée les renseignements d’identification de la station STI-C à l’EA (flux 33). L’EA vérifie la demande et, si le résultat est positif, enregistre les renseignements relatifs à la station STI-C dans sa base de données centrale et confirme cet enregistrement au souscripteur EE (flux 35). Cette opération n’est effectuée qu’une seule fois par le fabricant ou l’exploitant pour chaque station STI-C. Une fois qu’une station STI-C est enregistrée par une EA, elle peut demander un seul certificat EC (flux 31) à la fois. L’EA authentifie les renseignements contenus dans la demande de certificat EC et vérifie qu’ils sont valides pour une station STI-C.

    4.2.1.5.Tickets d’autorisation

    (125)Lors de demandes d’autorisation (flux 32), conformément à [1], l’AA doit authentifier l’EA de laquelle la station STI-C a reçu son EC. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre. Si l’AA n’est pas en mesure d’authentifier l’EA , la demande est rejetée (flux 26). L’AA doit impérativement posséder le certificat EA pour authentifier l’EA et vérifier sa réponse (flux 25 et 23, section 3.2.5.3).

    (126)L’EA authentifie la station STI-C demandant un AT en vérifiant son EC (flux 25 et 23).

    4.2.2.Approbation ou rejet des demandes de certificat

    4.2.2.1.Approbation ou rejet des certificats de la CA racine

    (127)Le TLM insère/supprime les certificats de la CA racine dans l’ECTL conformément à l’approbation de la CPA (flux 1/2).

    (128)Le TLM doit vérifier la signature, les renseignements et l’encodage des certificats de la CA racine après avoir reçu une approbation de la CPA (flux 1). Après la validation et l’approbation de la CPA, le TLM met le certificat racine correspondant sur l’ECTL et notifie la CPA (flux 5).

    4.2.2.2.Approbation ou rejet du certificat du TLM

    (129)La CPA est responsable de l’approbation ou du rejet des certificats du TLM.

    4.2.2.3.Approbation ou rejet des certificats de l’EA et de l’AA

    (130)La CA racine vérifie les demandes de certificat des sous-CA (flux 21/24) et les rapports correspondants (délivrés par l’auditeur agréé de la PKI) lorsqu’elle les reçoit (flux 36, section 8) de la sous-CA de la CA racine correspondante. Si le résultat de la vérification est positif, la CA racine correspondante délivre un certificat à l’EA/AA (flux 18/19); dans le cas contraire, la demande est rejetée et aucun certificat n’est délivré à l’EA /AA.

    4.2.2.4.Approbation ou rejet de l’EC

    (131)L’EA vérifie et valide les demandes d’EC conformément aux sections 3.2.3.2 et 3.2.5.3.

    (132)Si la demande de certificat conformément à [1] est correcte et valide, l’EA génère le certificat demandé.

    (133)Si la demande de certificat n’est pas valide, l’EA la refuse et envoie une réponse exposant le motif de refus conformément à [1]. Si une station STI-C souhaite toujours obtenir un EC, elle dépose une nouvelle demande de certificat. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    4.2.2.5.Approbation ou rejet de l’AT

    (134)La demande de certificat est vérifiée par l’EA. L’AA établit la communication avec l’EA pour valider la demande (flux 25). L’EA authentifie la station STI-C à l’origine de la demande et détermine si elle est en droit de recevoir l’AT demandé selon la CP (par exemple, en vérifiant le statut de révocation et la validité de la durée/région, les autorisations; le niveau de garantie, etc.). L’EA retourne une réponse de validation (flux 23) et, si cette réponse est positive, l’AA génère le certificat demandé et le transmet à la station STI-C. Si la demande d’AT n’est pas correcte ou si la réponse de validation de l’EA est négative, l’AA rejette la demande. Si une station STI-C souhaite toujours obtenir un AT, elle dépose une nouvelle demande d’autorisation.

    4.2.3.Délai de traitement des demandes de certificat 

    4.2.3.1.Demande de certificat de CA racine

    (135)Le traitement du processus d’identification et d’authentification d’une demande de certificat a lieu pendant les jours ouvrables et est soumis à un délai maximal prévu dans la CPS de la CA racine.

    4.2.3.2.Demande de certificat du TLM

    (136)Le traitement de la demande de certificat du TLM est soumis à un délai maximal prévu dans la CPS du TLM.

    4.2.3.3.Demande de certificat de l’EA et de l’AA

    (137)Le traitement du processus d’identification et d’authentification d’une demande de certificat a lieu pendant les jours ouvrables conformément à l’accord et au contrat entre la CA racine de l’État membre/de l’organisation privée et la sousCA. Le temps de traitement de la demande de certificat de la sous-CA est soumis à un délai maximal prévu dans la CPS de la sous-CA.

    4.2.3.4.Demande d’EC

    (138)Le traitement des demandes d’EC est soumis à un délai maximal prévu dans la CPS de l’EA.

    4.2.3.5.Demande d’AT

    (139)Le traitement des demandes d’AT est soumis à un délai maximal prévu dans la CPS de l’AA.

    4.3.Délivrance des certificats

    4.3.1.Tâches de la CA lors de la délivrance des certificats

    4.3.1.1.Délivrance de certificat par la CA racine

    (140)Les CA racine délivrent leurs propres certificats de CA racine autosignés, leurs certificats de lien, leurs certificats de sous-CA et CRL.

    (141)Après approbation de la CPA (flux 4), la CA racine envoie son certificat au TLM via le CPOC, pour qu’il soit ajouté à l’ECTL (flux 11 et 8) (voir section 4.1.2.1). Le TLM vérifie si la CPA a approuvé le certificat (flux 1).

    4.3.1.2.Délivrance de certificat du TLM

    (142)Le TLM délivre son propre certificat de TLM et de lien autosigné et l’envoie au CPOC (flux 6).

    4.3.1.3.Délivrance de certificat d’EA et AA

    (143)Les sous-CA génèrent une demande de certificat signée et la transmettent à la CA racine correspondante (flux 21 et 24). La CA racine vérifie la demande et délivre un certificat à la sous-CA à l’origine de la demande, conformément à [5], dans les plus brefs délais, comme prévu dans la CPS pour les pratiques opérationnelles habituelles, mais au plus tard cinq jours ouvrables après réception de la demande.

    (144)La CA racine met à jour le répertoire contenant les certificats des sousCA.

    4.3.1.4.Délivrance de l’EC

    (145)La station STI-C transmet une demande d’EC à l’EA conformément à [1]. L’EA authentifie et vérifie que les informations contenues dans la demande de certificat sont valides pour une station STI-C. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    (146)Si le résultat de la validation est positif, l’EA délivre un certificat conformément à l’enregistrement de la station STI-C (voir 4.2.1.4) et l’envoie à la station STI-C en utilisant un message de réponse d’EC conformément à [1]. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    (147)S’il n’existe pas d’enregistrement, l’EA génère un code d’erreur et l’envoie à la station STI-C en utilisant un message de réponse d’EC conformément à [1]. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    (148)Les demandes et les réponses d’EC sont chiffrées afin de garantir la confidentialité et sont signées afin de garantir l’authentification et l’intégrité.

    4.3.1.5.Délivrance  d’AT

    (149)La station STI-C envoie un message de demande d’AT à l’AA conformément à [1]. L’AA envoie une demande de validation de l’AT, conformément à [1], à l’EA. L’EA envoie une réponse de validation de l’AT à l’AA. Si cette réponse est positive, l’AA génère un AT et l’envoie à la station STI-C en utilisant un message de réponse d’AT conformément à [1]. En cas de réponse négative, l’AA génère un code d’erreur et l’envoie à la station STI-C en utilisant un message de réponse d’AT conformément à [1]. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    (150)Les demandes et les réponses d’AT sont chiffrées (cela n’est nécessaire que pour les stations mobiles STIC mobiles) afin de garantir la confidentialité et sont signées afin de garantir l’authentification et l’intégrité.

    4.3.2.Notification au souscripteur de la délivrance des certificats par la CA

    Sans objet.

    4.4.Acceptation des certificats

    4.4.1.Acceptation des certificats

    4.4.1.1.CA racine

    Sans objet.

    4.4.1.2.TLM

    Sans objet.

    4.4.1.3.EA et AA

    (151)L’EA/AA vérifie le type de certificat, la signature et les informations figurant dans le certificat reçu. L’EA/AA rejette tous les certificats de l’EA/AA qui ne sont pas correctement vérifiés et émet une nouvelle demande.

    4.4.1.4.Station STI-C

    (152)La station STI-C vérifie la réponse d’EC/AT reçue de l’EA/AA par rapport à sa demande initiale, y compris la signature et la chaîne de certification. Elle rejette toutes les réponses d’EC/AT qui ne sont pas correctement vérifiées. En pareils cas, elle doit envoyer une nouvelle demande d’EC/AT.

    4.4.2.Publication du certificat

    (153)Les certificats du TLM et leurs certificats de lien sont mis à la disposition de tous les participants par l’intermédiaire du CPOC.

    (154)Les certificats de la CA racine sont publiés par le CPOC via l’ECTL, qui est signé par le TLM.

    (155)Les certificats des sous-CA (EA et AA) sont publiés par la CA racine.

    (156)Les EC et les AT ne sont pas publiés.

    4.4.3.Notification de la délivrance des certificats

    Il n’y a pas de notifications de délivrance.

    4.5.Utilisation des paires de clés et des certificats

    4.5.1.Utilisation de la clé privée et du certificat

    4.5.1.1.Utilisation de la clé privée et du certificat pour le TLM

    (157)Le TLM utilise ses clés privées pour signer ses propres certificats (du TLM et de lien) et l’ECTL.

    (158)Le certificat du TLM est utilisé par les participants à une PKI afin de vérifier l’ECTL et d’authentifier le TLM.

    4.5.1.2.Utilisation de la clé privée et du certificat pour les CA racine

    (159)Les CA racine utilisent leurs clés privées pour signer leurs propres certificats, les CRL, les certificats de lien et les certificats de l’EA/AA.

    (160)Les certificats de la CA racine sont utilisés par les participants à la PKI afin de vérifier les certificats de l’AA et de l’EA connexes, les certificats de lien et les CRL.

    4.5.1.3.Utilisation de la clé privée et du certificat pour les EA et les AA

    (161)Les EA utilisent leurs clés privées pour signer les EC et pour le déchiffrement des demandes d’inscription.

    (162)Les certificats d’EA sont utilisés pour vérifier la signature des EC connexes et pour le chiffrement des demandes d’EC et d’AT par les EE tels que défini dans [1].

    (163)Les AA utilisent leurs clés privées pour signer les AT et déchiffrer les demandes d’AT.

    (164)Les certificats des AA sont utilisés par les EE pour vérifier les AT connexes et chiffrer les demandes d’AT tel que défini dans [1].

    4.5.1.4.Utilisation de la clé privée et du certificat pour l’entité finale

    (165)Les EE utilisent la clé privée correspondant à un EC valide afin de signer une nouvelle demande d’inscription telle que définie dans [1]. La nouvelle clé privée est utilisée pour créer la signature interne dans la demande afin de prouver la possession de la clé privée correspondant à la nouvelle clé publique d’EC.

    (166)Les EE utilisent la clé privée correspondant à un EC valide afin de signer une demande d’autorisation telle que définie dans [1]. La clé privée correspondant au nouvel AT doit être utilisée pour créer la signature interne dans la demande afin de prouver la possession de la clé privée correspondant à la nouvelle clé publique de l’AT.

    (167)Les EE utilisent la clé privée correspondant à un AT approprié afin de signer les messages des STI-C tels que définis dans [5].

    4.5.2.Utilisation du certificat et de la clé publique par une partie utilisatrice

    (168)Les parties utilisatrices utilisent la voie de certification de confiance et les clés publiques qui y sont associées aux fins visées dans les certificats et pour authentifier l’identité commune de confiance des EC et des AT.

    (169)Les certificats de la CA racine, de l’EA et de l’AA, les EC et les AT ne sont pas utilisés sans vérification préliminaire par une partie utilisatrice.

    4.6.Renouvellement de certificat

    Non autorisé.

    4.7.Régénération de clés de certificat

    4.7.1.Circonstances de la régénération des clés de certificat

    (170)La régénération des clés de certificat a lieu lorsqu’un certificat atteint la fin de sa durée de vie ou lorsqu’une clé privée arrive à la fin de son utilisation opérationnelle, mais que la relation de confiance avec la CA existe toujours. Une nouvelle paire de clés et le certificat correspondant sont générés et délivrés dans tous les cas.

    4.7.2.Qui peut demander la régénération 

    4.7.2.1.CA racine

    (171)La CA racine ne demande pas de régénération. Le processus de régénération est un processus interne pour la CA racine car c’est elle-même qui signe son certificat. La CA racine procède à une régénération soit avec des certificats de lien, soit par une nouvelle délivrance (voir section 4.3.1.1).

    4.7.2.2.TLM

    (172)Le TML ne demande pas de régénération. Le processus de régénération est interne pour le TML car c’est lui-même qui signe son certificat.

    4.7.2.3.EA et AA

    (173)Il convient que la demande de certificat de la sous-CA soit soumise en temps utile afin d'avoir la certitude que le nouveau certificat de sous-CA et la paire de clés de sous-CA seront opérationnels avant l’expiration de la clé de sous-CA privée en vigueur. La date de dépôt doit également tenir compte du délai requis pour l’approbation.

    4.7.2.4.station STI-C

    Sans objet.

    4.7.3.Traitement des demandes de régénération des clés de certificat

    4.7.3.1.Certificat du TLM

    (174)Le TLM décide de la régénération des clés sur la base des exigences énoncées aux sections 6.1 et 7.2. Le processus détaillé est exposé dans sa CPS.

    (175)Le TLM exécute le processus de régénération des clés en temps utile afin que les nouveaux certificats du TLM et certificat de lien puissent être diffusés à tous les participants avant l’expiration du certificat de TLM en vigueur.

    (176)Le TLM utilise les certificats de lien pour la régénération des clés et afin de garantir la relation de confiance du nouveau certificat autosigné. Le certificat du TLM et le certificat de lien nouvellement générés sont transférés au CPOC.

    4.7.3.2.Certificat de CA racine

    (177)La CA racine décide de la régénération des clés sur la base des exigences énoncées aux sections 6.1.5 et 7.2. Le processus détaillé doit être défini dans sa CPS.

    (178)La CA racine exécute le processus de régénération des clés en temps utile (avant l’expiration du certificat de la CA racine) afin de permettre l’insertion du nouveau certificat dans l’ECTL avant le début de la validité du certificat de la CA racine (voir section 5.6.2). Le processus de régénération des clés est effectué soit via les certificats de lien, soit comme une demande initiale.

    4.7.3.3.certificats d’EA et d’AA

    (179)L’EA ou l’AA demande un nouveau certificat comme suit:

    Étape

    Indications

    Demande de régénération des clés

    1

    Génération de paires de clés

    Les sous-CA (EA et AA) génèrent de nouvelles paires de clés conformément à la section 6.1.

    2

    Génération de demande de certificat et signature interne

    La sous-CA génère une demande de certificat à partir de la clé publique nouvellement générée, en prenant en considération le système de dénomination (subject_info) de la section 3, l’algorithme de signature, les SSP (autorisations spécifiques de service) et les paramètres facultatifs supplémentaires, et génère la signature interne avec la nouvelle clé privée correspondante. Si une clé de chiffrement est requise, la sous-CA doit également prouver la possession de la clé de déchiffrement correspondante.

    3

    Générer une signature externe

    L’ensemble de la demande est signée avec la clé privée valide en vigueur afin de garantir l’authenticité de la demande signée.

    4

    Envoyer une demande à la CA racine

    La demande signée est présentée à la CA racine correspondante.

    5

    Vérification de la demande

    La CA racine correspondante vérifie l’intégrité et l’authenticité de la demande. Elle vérifie d’abord la signature externe. Si le résultat de cette vérification est positif, elle vérifie la signature interne. Lorsqu’il existe une preuve de possession de la clé de déchiffrement privée, elle vérifie également cette preuve.

    6

    Accepter ou rejeter la demande

    Si tous les contrôles aboutissent à un résultat positif, la CA racine accepte la demande; dans le cas contraire, elle la rejette.

    7

    Générer et délivrer un certificat

    La CA racine génère un nouveau certificat et le remet à la sous-CA qui en fait la demande.

    8

    Envoyer la réponse

    La sous-CA envoie un message sur le statut (quant à la réception ou non du certificat) à la CA racine.

    Tableau 3: Processus de régénération des clés pour les EA et les AA

    (180)Au cours de la régénération automatique des clés pour les sous-CA, la CA racine veille à ce que le demandeur soit bien en possession de sa clé privée. Des protocoles appropriés pour la preuve de possession des clés de déchiffrement privées sont appliqués, par exemple comme définis dans le RFC 4210 et 4211. Pour les clés de signature privées, la signature interne doit être utilisée.

    4.7.3.4.Certificats de la station STI-C

    Sans objet pour les AT.

    4.8.Modification d’un certificat

    Non autorisée.

    4.9.Révocation et suspension de certificat

    Voir section 7

    4.10.Services d’état des certificats

    4.10.1.Caractéristiques opérationnelles

    Sans objet

    4.10.2.Disponibilité du service

    Sans objet

    4.10.3.Caractéristiques optionnelles

    Sans objet

    4.11.Fin de la souscription 

    Sans objet

    4.12.Séquestre et récupération des clés

    4.12.1.Souscripteur

    4.12.1.1.Quelles paires de clés peuvent être mises sous séquestre

    Sans objet.

    4.12.1.2.Qui peut présenter une demande de récupération

    Sans objet.

    4.12.1.3.Processus de récupération et responsabilités

    Sans objet.

    4.12.1.4.Identification et authentification

    Sans objet.

    4.12.1.5.Approbation ou rejet des demandes de récupération

    Sans objet.

    4.12.1.6.Actions KEA et KRA pendant la récupération de la paire de clés

    Sans objet.

    4.12.1.7.Disponibilité de KEA et KRA

    Sans objet.

    4.12.2.Politique et pratiques d’encapsulation et de récupération des clés de session

    Sans objet.

    5.Installation, gestion et contrôles opérationnels

    (181)La PKI est composée de la CA racine, de l’EA/AA, du CPOC et du TLM, y compris leurs composants de TIC (par exemple, les réseaux et les serveurs).

    (182)Dans la présente section, l’entité responsable d’un élément de la PLK est identifiée par l’élément lui-même. En d’autres termes, la phrase «la CA est chargée d’exécuter l’audit» est équivalente à «l’entité ou le personnel qui gère la CA est chargé d’exécuter...».

    (183)L’expression «éléments du modèle de confiance des STI-C» comprend la CA racine, le TLM, l’EA/AA, le CPOC et le réseau sécurisé.

    5.1.Contrôles physiques

    (184)Toutes les opérations du modèle de confiance des STI-C sont menées dans un environnement physiquement protégé, qui dissuade, prévient et détecte l’utilisation et l’accès non autorisés des informations et systèmes sensibles ou leur divulgation. Les éléments du modèle de confiance des STI-C utilisent des contrôles de sécurité physique conformément aux normes ISO 27001 et ISO 27005.

    (185)Les entités qui gèrent les éléments du modèle de confiance des STI-C décrivent les contrôles de sécurité physiques, des procédures et du personnel dans leur CPS. En particulier, la CPS couvre des informations sur l’emplacement du site et la construction des bâtiments ainsi que leurs contrôles de sécurité physiques garantissant un accès contrôlé à tous les locaux utilisés dans l’installation des entités du modèle de confiance des STI-C.

    5.1.1.Emplacement et construction des installations

    5.1.1.1.CA racine, CPOC, TLM

    (186)L’emplacement et la construction de l’installation abritant l’équipement et les données de la CA racine, du CPOC et du TLM (HSM, données d’activation, sauvegarde de la paire de clés, ordinateur, journaux de vérification, scénario de la cérémonie des clés, demande de certificat, etc.) sont compatibles avec les installations utilisées pour héberger les informations sensibles et de grande valeur. La CA racine est exploitée dans une zone physique dédiée, séparée des autres zones physiques des composantes de la PKI.

    (187)La CA racine, le CPOC et le TLM mettent en œuvre des politiques et procédures visant à garantir le maintien d’un niveau élevé de sécurité dans l’environnement physique dans lequel l’équipement de la CA racine est installé afin de garantir:

    ·qu’il est isolé des réseaux extérieurs au modèle de confiance;

    ·qu’il est scindé en une série de (au moins deux) périmètres physiques de plus en plus sécurisés;

    ·que les données sensibles (HSM, sauvegarde de paires de clés, données d’activation, etc.) sont stockées dans un coffre dédié situé dans une zone physique dédiée sous un contrôle d’accès multiple.

    (188)Les techniques de sécurité employées sont conçues pour résister à un grand nombre de différentes formes d’attaque qui peuvent être combinées. Les mécanismes utilisés incluent au moins:

    ·des alarmes périmétriques, une télévision en circuit fermé, des murs renforcés et des détecteurs de mouvement;

    ·une authentification à deux facteurs (par exemple, carte à puce et code PIN) pour chaque personne et un badge pour pénétrer dans les installations de la CA racine et dans la zone physique sécurisée et les quitter.

    (189)La CA racine, le CPOC et le TLM utilisent un personnel autorisé pour surveiller constamment l’équipement des installations 7 jours sur 7, 24h sur 24, 365 jours par an. L’environnement opérationnel (par ex. les installations physiques) n’est jamais laissé sans surveillance. Le personnel de l’environnement opérationnel n’a jamais accès aux zones sécurisées de la CA racine ou des sous-CA à moins d’y être autorisé.

    5.1.1.2.EA/AA

    (190)Les mêmes dispositions que celles qui figurent à la section 5.1.1.1 s’appliquent.

    5.1.2.Accès physique

    5.1.2.1.CA racine, CPOC, TLM

    (191)L’équipement et les données (HSM, données d’activation, sauvegarde de paires de clés, ordinateur, journal, scénario de la cérémonie des clés, demande de certificat, etc.) sont toujours protégés contre un accès non autorisé. Les mécanismes de sécurité physique pour les équipements, au minimum:

    ·exercent une surveillance continue, soit manuellement soit par voie électronique, pour repérer toute intrusion non autorisée;

    ·garantissent qu’aucun accès non autorisé au matériel et aux données d’activation n’est permis;

    ·garantissent que tous les supports amovibles et documents papier contenant des informations sensibles en texte clair sont stockés dans un conteneur sécurisé;

    ·garantissent qu’aucune personne non autorisée à titre permanent entrant dans des zones sécurisées n’est laissée hors de la surveillance d’un membre du personnel autorisé de la CA racine, du CPOC et des installations du TLM;

    ·garantissent qu’un registre d’accès est maintenu et contrôlé périodiquement;

    ·fournissent au moins deux couches de sécurité progressivement renforcée, par exemple au niveau du périmètre, du bâtiment et de la salle opérationnelle;

    ·requièrent deux contrôles de l’accès physique des rôles de confiance pour le HSM et les données d’activation cryptographiques.

    (192)Un contrôle de sécurité des installations abritant l’équipement est effectué s’il est prévu de le laisser sans surveillance. Au minimum, le contrôle permet de vérifier que:

    ·l’équipement est dans un état approprié pour le mode de fonctionnement en vigueur;

    ·pour les composantes hors ligne, tout l’équipement est arrêté;

    ·tous les conteneurs de sécurité (enveloppe inviolable, coffre, etc.) sont correctement sécurisés;

    ·les systèmes de sécurité physiques (par exemple, verrous de portes, couvercles d’aération, électricité) fonctionnent correctement;

    ·la zone est protégée contre un accès non autorisé.

    (193)Les modules cryptographiques amovibles sont désactivés avant le stockage. Lorsqu’ils ne sont pas utilisés, ces modules et les données d’activation utilisées pour y accéder ou les activer sont placés dans un coffre. Les données d’activation sont mémorisées ou enregistrées et stockées d’une manière correspondant à la sécurité assurée au module cryptographique. Elles ne sont pas stockées avec le module cryptographique, afin d’éviter qu’une seule personne n’ait accès à la clé privée.

    (194)Une personne ou un groupe assumant de rôles de confiance sont explicitement chargés d’effectuer ces contrôles. Lorsque la responsabilité est confiée à un groupe de personnes, un journal est tenu et identifie la personne qui effectue chaque vérification. Si les installations ne sont pas constamment occupées, la dernière personne à partir paraphe un registre de sortie indiquant la date et l’heure, et confirme que tous les mécanismes de protection physiques nécessaires sont en place et activés.

    5.1.2.2.EA/AA

    (195)Les mêmes dispositions de la section 5.1.2.1 s’appliquent.

    5.1.3.Alimentation électrique et climatisation

    (196)Les installations sécurisées des éléments du modèle de confiance des STI-C (CA racine, CPOC, TLM, EA et AA) sont équipées d’un accès fiable à l’alimentation électrique afin de garantir un fonctionnement sans défaillance ou avec des défaillances mineures. Des installations principales et de secours sont requises en cas de panne d’alimentation externe et il convient d’assurer un arrêt ordonné de l’équipement du modèle de confiance des STIC en cas d’absence d’alimentation. Les installations du modèle de confiance des STI-C sont équipées de systèmes de chauffage/ventilation/climatisation permettant de maintenir la température et l’humidité relative de l’équipement du modèle de confiance des STI-C dans la plage de fonctionnement. La CPS de l’élément du modèle de confiance des STI-C décrira en détail le plan et les processus de mise en œuvre de ces exigences.

    5.1.4.Exposition à l’eau

    (197)Les installations sécurisées des éléments du modèle de confiance des STI-C (CA racine, CPOC, TLM, EA et AA) doivent être protégées de manière à réduire au maximum les conséquences d’une exposition à l’eau. Pour cette raison, il convient d’éviter les canalisations d’eau et les tuyaux d’écoulement. La CPS de l’élément du modèle de confiance des STI-C décrira en détail le plan et les processus de mise en œuvre de ces exigences.

    5.1.5.Prévention et protection contre les incendies

    (198)Pour éviter une exposition dommageable au feu ou à la fumée, les installations sécurisées des éléments du modèle de confiance des STIC (CA racine, CPOC, TLM, EA et AA) sont construites et équipées en conséquence et des procédures sont mises en œuvre pour répondre aux menaces liées au feu. Le stockage des supports doit être protégé contre les incendies dans des conteneurs appropriés.

    (199)Les éléments du modèle de confiance des STI-C protègent les supports physiques contenant des sauvegardes des données de système essentielles ou toute autre information sensible contre les risques de l’environnement ainsi que l’utilisation non autorisée, l’accès et la divulgation. La CPS de l’élément du modèle de confiance des STI-C décrira en détail le plan et les processus de mise en œuvre de ces exigences.

    5.1.6.Gestion des supports

    (200)Les supports utilisés dans les éléments du modèle de confiance des STI-C (CA racine, CPOC, TLM, EA et AA) sont manipulés de manière sécurisée afin d’être protégés de tout dommage, vol et accès non autorisé. Des procédures de gestion des supports sont mises en œuvre afin de protéger les supports contre l’obsolescence et la détérioration au cours de la période pendant laquelle les enregistrements doivent être conservés.

    (201)Les données sensibles sont protégées contre les accès résultant d’une réutilisation d’objets de stockage (par exemple, des fichiers supprimés), qui pourraient rendre les données sensibles accessibles à des utilisateurs non autorisés.

    (202)Un inventaire de toutes les ressources d’information est tenu et les exigences définies pour la protection de ces ressources sont cohérentes avec l’analyse de risque. La CPS de l’élément du modèle de confiance des STI-C décrira en détail le plan et les processus de mise en œuvre de ces exigences.

    5.1.7.Élimination des déchets

    (203)Les éléments du modèle de confiance des STI-C (CA racine, CPOC, TLM, EA et AA) mettent en œuvre des procédures d’élimination sûre et irréversible des déchets (papier, supports ou tout autre déchet) afin d’empêcher que des déchets contenant des informations confidentielles/privées ne fassent l’objet d’une utilisation non autorisée, d’un accès ou d’une divulgation. Tous les supports utilisés pour le stockage des informations sensibles, telles que des clés, des données d’activation ou des fichiers, sont détruits avant d’être évacués pour leur élimination. La CPS de l’élément du modèle de confiance des STI-C décrira en détail le plan et les processus de mise en œuvre de ces exigences.

    5.1.8.Sauvegarde hors site

    5.1.8.1.CA racine, CPOC et TLM

    (204)Des sauvegardes complètes des composantes de la CA racine, du CPOC et du TLM, suffisantes pour permettre une récupération en cas de panne du système, sont effectuées hors ligne après le déploiement de la CA racine, du CPOC et du TLM, et après la création de chaque nouvelle paire de clés. Des copies de sauvegarde des renseignements opérationnels essentiels (paire de clés et CRL) et des logiciels sont effectuées régulièrement. Des dispositifs de sauvegarde adéquats sont fournis de façon à ce que tous les renseignements opérationnels essentiels et les logiciels puissent être récupérés après un sinistre ou une défaillance des supports. Les modalités de sauvegarde pour les systèmes individuels sont régulièrement mises à l’épreuve afin de s’assurer qu’elles satisfont aux exigences du plan de continuité des activités. Au moins une copie de sauvegarde complète est stockée dans un emplacement hors site (récupération après sinistre). La copie de sauvegarde est stockée sur un site présentant des contrôles physiques et des procédures équivalents à ceux du système opérationnel de la PKI.

    (205)Les données de sauvegarde sont soumises aux mêmes exigences d’accès que les données opérationnelles. Les données de sauvegarde sont chiffrées et stockées hors site. En cas de perte totale des données, les informations requises pour remettre la CA racine, le CPOC et le TLM en exploitation sont entièrement récupérées à partir des données de sauvegarde.

    (206)Le matériel privé de la CA racine, du CPOC et du TLM signé avec clé n’est pas sauvegardé au moyen de mécanismes de sauvegarde standard, mais en utilisant la fonction de sauvegarde du module cryptographique.

    5.1.8.2.EA/AA

    (207)Les processus décrits dans la section 5.1.8.1 s’appliquent à la présente section.

    5.2.Contrôles des procédures

    La présente section décrit les exigences applicables aux rôles, aux fonctions et à l’identification des membres du personnel.

    5.2.1.Rôles de confiance

    (208)Les membres du personnel, les contractants et les consultants qui se voient assigner des rôles de confiance sont considérés comme des «personnes de confiance». Les personnes souhaitant devenir des personnes de confiance pour obtenir un poste de confiance respectent les exigences de contrôle de la présente politique de certification.

    (209)Les personnes de confiance contrôlent ou ont accès aux opérations d’authentification ou cryptographiques susceptibles d’affecter sensiblement:

    ·la validation des informations contenues dans des demandes de certificats;

    ·l’acceptation, le rejet ou autre traitement des demandes de certificats, des demandes de déchéance ou des demandes de renouvellement;

    ·la délivrance ou la révocation des certificats, y compris le personnel ayant accès à des parties restreintes de leur répertoire ou le traitement des informations ou des demandes relatives aux souscripteurs.

    (210)Les rôles de confiance comprennent, mais sans s’y limiter:

    ·le service à la clientèle;

    ·l’administration du système;

    ·l’ingénierie désignée;

    ·les cadres chargés de la gestion de la fiabilité de l’infrastructure.

    (211)La CA fournit des descriptions claires de tous les rôles de confiance dans sa CPS.

    5.2.2.Nombre de personnes requises par tâche

    (212)Les éléments du modèle de confiance des STI-C établissent, maintiennent et appliquent des procédures de contrôle rigoureuses pour garantir la séparation des tâches fondées sur les rôles de confiance et veiller à ce que plusieurs personnes de confiance soient requises pour exécuter les tâches sensibles. Les éléments du modèle de confiance des STI-C (TLM, CPOC, CA racine, EA et AA) doivent satisfaire à [4] ainsi qu’aux exigences énoncées dans les paragraphes suivants.

    (213)Une politique et des procédures de contrôle sont en place pour garantir une séparation des tâches fondée sur les responsabilités inhérentes au poste. Les tâches les plus sensibles, telles que l’accès au matériel cryptographique de la CA (HSM) et à son matériel connexe signé avec clé, ainsi que leur gestion, doivent requérir l’autorisation de plusieurs personnes de confiance.

    (214)Ces procédures de contrôle internes sont conçues de façon à ce qu’au moins deux personnes de confiance soient requises pour avoir un accès physique ou logique au dispositif. Les restrictions relatives à l’accès au matériel cryptographique de la CA doivent être strictement appliquées par plusieurs personnes de confiance tout au long de son cycle de vie, de la réception et l’inspection à l’entrée à la destruction logique et/ou physique finale. Une fois qu’un module est activé avec des clés opérationnelles, de nouveaux contrôles de l’accès sont invoqués pour maintenir un contrôle fractionné sur l’accès tant physique que logique au dispositif.

    5.2.3.Identification et authentification pour chaque rôle

    (215)Toutes les personnes assignées à un rôle, telles que décrites dans la présente CP, sont identifiées et authentifiées de manière à garantir que le rôle leur permet d’exécuter leurs tâches de la PKI.

    (216)Les éléments du modèle de confiance des STI-C vérifient et confirment l’identité et l’autorisation de toutes les personnes souhaitant devenir des personnes de confiance avant qu’elles ne se voient:

    ·délivrer leurs dispositifs d’accès et l’accès aux installations requises;

    ·accorder les authentifiants électroniques pour accéder à des fonctions spécifiques sur les systèmes de la CA et les exécuter.

    (217)La CPS décrit les mécanismes utilisés pour identifier et authentifier les personnes.

    5.2.4.Rôles nécessitant une séparation des tâches

    (218)Les rôles nécessitant une séparation des tâches sont notamment (liste non exhaustive):

    ·l’acceptation, le rejet et la révocation des demandes, et autre traitement de demandes de certificats de la CA;

    ·la création, la délivrance et la destruction d’un certificat de la CA.

    (219)La séparation des tâches peut être réalisée au travers de l’équipement de la PKI et/ou de procédures. Aucune personne ne peut se voir attribuer plus d’une identité, sauf autorisation de la CA racine.

    (220)La partie de la CA racine et de la CA concernée par la gestion de la création et de la révocation des certificats est indépendante des autres organisations pour ses décisions relatives à l’établissement, à la prestation, au maintien et à la suspension de services conformément aux politiques de certification applicables. En particulier, son encadrement supérieur, son encadrement et son personnel investis de rôle de confiance sont exempts de toute pression commerciale, financière ou autre, susceptible d’influencer négativement la confiance dans les services qu’elle fournit.

    (221)L’EA et l’AA qui servent les stations STI-C mobiles sont des entités opérationnelles distinctes, avec une infrastructure informatique et des équipes de gestion informatique distinctes. Conformément au RGPD, l’EA et l’AA n’échangent aucune donnée à caractère personnel, sauf pour l’autorisation des demandes d’AT. Elles transfèrent les données relatives à l’approbation des demandes d’AT en utilisant uniquement le protocole de validation des autorisations de [1], sur une interface sécurisée réservée. D’autres protocoles peuvent être utilisés, pour autant que [1] soit mise en œuvre.

    (222)Les fichiers journaux stockés par l’EA et l’AA ne peuvent être utilisés qu’aux seules fins de la révocation des EC présentant un comportement anormal sur la base des AT dans des messages CAM/DENM malveillants interceptés. Après l’identification d’un message CAM/DENM comme étant malveillant, l’AA examinera la clé de vérification de l’AT dans ses journaux de délivrance et soumettra une demande de révocation à l’EA contenant la signature chiffrée sous la clé privée de l’EC qui a été utilisée lors de la délivrance de l’AT. Tous les fichiers journaux doivent être suffisamment protégés contre l’accès par des parties non autorisées et ne peuvent être partagés avec d’autres entités ou autorités.

    Remarque: Au moment de la rédaction de la présente version de la CP, la fonction d’anomalie de comportement n’a pas été mise au point. L’éventuelle mise au point de la fonction d’anomalie de comportement est envisagée dans le cadre de futures révisions de la politique.

    5.3.Contrôles du personnel

    5.3.1.Exigences en matière de qualifications, d’expérience et d’habilitation de sécurité

    (223)Les éléments du modèle de confiance des STI-C emploient un personnel en nombre suffisant, possédant l’expertise, l’expérience et les qualifications requises pour les fonctions inhérentes au poste et les services offerts. Le personnel d’une PKI satisfait à ces exigences en faisant valoir une formation et des références officielles et/ou une expérience concrète. Les rôles de confiance et les responsabilités, tels que précisés dans la CPS, sont documentés dans les descriptions de poste et clairement définis. Pour les sous-traitants du personnel d’une PKI, les descriptions de poste sont conçues afin de garantir la séparation des tâches et des privilèges, et la sensibilité du poste est déterminée sur la base des tâches et des niveaux d’accès, d’un examen des antécédents ainsi que de la formation et de la sensibilisation du personnel.

    5.3.2.Procédures de vérification des antécédents

    (224)Les éléments du modèle de confiance des STI-C procèdent à la vérification des antécédents concernant les membres du personnel désireux de devenir des personnes de confiance. Les vérifications des antécédents sont réitérées pour le personnel occupant des postes de confiance au moins tous les cinq ans.

    (225)Les facteurs suivants (liste non exhaustive), mis en évidence lors d’une vérification des antécédents, peuvent être considérés comme des motifs de rejet d’une candidature à un poste de confiance ou d’adoption de mesures à l’encontre d’une personne de confiance existante:

    ·des déclarations erronées faites par le candidat ou la personne de confiance;

    ·des références professionnelles très négatives ou peu fiables;

    ·certaines condamnations pénales;

    ·des indices d’une absence de responsabilité financière.

    (226)Les rapports contenant ces informations sont évalués par le personnel des ressources humaines, qui prend des mesures raisonnables compte tenu de la nature, de l’ampleur et de la fréquence du comportement mis au jour par la vérification des antécédents. Cette action peut inclure des mesures allant jusqu’à l’annulation des offres d’emploi faites aux candidats pour des postes de confiance ou à la résiliation du contrat de travail des personnes de confiance existantes. L’utilisation d’informations révélées dans le cadre d’une vérification des antécédents est soumise à la législation applicable.

    (227)Une enquête sur les antécédents des personnes souhaitant devenir des personnes de confiance inclut, sans s’y limiter:

    ·la confirmation d’un emploi antérieur;

    ·une vérification des références professionnelles couvrant une durée d’emploi d’au moins cinq ans;

    ·une confirmation du diplôme le plus élevé ou le plus pertinent obtenu;

    ·une recherche de casier judiciaire.

    5.3.3.Exigences en matière de formation

    (228)Les éléments du modèle de confiance des STI-C dispensent aux membres de leur personnel la formation requise pour qu’ils puissent s’acquitter avec compétence et de manière satisfaisante de leurs responsabilités liées aux opérations de la CA.

    (229)Les programmes de formation sont réexaminés régulièrement et les formations abordent des questions qui intéressent les fonctions exercées par les membres de leur personnel.

    (230)Les programmes de formation abordent des questions importantes pour l’environnement spécifique de la personne en formation, notamment:

    ·les principes et les mécanismes de sécurité du modèle de confiance des STI-C;

    ·les versions du matériel et du logiciel utilisés;

    ·l’ensemble des tâches dont la personne est supposée s’acquitter, et les procédures et séquences d’établissement de rapports internes et externes;

    ·les processus d’entreprise et flux de travail d’une PKI;

    ·le signalement et le traitement des incidents et compromissions;

    ·les procédures de récupération et continuité des activités après sinistre;

    ·des connaissances informatiques suffisantes.

    5.3.4.Fréquence et exigences en matière de recyclage

    (231)Les personnes assignées à des rôles de confiance sont tenues de rafraîchir de façon continue à l’aide d’un environnement de formation les connaissances qu’elles ont acquises par la formation. La formation doit être répétée autant de fois que nécessaire et au moins tous les deux ans.

    (232)Les éléments du modèle de confiance des STI-C offrent aux membres de leur personnel une formation de remise à niveau et des mises à jour dans la mesure et avec la fréquence requises pour garantir le maintien du niveau de compétence requis dont ils ont besoin pour s’acquitter avec compétence et de manière satisfaisante de leurs responsabilités inhérentes au poste.

    (233)Les personnes occupant des rôles de confiance sont informées des modifications intervenant dans les opérations de la PKI, le cas échéant. Toute modification significative apportée aux opérations est accompagnée d’un plan de formation (sensibilisation) et l’exécution de ce plan est documentée.

    5.3.5.Fréquence et séquence de rotation des postes

    (234)Aucune stipulation tant que les compétences techniques, l’expérience et les droits d’accès sont assurés. Les administrateurs des éléments du modèle de confiance des STI-C veillent à ce que les changements dans le personnel n’affectent pas la sécurité du système.

    5.3.6.Sanctions pour des actions non autorisées

    (235)Chaque élément du modèle de confiance des STI-C doit élaborer un processus disciplinaire formel afin de garantir que les actions non autorisées sont dûment sanctionnées. Dans les cas les plus graves, l’assignation des rôles et les privilèges correspondants doivent être retirés.

    5.3.7.Exigences concernant les contractants indépendants

    (236)Les éléments du modèle de confiance des STI-C ne peuvent autoriser des contractants ou des consultants indépendants à devenir des personnes de confiance que dans la mesure où des relations de sous-traitance clairement définies l’exigent et à condition que l’entité ait confiance dans ces contractants ou consultants au même titre que s’ils faisaient partie de son personnel et que ceux-ci se conforment aux exigences applicables aux membres du personnel.

    (237)Dans le cas contraire, les contractants et consultants indépendants n’ont accès aux installations sécurisées de la PKI des STI-C que s’ils sont escortés et sous la surveillance directe de personnes de confiance.

    5.3.8.Documentation fournie au personnel

    (238)Les éléments du modèle de confiance des STI-C dispensent aux membres de leur personnel la formation requise et leur donnent accès à la documentation qui leur est nécessaire pour s’acquitter avec compétence et de manière satisfaisante de leurs responsabilités inhérentes au poste.

    5.4.Procédures relatives aux journaux d’audit

    (239)La présente section définit les exigences en ce qui concerne les types d’événements à enregistrer et la gestion des journaux d’audit.

    5.4.1.Types d’événements à enregistrer et à signaler par chaque CA

    (240)Un représentant de la CA vérifie régulièrement les journaux, les événements et les procédures de la CA.

    (241)Les éléments du modèle de confiance des STI-C enregistrent les types suivants d’événements d’audit (le cas échéant):

    ·accès aux installations physiques: l’accès par des personnes physiques aux installations sera enregistré par stockage des demandes d’accès à l’aide de cartes à puce. Un événement sera créé pour chaque enregistrement créé;

    ·gestion des rôles de confiance: tout changement dans la définition et le niveau d’accès des différents rôles sera enregistré, y compris la modification des attributs des rôles. Un événement sera créé pour chaque enregistrement créé;

    ·accès logique: un événement sera créé lorsqu’une entité (par ex. un programme) a accès aux zones sensibles (c.-à-d. réseaux et serveurs);

    ·gestion de sauvegarde: un événement est créé chaque fois qu’une sauvegarde est effectuée, avec ou sans succès;

    ·gestion des journaux: les journaux seront conservés. Un événement est créé lorsque le journal excède une taille déterminée;

    ·données du processus d’authentification pour les souscripteurs et les éléments du modèle de confiance des STI-C: des événements seront créés pour chaque demande d’authentification effectuée par les souscripteurs et les éléments du modèle de confiance des STI-C;

    ·acceptation et rejet des demandes de certificats, y compris la création et le renouvellement de certificats: un événement sera créé périodiquement avec une liste des demandes de certificats acceptées et rejetées au cours des sept derniers jours;

    ·enregistrement des fabricants: un événement sera créé lorsqu’un fabricant est enregistré;

    ·enregistrement d’une station STI-C: un événement sera créé lorsqu’une station STI-C est enregistrée;

    ·gestion du HSM: un événement sera créé lorsqu’une violation de la sécurité du HSM est enregistrée;

    ·gestion informatique et de réseau, dans la mesure où elle concerne les systèmes de la PKI: un événement sera créé lorsqu’un serveur de la PKI est arrêté ou relancé;

    ·gestion de la sécurité (tentatives fructueuses et infructueuses d’accès au système de la PKI, réalisation d’actions relatives à la PKI et au système de sécurité, changements du profil de sécurité, pannes du système, pannes de matériel et autres anomalies, activités relatives au pare-feu et au routeur; et entrées dans les installations de la PKI et sorties);

    ·les données liées aux événements seront conservées pendant au moins cinq ans, sauf si des règles nationales supplémentaires sont applicables.

    (242)Conformément au RGPD, les journaux d’audit ne permettent pas l’accès aux données relatives à la vie privée en ce qui concerne les véhicules privés équipés d'une station STI-C.

    (243)Dans la mesure du possible, les journaux d’audit de sécurité sont collectés automatiquement. Lorsque cela n’est pas possible, un journal, un formulaire papier ou un autre mécanisme physique est utilisé. Tous les journaux d’audit de sécurité, tant électroniques que non électroniques, sont conservés et mis à disposition au cours des audits de conformité.

    (244)Chaque événement lié au cycle de vie du certificat est journalisé de manière à pouvoir être attribué à la personne qui l’a exécuté. Toutes les données relatives à une identité personnelle sont chiffrées et protégées contre les accès non autorisés.

    (245)Au minimum, chaque enregistrement d’audit comprend les éléments suivants (enregistrés automatiquement ou manuellement pour chaque événement vérifiable):

    ·type d’événement (à partir de la liste ci-dessus);

    ·date et heure certifiées auxquelles l’événement s’est produit;

    ·résultat de l’événement — réussite ou échec s’il y a lieu;

    ·identité de l’entité et/ou de l’exploitant qui a causé l’événement, le cas échéant;

    ·identité de l’entité à laquelle l’événement s’adresse.

    5.4.2.Fréquence de traitement des journaux

    (246)Les journaux d’audit sont examinés en réponse à des alertes fondées sur des irrégularités et des incidents dans les systèmes de la CA et le sont en outre périodiquement, chaque année.

    (247)Le traitement des journaux d’audit consiste à passer ces journaux en revue et à justifier par des documents tous les événements significatifs dans une synthèse des journaux d’audit. Les revues des journaux d’audit comprennent une vérification que le journal n’a pas été altéré, un contrôle de toutes les entrées du journal et une enquête sur toute alerte ou irrégularité dans les journaux. Les mesures prises sur la base des revues des journaux d’audit sont documentées.

    (248)Le journal d’audit est archivé au moins une fois par semaine. Un administrateur l’archive manuellement si l’espace libre du disque pour le journal d’audit est inférieur au volume escompté des données du journal d’audit produites au cours de la semaine.

    5.4.3.Période de conservation des journaux d’audit

    (249)Les enregistrements de journaux relatifs aux cycles de vie des certificats sont conservés pendant au moins cinq ans après l’expiration du certificat correspondant.

    5.4.4.Protection des journaux d’audit

    (250)L’intégrité et la confidentialité du journal d’audit sont garanties par un mécanisme de contrôle de l’accès basé sur les rôles. Seuls les administrateurs peuvent accéder aux journaux d’audit internes; les utilisateurs disposant d’une autorisation appropriée peuvent également accéder aux journaux d’audit relatifs au cycle de vie des certificats via une page web avec un identifiant de connexion. L’accès doit être accordé avec une authentification multi-utilisateurs (au moins deux utilisateurs) et à deux niveaux au moins. Il y a lieu de garantir techniquement que les utilisateurs ne peuvent pas accéder à leurs propres fichiers journaux.

    (251)Chaque entrée aux journaux est signée avec une clé provenant du HSM.

    (252)Les journaux des événements contenant des informations pouvant conduire à une identification personnelle, telle qu’un véhicule privé, sont chiffrés de manière à ce que seules les personnes autorisées puissent les lire.

    (253)Les événements sont journalisés de manière à ce qu'ils ne puissent pas être facilement supprimés ou détruits (sauf pour un transfert vers des supports de longue durée) au cours de la période pendant laquelle les journaux doivent être conservés.

    (254)Les journaux d’événements sont protégés de manière à rester lisibles pendant toute la durée de leur stockage.

    5.4.5.Procédures de sauvegarde des journaux d’audit

    (255)Les journaux d’audit et les synthèses sont sauvegardés via des mécanismes de sauvegarde d’entreprise, sous le contrôle des rôles de confiance autorisés, séparés de la génération de la source de leurs composantes. Les sauvegardes des journaux d’audit sont protégées avec le même niveau de confiance qui s’applique aux journaux originaux.

    5.4.6.Système de collecte des audits (interne ou externe)

    (256)L’équipement des éléments du modèle de confiance des STI-C active les processus d’audit au démarrage du système et ne les désactive qu’à l’arrêt du système. Si les processus d’audit ne sont pas disponibles, l’élément du modèle de confiance des STI-C suspend son fonctionnement.

    (257)À la fin de chaque période d’exploitation et lors de la régénération des clés de certificats, le statut collectif des équipements doit être signalé au gestionnaire des opérations et à l’organe régissant les opérations de l’élément de la PKI correspondant.

    5.4.7.Notification du sujet ayant causé un événement

    (258)Lorsqu’un événement est journalisé par le système de collecte de l’audit, cela garantit que l’événement est lié à un rôle de confiance.

    5.4.8.Évaluation des vulnérabilités

    (259)Le rôle chargé de réaliser l’audit et les rôles chargés de réaliser les opérations du système de la PKI dans les éléments du modèle de confiance des STI-C expliquent tous les événements significatifs dans une synthèse des journaux d’audit. Ces revues comprennent une vérification que le journal n’a pas été altéré et qu’il n’y a pas de discontinuité ou d’autre perte de données d’audit, puis un bref contrôle de toutes les entrées du journal, assorti d’une enquête plus approfondie de toutes les alertes ou irrégularités dans les journaux. Les mesures prises à la suite de ces revues sont documentées.



    (260)Les éléments du modèle de confiance STI-C:

    ·mettent en œuvre des contrôles de détection et de prévention organisationnels et/ou techniques sous le contrôle des éléments du modèle de confiance des STI-C afin de protéger les systèmes de la PKI contre les virus et les logiciels malveillants;

    ·documentent et suivent un processus de correction des vulnérabilités qui couvre l’identification, l’examen, la réponse et la correction des vulnérabilités;

    ·subissent ou exécutent une analyse des vulnérabilités:

    ·après toute modification du système ou du réseau déterminée par les éléments du modèle de confiance des STI-C comme étant importante pour les composantes de la PKI; et

    ·au moins une fois par mois, sur les adresses IP publiques et privées indiquées par la CA, le CPOC comme étant les systèmes de la PKI,

    ·subissent un essai de pénétration sur les systèmes de la PKI, au moins une fois par an et après des mises à jour ou des modifications des infrastructures ou des applications, déterminées par les éléments du modèle de confiance des STI-C comme étant significatives pour la composante de la PKI de la CA;

    ·pour les systèmes en ligne, enregistrent les éléments prouvant que chaque analyse des vulnérabilités et essai de pénétration ont été réalisés par une personne ou une entité (ou un groupe collectif de ces dernières) disposant des compétences, des outils, des connaissances, du code de déontologie et de l’indépendance nécessaires pour fournir un essai de vulnérabilité ou de pénétration fiable;

    ·repèrent les vulnérabilités et y remédient conformément aux politiques d’entreprise en matière de cybersécurité et à la méthodologie d’atténuation des risques.

    5.5.Archivage des enregistrements

    5.5.1.Types d’enregistrements archivés

    (261)Les éléments du modèle de confiance des STI-C archivent des enregistrements suffisamment détaillés pour permettre d’établir la validité d’une signature et le bon fonctionnement de la PKI. Au minimum, les enregistrements des événements de la PKI suivants sont archivés (le cas échéant):

    ·journal des accès physiques aux installations des éléments du modèle de confiance des STI-C (au minimum un an);

    ·journal de gestion des rôles de confiance pour les éléments du modèle de confiance des STI-C (minimum dix ans);

    ·journal des accès informatiques pour les éléments du modèle de confiance des STI-C (minimum cinq ans);

    ·journal de la création, de l’utilisation et de la destruction des clés de la CA (minimum cinq ans) (pas pour le TLM et le CPOC);

    ·journal de la création, de l’utilisation et de la destruction des certificats (minimum deux ans);

    ·journal des demandes de la CPA (minimum deux ans);

    ·journal de la gestion des données d’activation pour les éléments du modèle de confiance des STI-C (minimum cinq ans);

    ·journal informatique et de réseau pour les éléments du modèle de confiance des STI-C (minimum cinq ans);

    ·documentation de la PKI pour les éléments du modèle de confiance des STI-C (minimum cinq ans);

    ·rapport des incidents de sécurité et d’audit pour les éléments du modèle de confiance des STI-C (minimum dix ans);

    ·équipement, logiciels et configuration du système (minimum cinq ans).

    (262)Les éléments du modèle de confiance des STI-C conservent les documents suivants relatifs aux demandes de certificats et à leur vérification, et tous les certificats des TLM, des CA racine et des CA ainsi que leur CRL, au moins sept ans après l’expiration de la validité de tout certificat basé sur ces documents:

    ·documents d’audit de la PKI conservés par les éléments du modèle de confiance des STI-C;

    ·documents de la CPS conservés par les éléments du modèle de confiance des STI-C;

    ·contrat entre la CPA et d’autres entités conservé par les éléments du modèle de confiance des STI-C;

    ·certificats (ou autres informations de révocation) conservés par la CA et le TLM;

    ·enregistrements des demandes de certificats dans le système de la CA racine (non applicable au TLM);

    ·autres données ou applications permettant de vérifier le contenu des archives;

    ·tous travaux liés aux éléments du modèle de confiance des STI-C et aux auditeurs de la conformité ou provenant de ceux-ci.

    (263)L’entité de la CA conserve tous les documents relatifs aux demandes de certificats et à leur vérification, et tous les certificats ainsi que leur révocation, pendant au moins sept ans après l’expiration de la validité de tout certificat fondé sur ces documents.

    5.5.2.Période de conservation des archives

    (264)Sans préjudice des réglementations exigeant une période d’archivage plus longue, les éléments du modèle de confiance des STI-C conservent tous les enregistrements pendant au moins cinq ans après l’expiration du certificat correspondant.

    5.5.3.Protection des archives

    (265)Les éléments du modèle de confiance des STI-C conservent l’archive des enregistrements dans une installation de stockage sûre et sécurisée séparée de l’équipement de la CA, avec des contrôles de sécurité physique et procédurale équivalents ou supérieurs à ceux de la PKI.

    (266)L’archive est stockée dans un système fiable qui garantit sa protection contre toute consultation, modification, suppression ou autre altération non autorisée.

    (267)Les supports contenant les données d’archive et les applications requises pour les traiter sont maintenus de façon à ce qu’il soit possible d’y accéder pendant la période prévue dans la présente CP.

    5.5.4.Archives système et stockage

    (268)Les éléments du modèle de confiance des STI-C sauvegardent au fur et à mesure les archives système de ces informations sur une base quotidienne et effectuent des sauvegardes intégrales sur une base hebdomadaire. Des copies des enregistrements papier sont conservées dans une installation sécurisée hors site.

    5.5.5.Exigences d’horodatage des enregistrements

    (269)Les éléments du modèle de confiance des STI-C qui gèrent une base de données des révocations veillent à ce que les enregistrements contiennent des informations relatives à l’heure et à la date de création des enregistrements de révocation. L’intégrité de ces informations sera mise en œuvre à l’aide de solutions basées sur la cryptographie.

    5.5.6.Système de collecte des archives (interne ou externe)

    (270)Le système de collecte des archives est interne.

    5.5.7.Procédures d’obtention et de vérification des informations archivées

    (271)Tous les éléments du modèle de confiance des STI-C ne permettent l’accès aux archives qu’aux personnes de confiance autorisées. Les CA racine et les CA décrivent les procédures pour la création, la vérification, l’assemblage, la transmission et le stockage des informations archivées dans la CPS.

    (272)L’équipement de la CA racine et de la CA vérifie l’intégrité des informations avant leur restauration.

    5.6.Changement de clés pour les éléments du modèle de confiance des STI-C

    (273)Les éléments suivants du modèle de confiance des STI-C appliquent des exigences spécifiques pour leur changement de clés: certificats du TLM, de la CA racine et de l’EA/AA.

    5.6.1.TLM

    (274)Le TLM efface sa clé privée à l’expiration du certificat correspondant. Il génère une nouvelle paire de clés et le certificat du TLM correspondant avant la désactivation de la clé privée valide en vigueur. Il veille à ce que le nouveau certificat (de lien) soit inséré dans l’ECTL à temps pour être distribué à toutes les stations STI-C avant de devenir valide. Le certificat de lien et le nouveau certificat autosigné sont transférés au CPOC.

    5.6.2.CA racine

    (275)La CA racine désactive et supprime la clé privée en vigueur (y compris les clés de sauvegarde), de sorte qu’elle ne délivrera pas de certificats d’EA/AA dont la validité s’étend au-delà de la validité du certificat de la CA racine.

    (276)La CA racine génère une nouvelle paire de clés et les certificats de la CA racine et de lien correspondants avant la désactivation de la clé privée en vigueur (y compris des clés de sauvegarde) et l’envoie au TLM pour insertion dans l’ECTL. La période de validité du nouveau certificat de la CA racine débute lors de la désactivation prévue de la clé privée en vigueur. La CA racine veille à ce que le nouveau certificat soit inséré dans l’ECTL à temps pour être distribué à toutes les stations STI-C avant de devenir valide.

    (277)La CA racine active la nouvelle clé privée lorsque le certificat de la CA racine correspondant devient valide.

    5.6.3.Certificat d’EA/AA

    (278)L’EA/AA désactive la clé privée en vigueur de façon à ne pas délivrer d’EC/AT dont la validité s’étend au-delà de la validité du certificat d’EA/AA.

    (279)L’EA/AA génère une nouvelle paire de clés et demande un certificat d’EA/AA correspondant avant la désactivation de la clé privée en vigueur. La durée de validité du nouveau certificat d’EA/AA débute lors de la désactivation prévue de la clé privée en vigueur. L’EA/AA veille à ce que le nouveau certificat puisse être publié à temps pour être distribué à toutes les stations STI-C avant de devenir valide.

    (280)L’EA/AA active la nouvelle clé privée lorsque le certificat d’EA/AA devient valide.

    5.6.4.Auditeur

    Aucune disposition

    5.7.Compromission et reprise après sinistre

    5.7.1.Traitement des incidents et des compromissions

    (281)Les éléments du modèle de confiance des STI-C contrôlent leurs équipements sur une base continue, de façon à détecter d’éventuelles tentatives de piratage ou d’autres formes de compromission. Lorsqu’un tel événement se produit, ils enquêtent afin de déterminer la nature et le degré du préjudice.

    (282)Si le personnel chargé de la gestion de la CA racine ou du TLM détecte une possible tentative de piratage ou une autre forme de compromission, il enquête afin de déterminer la nature et le degré du préjudice. En cas de compromission de la clé privée, le certificat de la CA racine est révoqué. Les experts en sécurité informatique de la CPA évaluent la portée du préjudice éventuel afin de déterminer s’il est nécessaire de rétablir la PKI, si seuls certains certificats doivent être révoqués et/ou si la PKI a été compromise. En outre, la CPA détermine quels sont les services qui doivent être maintenus (révocation et informations sur le statut du certificat) et de quelle façon, conformément au plan de continuité des activités de la CPA.

    (283)Les incidents, la compromission et la continuité des activités sont couverts dans la CPS, qui peut également s’appuyer sur d’autres ressources et plans d’entreprise pour sa mise en œuvre.

    (284)Si le personnel chargé de la gestion de l’EA/de l’AA/du CPOC détecte une possible tentative de piratage ou une autre forme de compromission, il enquête afin de déterminer la nature et le degré du préjudice. Le personnel chargé de la gestion de l’entité de la CA ou du CPOC évalue l’ampleur du préjudice éventuel afin de déterminer si la composante de la PKI doit être rétablie, si seuls certains certificats doivent être révoqués et/ou si la composante de la PKI a été compromise. En outre, l’entité de la sous-CA détermine quels services doivent être maintenus et de quelle façon, conformément au plan de continuité des activités de l’entité de la sous-CA. En cas de compromission d’une composante de la PKI, l’entité de la CA alerte sa propre CA racine et le TLM par l'intermédiaire du CPOC.

    (285)Les incidents, la compromission et la continuité des activités sont couverts dans la CPS de la CA racine ou du TLM, ou d’autres documents pertinents dans le cas du CPOC, qui peut également s’appuyer sur d’autres ressources et plans d’entreprise pour leur mise en œuvre.

    (286)La CA racine et la CA alertent, en fournissant des informations précises sur les conséquences de l’incident, chaque représentant des États membres et chaque CA racine avec lesquels elles ont signé un accord dans le cadre des STI-C, afin de leur permettre d’activer leur propre plan de gestion des incidents.

    5.7.2.Corruption des ressources informatiques, des logiciels et/ou des données

    (287)Si un sinistre qui empêche le bon fonctionnement d’un élément du modèle de confiance des STI-C est découvert, cet élément suspend son fonctionnement et examine si la clé privée a été compromise (sauf le CPOC). Le matériel défectueux est remplacé le plus rapidement possible et les procédures décrites dans les sections 5.7.3 et 5.7.4 s’appliquent.

    (288)La corruption des ressources informatiques, des logiciels et/ou des données est signalée à la CA racine dans les 24 heures pour les niveaux de risque les plus élevés. Tous les autres événements doivent être inclus dans le rapport périodique de la CA racine, des EA et des AA.

    5.7.3.Procédures en cas de compromission de la clé privée d’une entité

    (289)Si la clé privée d’une CA racine est compromise, perdue, détruite ou soupçonnée d’être compromise, la CA racine:

    ·suspend son fonctionnement;

    ·lance le plan de rétablissement après sinistre et de migration;

    ·révoque son certificat de CA racine;

    ·enquête sur le «problème de clé» qui a généré la compromission et informe la CPA, qui révoquera le certificat de CA racine par l'intermédiaire du TLM (voir section 7);

    ·alerte tous les souscripteurs avec lesquels elle a conclu un accord.

    (290)Si une clé de l’EA/AA est compromise, perdue, détruite ou soupçonnée d’être compromise, l’EA/AA:

    ·suspend son fonctionnement;

    ·révoque son propre certificat;

    ·enquête sur le «problème de clé» et informe la CA racine;

    ·alerte les souscripteurs avec lesquels il existe un accord.

    (291)Si la clé de l’EC ou de l’AT d’une station STI-C est compromise, perdue, détruite ou soupçonnée d’être compromise, l’EA/AA auxquelles la station STI-C a souscrit:

    ·révoque l’EC de la STI concernée;

    ·enquête sur le «problème de clé» et informe la CA racine;

    ·alerte les souscripteurs avec lesquels elle a conclu un accord.

    (292)Lorsque l’un des algorithmes ou des paramètres associés utilisés par la CA racine et/ou la CA ou les stations STI-C ne suffit plus pour le restant de son usage prévu, la CPA (avec une recommandation des experts en cryptographie) informe l’entité de la CA racine avec laquelle elle a conclu un accord et modifie les algorithmes utilisés. (Pour plus de détails, voir la section 6 et les CPS de la CA racine et de la sous-CA).

    5.7.4.Capacités en matière de continuité des activités après un sinistre

    (293)Les éléments du modèle de confiance des STI-C exploitant des installations sécurisées pour les opérations de la CA élaborent, testent, maintiennent et mettent en œuvre un plan de rétablissement après sinistre visant à atténuer les effets de tout sinistre d’origine naturelle ou humaine. Ces plans couvrent la restauration des services des systèmes d’information et des principales fonctions opérationnelles.

    (294)Après un incident d’un certain niveau de risque, la CA compromise doit être auditée à nouveau par un auditeur agréé de la PKI (voir section 8).

    (295)Lorsque la CA compromise n’est pas en mesure de fonctionner plus longtemps (par exemple, à la suite d’un grave incident), un plan de migration doit être établi pour le transfert de ses fonctions à une autre CA racine. La CA racine de l’UE est au moins disponible pour soutenir le plan de migration. La CA compromise cesse ses fonctions.

    (296)Les CA racine incluent le plan de rétablissement après sinistre et le plan de migration dans la CPS.

    5.8.Cessation et transfert

    5.8.1.TLM

    (297)Le TLM ne met pas fin à son fonctionnement, mais une entité gérant le TLM peut reprendre une autre entité.

    (298)En cas de changement de l’entité de gestion:

    ·il demande l’approbation de la CPA pour un changement de gestion du TLM, de l’ancienne entité à la nouvelle entité;

    ·la CPA approuve le changement de gestion du TLM;

    ·tous les journaux d’audit et les enregistrements archivés sont transférés de l’ancienne entité de gestion à la nouvelle entité.

    5.8.2.CA racine

    (299)La CA racine ne cesse/débute pas son fonctionnement avant d’avoir établi un plan de migration (prévu dans la CPS correspondante) qui garantit un fonctionnement continu à tous les souscripteurs.

    (300)En cas de cessation du service de la CA racine, la CA racine:

    ·informe la CPA;

    ·informe le TLM afin qu’il puisse supprimer le certificat de la CA racine de l’ECTL;

    ·révoque la CA racine correspondante en délivrant une CRL sur laquelle elle figure;

    ·alerte les CA racine avec lesquelles elle a conclu un accord pour le renouvellement des certificats d’EA/AA;

    ·détruit la clé privée de la CA racine;

    ·communique les dernières informations relatives au statut de révocation (CRL signée par la CA racine) à la partie utilisatrice, en indiquant clairement qu’il s’agit des dernières informations de révocation;

    ·archive tous les journaux d’audit et autres enregistrements avant la cessation de la PKI;

    ·transfère les enregistrements archivés à l’autorité appropriée.

    (301)Le TLM supprime le certificat de la CA racine correspondant de l’ECTL.

    5.8.3.EA/AA

    (302)En cas de cessation du service de l’EA/AA, l’entité de l’EA/AA donne un préavis de cessation. Une EA ou AA ne cesse/débute pas son fonctionnement avant d’avoir établi un plan de migration (prévu dans la CPS correspondante) qui garantit un fonctionnement continu à tous les souscripteurs. L’EA/AA:

    ·informe la CA racine par lettre recommandée;

    ·détruit la clé privée de la CA;

    ·transfère sa base de données à l’entité désignée par la CA racine;

    ·cesse de délivrer des certificats;

    ·pendant le transfert de sa base de données et jusqu’à ce que la base de données soit pleinement opérationnelle dans une nouvelle entité, maintient la capacité d’autoriser des demandes émanant de l’autorité de protection de la vie privée responsable;

    ·lorsqu’une sous-CA a été compromise, la CA racine révoque la sous-CA et émet une nouvelle CRL avec une liste des sous-CA révoquées;

    ·archive tous les journaux d’audit et autres enregistrements avant de résilier la PKI;

    ·transfère les enregistrements archivés à une entité désignée par la CA racine.

    (303)En cas de cessation des services de la CA, la CA est chargée de conserver tous les enregistrements pertinents concernant les composantes de la CA et de la PKI.

    6.Contrôles techniques de sécurité

    6.1.Génération et installation des paires de clés

    6.1.1.TLM, CA racine, EA et AA

    (304)Le processus de génération des paires de clés satisfait aux exigences suivantes:

    ·chaque participant est en mesure de générer ses propres paires de clés conformément aux sections 6.1.4 et 6.1.5;

    ·le processus de dérivation des clés de chiffrement symétriques et d’une clé MAC pour les demandes de certificat (ECIES) se déroule conformément à [1] et [5];

    ·le processus de génération des clés utilise les algorithmes et les longueurs de clés décrits dans les sections 6.1.4.1 et 6.1.4.2;

    ·le processus de génération des paires de clés est soumis aux exigences du «stockage sécurisé des clés privées» (voir section 6.1.5);

    ·les CA racine et leurs souscripteurs (sous-CA) veillent à ce que l’intégrité et l’authenticité de leurs clés publiques et de tout paramètre associé soient préservées durant la distribution aux entités enregistrées des sous-CA.

    6.1.2.EE — station STI-C mobile

    (305)Chaque station STI-C mobile génère ses propres paires de clés conformément aux sections 6.1.4 et 6.1.5.

    (306)Le processus de dérivation des clés de chiffrement symétriques et d’une clé MAC pour les demandes de certificat (ECIES) se déroule conformément à [1] et [5].

    (307)Les processus de génération des clés utilisent les algorithmes et les longueurs de clés décrits dans les sections 6.1.4.1 et 6.1.4.2.

    (308)Les processus de génération des paires de clés sont soumis aux exigences du «stockage sécurisé des clés privées» (voir section 6.1.5).

    6.1.3.EE — station STI-C fixe

    (309)Chaque station STI-C fixe génère sa propre paire de clés conformément aux sections 6.1.4 et 6.1.5.

    (310)Les processus de génération des clés utilisent les algorithmes et les longueurs de clés décrits dans les sections 6.1.4.1 et 6.1.4.2.

    (311)Les processus de génération des paires de clés sont soumis aux exigences du «stockage sécurisé des clés privées» (voir section 6.1.5).

    6.1.4.Exigences cryptographiques

    (312)Tous les participants à la PKI satisfont aux exigences cryptographiques énoncées dans les paragraphes suivants en ce qui concerne l’algorithme de signature, la longueur des clés, le générateur de nombre aléatoire et les certificats de lien.

    6.1.4.1.Algorithme et longueur de la clé - algorithmes de signature

    (313)Tous les participants à la PKI (TLM, CA racine, EA, AA et stations STI-C) sont en mesure de générer des paires de clés et d’utiliser la clé privée pour la signature des opérations avec des algorithmes sélectionnés au plus tard deux ans après l’entrée en vigueur du présent règlement, conformément au tableau 4.

    (314)Tous les participants à la PKI qui doivent vérifier l’intégrité de l’ECTL, des certificats et/ou des messages signés conformément à leur rôle, tel que défini à la section 1.3.6, prennent en charge les algorithmes correspondants énumérés au tableau 5 pour vérification. En particulier, les stations STI-C sont capables de vérifier l’intégrité de l’ECTL.

    TLM

    CA racine

    EA

    AA

    Station STI-C

    ECDSA_nistP256_with_SHA 256

    -

    X

    X

    X

    X

    ECDSA_brainpoolP256r1_with_SHA 256

    -

    X

    X

    X

    X

    ECDSA_brainpoolP384r1_with_SHA 384

    X

    X

    X

    -

    -

    X indique une prise en charge obligatoire

    Tableau 4: Génération de paires de clés et utilisation d’une clé privée pour la signature des opérations



    TLM

    CA racine

    EA

    AA

    Station STI-C

    ECDSA_nistP256_with_SHA 256

    X

    X

    X

    X

    X

    ECDSA_brainpoolP256r1_with_SHA 256

    X

    X

    X

    X

    X

    ECDSA_brainpoolP384r1_with_SHA 384

    X

    X

    X

    X

    X

    X indique une prise en charge obligatoire

    Tableau 5: Aperçu de la vérification

    (315)Si la CPA en décide ainsi, sur la base de nouvelles faiblesses cryptographiques détectées, toutes les stations STI-C sont en mesure de passer à l’un des deux algorithmes (ECDSA_nistP256_with_SHA 256 ou ECDSA_brainpoolP256_with_SHA 256) dès que possible. Le ou les algorithmes qui sont concrètement utilisés sont déterminés dans la CPS de la CA qui délivre le certificat pour la clé publique correspondante, conformément à la présente CP.

    6.1.4.2.Algorithme et longueur de la clé - algorithmes de chiffrement pour l’inscription et l’autorisation

    (316)Tous les participants à la PKI (EA, AA et stations STI-C) sont en mesure d’utiliser les clés publiques pour chiffrer les demandes/réponses d’inscription et d’autorisation avec des algorithmes sélectionnés au plus tard deux ans après l’entrée en vigueur du présent règlement, conformément au tableau 6. Le ou les algorithmes qui sont concrètement utilisés sont déterminés dans la CPS de la CA qui délivre le certificat pour la clé publique correspondante, conformément à la présente CP.

    (317)Les algorithmes mentionnés dans le tableau 6 indiquent la longueur de la clé et la longueur de l’algorithme de hachage et sont mis en œuvre conformément à [5].

    TLM

    CA racine

    EA

    AA

    Station STI-C

    ECIES_nistP256_with_AES 128_CCM

    -

    -

    X

    X

    X

    ECIES_brainpoolP256r1_with_AES 128_CCM

    -

    -

    X

    X

    X

    X indique une prise en charge obligatoire

    Tableau 6: Utilisation des clés publiques pour le chiffrement des questions/réponses d’inscription et d’autorisation



    (318)Tous les participants à la PKI (EA, AA et stations STI-C) sont en mesure de générer des paires de clés et d’utiliser la clé privée pour déchiffrer les demandes/réponses d’inscription et d’autorisation avec des algorithmes sélectionnés au plus tard deux ans après l’entrée en vigueur du présent règlement, conformément au tableau 7.

    TLM

    CA racine

    EA

    AA

    Station STI-C

    ECIES_nistP256_with_AES 128_CCM

    -

    -

    X

    X

    X

    ECIES_brainpoolP256r1_with_AES 128_CCM

    -

    -

    X

    X

    X

    X indique une prise en charge obligatoire

    Tableau 7: Génération de paires de clés et utilisation de clé privée pour le déchiffrement des demandes/réponses d’inscription et d’autorisation

    6.1.4.3.Crypto-agilité

    (319)Les exigences concernant les longueurs de clés et les algorithmes doivent être modifiées au fil du temps afin de maintenir un niveau de sécurité approprié. La CPA surveille la nécessité de ces modifications compte tenu des vulnérabilités réelles et des dernières avancées de la cryptographie. Elle rédigera, approuvera et publiera une mise à jour de la présente politique de certification si elle décide que les algorithmes cryptographiques doivent être mis à jour. Si une nouvelle édition de la présente CP signale un changement d’algorithme et/ou de longueur de clé, la CPA adoptera une stratégie de migration comprenant des périodes de transition au cours desquelles les anciens algorithmes et longueurs de clés doivent être pris en charge.

    (320)Afin de permettre et de faciliter le transfert vers de nouveaux algorithmes et/ou longueurs de clés, il est recommandé que tous les participants à la PKI mettent en œuvre des matériels et/ou des logiciels capables de soutenir un changement de longueurs de clés et d’algorithmes.

    (321)Les modifications des certificats racine et du TLM sont prises en charge et exécutées à l’aide de certificats de lien (voir section 4.6) qui sont utilisés pour couvrir la période de transition entre les anciens et les nouveaux certificats racine («migration du modèle de confiance»).

    6.1.5.Stockage sécurisé de clés privées

    La présente section décrit les exigences pour le stockage sécurisé et la génération de paires de clés et de nombres aléatoires pour les CA et les entités finales. Ces exigences sont définies pour les modules cryptographiques et décrites dans les sous-sections suivantes.

    6.1.5.1.Niveau CA racine, sous-CA et TLM

    (322)Un module cryptographique est utilisé pour:

    ·générer, utiliser, administrer et stocker les clés privées;

    ·générer et utiliser des nombres aléatoires (l’évaluation de la fonction de génération de nombres aléatoires fait partie de l’évaluation et de la certification de la sécurité);

    ·créer des sauvegardes des clés privées conformément à la section 6.1.6;

    ·supprimer des clés privées.

    Le module cryptographique est certifié avec l’un des profils de protection (PP) suivants, présentant un niveau d’assurance EAL-4 ou supérieur:

    ·PP pour HSM:

    ·CEN EN 419 221-2: Profils de protection pour modules cryptographiques utilisés par les prestataires de services de confiance – Partie 2: Module cryptographique utilisé par le prestataire de services de certification pour les opérations de signature avec sauvegarde;

    ·CEN EN 419 221-4: Profils de protection pour modules cryptographiques utilisés par les prestataires de services de confiance – Partie 4: Module cryptographique utilisé par le prestataire de services de certification pour les opérations de signature sans sauvegarde;

    ·CEN EN 419 221-5: Profils de protection pour les modules cryptographiques de prestataires de services de confiance – Partie 5: Module cryptographique pour les services de confiance;

    ·PP pour cartes à puces:

    ·CEN EN 419211-2: Profils de protection des dispositifs sécurisés de création de signature – Partie 2: Dispositif avec génération de clé;

    ·CEN EN 419211-3: Profils de protection des dispositifs sécurisés de création de signature – Partie 3: Dispositif avec import de clé.

    Un accès manuel au module cryptographique exige une authentification à deux facteurs de l’administrateur. En outre, cela requiert la participation de deux personnes autorisées.

    La mise en œuvre d’un module cryptographique garantit que les clés ne sont pas accessibles en dehors du module cryptographique. Le module cryptographique comporte un mécanisme de contrôle de l’accès afin de prévenir toute utilisation non autorisée des clés privées.

    6.1.5.2.Entité finale

    (323)Un module cryptographique pour EE est utilisé pour:

    ·générer, utiliser, administrer et stocker les clés privées;

    ·générer et utiliser des nombres aléatoires (l’évaluation de la fonction de génération de nombres aléatoires fait partie de l’évaluation et de la certification de la sécurité);

    ·assurer la suppression d’une clé privée.

    (324)Le module cryptographique est protégé contre un retrait, un remplacement et une modification non autorisés. Tous les PP et les documents correspondants applicables pour la certification de la sécurité du module cryptographique sont évalués, validés et certifiés conformément à la norme ISO 15408, en appliquant l’accord sur la reconnaissance mutuelle des certificats d'évaluation de la sécurité en matière de technologies de l'information («Mutual Recognition Agreement of Information Technology Security Evaluation Certificates») du groupe des hauts fonctionnaires pour la sécurité des systèmes d’information («Senior Officials Group on Information Systems Security», SOG-IS).

    (325)Étant donné l’importance que revêt le maintien du niveau de sécurité le plus élevé possible, des certificats de sécurité pour le module cryptographique sont délivrés au titre du régime de certification «critères communs» (ISO 15048) par un organisme d’évaluation de la conformité reconnu par le comité de gestion dans le cadre de l’accord du SOG-IS, ou délivrés par un organisme d'évaluation de la conformité accrédité par une autorité nationale de certification de cybersécurité d’un État membre. Cet organisme d'évaluation de la conformité offre au moins des conditions d’évaluation de la sécurité équivalentes à celles qui sont prévues par l’accord de reconnaissance mutuelle du SOG-IS.

    Note: le lien entre le module cryptographique et la station STI-C est protégé.

    6.1.6.Sauvegarde de clés privées

    (326)La génération, le stockage et l’utilisation des sauvegardes de clés privées satisfont aux exigences au moins du niveau de sécurité requis pour les clés originales.

    (327)Les sauvegardes des clés privées sont effectuées par les CA racine, les EA et les AA.

    (328)Les sauvegardes des clés privées ne sont pas effectuées pour les EC et les AT.

    6.1.7.Destruction de clés privées

    (329)Les CA racine, les EA, les AA et les stations STI-C mobiles et fixes détruisent leur clé privée et toute sauvegarde correspondante, si une nouvelle paire de clés et le certificat correspondant ont été générés et installés avec succès, et si le délai de chevauchement (le cas échéant — pour la CA uniquement) a expiré. La clé privée est détruite en utilisant le mécanisme proposé par le module cryptographique utilisé pour le stockage de clés ou comme décrit dans le PP correspondant tel que mentionné à la section 6.1.5.2.

    6.2.Données d’activation

    (330)Les données d’activation font référence aux facteurs d’authentification requis pour exploiter les modules cryptographiques afin d’empêcher tout accès non autorisé. L’utilisation des données d’activation d’un dispositif cryptographique de la CA requiert une action par deux personnes autorisées.

    6.3.Contrôles de sécurité informatique

    (331)Les contrôles de sécurité informatique des CA sont conçus conformément au niveau de sécurité élevé en se conformant aux exigences de la norme ISO/IEC 27002.

    6.4.Contrôles techniques tout au long du cycle de vie

    (332)Les contrôles techniques de la CA couvrent tout le cycle de vie de la CA. En particulier, cela inclut les exigences de la section 6.1.4.3 («Crypto-agilité»).

    6.5.Contrôles de sécurité du réseau

    (333)Les réseaux des CA (CA racine, EA et AA) sont renforcés contre les attaques conformément aux exigences et aux orientations pour la mise en œuvre de la norme ISO/IEC 27001 et de la norme ISO/IEC 27002.

    (334)La disponibilité des réseaux de la CA est conçue en fonction du trafic estimé.

    7.Profils de certificats, CRL et ECTL

    7.1.Profil de certificats

    (335)Les profils de certificats définis dans [5] sont utilisés pour les TLM, les certificats racines, les certificats de l’EA, les certificats de l'AA, les AT et les EC. Les EA publiques nationales peuvent utiliser d’autres profils de certificat pour les EC.

    (336)Les certificats de la CA racine, de l’EA et de l’AA indiquent les autorisations pour lesquelles ces CA (CA racine, EA et AA) sont autorisées à délivrer des certificats.

    (337)Sur la base de [5]:

    ·chaque CA racine utilise sa propre clé privée de signature pour émettre des CRL;

    ·le TLM utilise sa propre clé privée de signature pour émettre l’ECTL.

    7.2.Validité des certificats

    (338)Tous les profils de certificats des STI-C comprennent une date de délivrance et d’expiration, qui représentent le délai de validité du certificat. À chaque niveau de la PKI, des certificats sont générés avec une avance suffisante avant l’expiration.

    (339)Le délai de validité des certificats de la CA et de l’EC inclut un délai de chevauchement. Les certificats du TLM et de la CA racine sont délivrés et placés sur l’ECTL trois mois au maximum et un mois au moins avant le début de leur validité déterminé en fonction du moment indiqué dans le certificat. Cette phase de préchargement est requise pour distribuer les certificats en toute sécurité à toutes les parties utilisatrices correspondantes, conformément à la section 2.2. Cela garantit que, à compter du début du délai de chevauchement, toutes les parties utilisatrices sont déjà en mesure de vérifier les messages émis avec un nouveau certificat.

    (340)Au début du délai de chevauchement, les certificats successifs de la CA, de l’EC et de l’AT sont délivrés (le cas échéant), distribués et installés par les parties utilisatrices correspondantes. Pendant le délai de chevauchement, le certificat en vigueur est utilisé uniquement à des fins de vérification.

    (341)Étant donné que les périodes de validité énumérées dans le tableau 8 ne doivent pas dépasser la période de validité du certificat supérieur, les restrictions suivantes s’appliquent:

    ·maximumvalidity(Root CA) = privatekeyusage(Root CA) + maximumvalidity(EA,AA);

    ·maximumvalidity(EA) = privatekeyusage(EA) + maximumvalidity(EC);

    ·maximumvalidity(AA) = privatekeyusage(AA) + preloadingperiod(AT).

    (342)La validité des certificats de lien (racine et TML) commence avec l’utilisation de la clé privée correspondante et s’achève à la fin de la durée de validité maximale de la CA racine ou du TLM.

    (343)Le tableau 8 montre le délai de validité maximale pour les certificats des CA des STI-C (pour les périodes de validité des AT, voir section 7.2.1).

    Entité

    Période max. d’utilisation de la clé privée

    Durée de validité maximale

    CA racine

    3 ans

    8 ans

    EA

    2 ans

    5 ans

    AA

    4 ans

    5 ans

    EC

    3 ans

    3 ans

    TLM

    3 ans

    4 ans

    Tableau 8: Périodes de validité des certificats dans le modèle de confiance des STI-C

    7.2.1.Certificats de pseudonymes

    (344)Dans ce contexte, des pseudonymes sont mis en œuvre par les AT. En conséquence, la présente section fait référence aux AT plutôt qu’aux pseudonymes.

    (345)Les exigences énoncées dans la présente section s’appliquent uniquement aux AT des stations STI-C mobiles qui envoient des messages CAM et DENM, lorsque le risque lié à la confidentialité de la localisation est présent. Aucune exigence spécifique concernant les certificats AT ne s’applique aux AT pour les stations STI-C fixes et mobiles utilisées pour assurer des fonctions spéciales lorsque la confidentialité de la localisation n’est pas applicable (par exemple, les véhicules d’urgence et les véhicules des forces de l’ordre identifiés).

    (346)On entend par:

    ·«période de validité pour les AT», la période pendant laquelle un AT est valide, à savoir la période entre sa date d’entrée en vigueur et sa date d’expiration;

    ·«période de préchargement pour les AT», la période pendant laquelle les stations STI-C ont la possibilité d’obtenir des AT avant le début de la période de validité (préchargement). La période de préchargement est le délai maximal autorisé entre la demande d’AT à la date ultime de validité de tout AT demandé;

    ·«période d’utilisation pour les AT», la période durant laquelle un AT est effectivement utilisé pour signer les messages CAM/DENM;

    ·«nombre maximal d’AT parallèles», le nombre d’AT parmi lesquels une station STI-C peut choisir, à tout moment donné, lors de la signature d’un message CAM/DENM, c’est-à-dire le nombre d’AT différents délivrés à une station STI-C qui sont valides en même temps.

    (347)Les exigences suivantes s’appliquent:

    ·la période de préchargement pour les AT n’excède pas trois mois;

    ·la période de validité pour les AT ne dépasse pas une semaine;

    ·le nombre maximal d’AT parallèles ne dépasse pas 100 par station STI-C;

    ·la période d’utilisation d’un AT dépend de la stratégie de changement des AT et du laps de temps durant lequel un véhicule est en intervention, mais elle est limitée par le nombre maximal d’AT parallèles et par la période de validité. Plus précisément, la période d’utilisation moyenne pour une station STI-C est au moins égale à la durée de service du véhicule pendant une période de validité divisée par le nombre maximal d’AT parallèles.

    7.2.2.Tickets d’autorisation pour les stations STI-C fixes

    (348)Les définitions de la section 7.2.1 et les exigences suivantes s’appliquent:

    ·la période de préchargement pour les AT n’excède pas trois mois;

    ·le nombre maximal d’AT parallèles ne dépasse pas deux par station STI-C.

    7.3.Révocation de certificats

    7.3.1.Révocation de certificats de la CA, l’EA et l’AA

    Les certificats de la CA racine, de l’EA et de l’AA sont révocables. Les certificats révoqués des CA racine, des EA et des AA sont publiés sur une CRL dès que possible et sans retard indu. Cette CRL est signée par son CA racine correspondante et utilise le profil décrit à la section 7.4. Pour la révocation des certificats de la CA racine, la CA racine correspondante émet une CRL sur laquelle elle figure. En outre, en cas de compromission de la sécurité, la section 5.7.3 s’applique. En outre, le TLM retire les CA racine révoquées de la liste de confiance et émet une nouvelle liste de confiance. Les certificats périmés sont retirés de la CRL correspondante et de la liste de confiance.

    (349)Les certificats sont révoqués lorsque:

    ·les CA racine ont des raisons de croire ou de soupçonner fortement que la clé privée correspondante a été compromise;

    ·les CA racine ont été informées que le contrat conclu avec le souscripteur a été résilié;

    ·les informations (telles que le nom et les associations entre la CA et le sujet) dans le certificat sont inexactes ou ont changé;

    ·un incident de sécurité a lieu, qui affecte le titulaire du certificat;

    ·un audit (voir section 8) conduit à un résultat négatif.

    (350)Le souscripteur informe immédiatement la CA d’une compromission connue ou suspectée de sa clé privée. Il convient de s’assurer que seules les demandes authentifiées donnent lieu à des certificats révoqués.

    7.3.2.Révocation de certificats d’inscription

    (351)La révocation des EC peut être initiée par le souscripteur de la station STI-C (flux 34) et est mise en œuvre moyennant une liste noire interne portant un horodatage, qui est générée et maintenue par chaque EA dans une base de données des révocations. La liste noire n’est jamais publiée, est tenue confidentielle et est seulement utilisée par l’EA correspondante afin de vérifier la validité des EC correspondants dans le cadre des demandes d'AT et de nouveaux EC.

    7.3.3.Révocation de tickets d’autorisation

    (352)Comme les AT ne sont pas révoqués par les CA correspondantes, ils ont une durée de vie courte et ne peuvent pas être délivrés trop longtemps avant de devenir valides. Les valeurs des paramètres du cycle de vie des certificats admissibles sont énoncées à la section 7.2.

    7.4.Liste de révocation de certificats

    (353)Le format et le contenu de la CRL émise par des CA racine sont indiqués dans [1].

    7.5.Liste de confiance européenne des certificats

    (354)Le format et le contenu de l’ECTL émise par le TLM sont indiqués dans [1].

    8.Vérification de la conformité et autres évaluations

    8.1.Sujets faisant l’objet d’audits et fondement des audits

    (355)Un audit de conformité a pour objectif de vérifier que le TML, les CA racine, les EA et les AA fonctionnent conformément à la présente CP. Le TLM, les CA racine, les EA et les AA sélectionnent un auditeur agréé de la PKI et agissant indépendamment pour évaluer leur CPS. L’audit est combiné avec une évaluation au titre des normes ISO/IEC 27001 et ISO/IEC 27002.

    (356)Un audit de conformité est ordonné, pour une CA racine, par la CA racine elle-même (flux 13) et, pour une sous-CA, par son EA/AA subordonnée.

    (357)Un audit de conformité pour le TLM est ordonné par la CPA (flux 38).

    (358)Lorsqu’il est demandé, un audit de conformité est effectué par un auditeur agréé de la PKI sur l’un des niveaux suivants:

    (1)conformité des CPS du TLM, de la CA racine, de l’EA ou de l’AA à la présente CP;

    (2)conformité des pratiques visées du TLM, de la CA racine, de l’EA ou de l’AA à leur CPS avant l’exploitation;

    (3)conformité des pratiques et activités opérationnelles du TLM, de la CA racine, de l’EA ou de l’AA à leur CPS pendant l’exploitation.

    (359)L’audit couvre toutes les exigences de la présente CP à respecter par le TLM, les CA racine, les EA et les AA devant faire l'objet de l’audit. Il porte également sur le fonctionnement de la CA dans la PKI des STI-C, y compris sur tous les processus mentionnés dans sa CPS, les locaux et les personnes responsables.

    (360)L’auditeur agréé de la PKI fournit un rapport détaillé de l’audit à la CA racine (flux 36), à l’EA, à l’AA ou à la CPA (flux 16 et 40), le cas échéant.

    8.2.Fréquence des audits

    (361)Une CA racine, un TLM, une EA ou AA commande un audit de conformité pour elle/lui-même auprès d’un auditeur de la PKI indépendant et agréé dans les cas suivants:

    ·lors de sa première mise en place (conformité de niveaux 1 et 2);

    ·lors de toute modification de la CP. La CPA définit le contenu du changement de la CP et le calendrier du déploiement et détermine les besoins d’audit (y compris le niveau de conformité nécessaire) en conséquence;

    ·lors de toute modification de sa CPS (conformité de niveaux 1, 2 et 3). Étant donné que les entités de gestion des CA racine, du TLM et des EA/AA décident des modifications de la mise en œuvre qui suivent la mise à jour de leur CPS, elles commandent un audit de conformité avant de mettre en œuvre ces modifications. En cas de modifications mineures de la CPS (par exemple de nature rédactionnelle), l’entité de gestion peut envoyer à la CPA une demande dûment justifiée pour qu’elle l’autorise à ne pas effectuer les audits de conformité de niveau 1, 2 ou 3;

    ·régulièrement, et au moins tous les trois ans, durant son exploitation (conformité de niveau 3).

    8.3.Identité/qualifications de l’auditeur

    (362)La CA devant faire l'objet d'un audit sélectionne une entreprise/organisation («organe d’audit») agissant de manière indépendante et accréditée ou des auditeurs agréés de la PKI qui procéderont à son audit conformément à la présente CP. L’organe d’audit est agréé et certifié par un membre de l’organisme européen d’accréditation 1 .

    8.4.Lien entre l’auditeur et l’entité soumise à audit

    (363)L’auditeur agréé de la PKI est indépendant de l’entité soumise à audit.

    8.5.Mesures prises à la suite du constat de lacunes

    (364)Lorsqu’un rapport d’audit conclut à la non-conformité du TLM, la CPA ordonne au TLM de prendre des mesures préventives/correctives immédiates.

    (365)Lorsqu’une CA racine faisant l’objet d’un rapport d’audit non conforme introduit une nouvelle demande, la CPA rejette la demande et transmet un rejet correspondant à la CA racine (flux 4). En pareils cas, la CA racine sera suspendue. Elle doit prendre des mesures correctives, commander à nouveau un audit et faire une nouvelle demande d’approbation de la CPA. La CA racine n’est pas autorisée à délivrer des certificats pendant la période de suspension.

    (366)En cas d’audit régulier de la CA racine ou de modification à la CPS de la CA racine, et en fonction de la nature de la non-conformité décrite dans le rapport d’audit, la CPA peut décider de révoquer la CA racine et de communiquer cette décision au TLM (flux 2), entraînant la suppression du certificat de la CA racine de l’ECTL et l’insertion de la CA racine sur la CRL. La CPA transmet un rejet correspondant à la CA racine (flux 4). La CA racine doit prendre des mesures correctives, commander à nouveau un audit complet (niveaux 1 à 3) et introduire une nouvelle demande d’approbation de la CPA. Il se peut aussi que la CPA décide de ne pas révoquer la CA racine, mais de lui accorder un délai de grâce au cours duquel la CA racine prend des mesures correctives, commande à nouveau un audit et soumet à nouveau le rapport d’audit à la CPA. Le cas échéant, le fonctionnement de la CA racine doit être suspendu et elle n’est pas autorisée à délivrer des certificats et des CRL.

    (367)Dans le cas de l’audit d’une EA/AA, la CA racine décide d’accepter ou non le rapport. En fonction du résultat de l’audit, la CA racine décide s’il y a lieu de révoquer ou non le certificat d’EA/AA conformément aux règles de la CPS de la CA racine. La CA racine garantit à tout moment la conformité de l’EA/AA à la présente CP.

    8.6.Communication des résultats

    (368)La CA racine et le TLM transmettent le rapport d’audit à la CPA (flux 16). La CA racine et le TLM conservent tous les rapports d’audit qu’ils ont commandés. La CPA envoie une approbation ou un rejet correspondant (flux 4) à la CA racine et au TLM.

    (369)La CA racine envoie un certificat de conformité à l’EA/AA correspondante.

    9.Autres dispositions

    9.1.Redevances

    (370)L’un des principes du modèle de confiance des STI-C mis en œuvre est que les CA racine, conjointement, financent intégralement les coûts de fonctionnement périodiques et récurrents de la CPA et des éléments centraux (TLM et CPOC) relatifs aux activités exposées dans la présente CP.

    (371)Les CA racine (y compris la CA racine de l’UE) sont habilitées à percevoir des redevances auprès de leurs sous-CA.

    (372)Tout au long de leur période d’exploitation, chaque participant du modèle de confiance des STI-C a accès à au moins une AC racine, EA et AA sur une base non discriminatoire.

    (373)Chaque CA racine est autorisée à répercuter les redevances qu’elle paie pour la CPA et les éléments centraux (TLM et CPOC) sur les participants enregistrés du modèle de confiance des STI-C, y compris les stations STI-C inscrites et autorisées.

    9.2.Responsabilité financière

    (374)L’établissement initial d’une CA racine couvre une période d’au moins trois années d’exploitation, afin qu’elle puisse devenir membre du modèle de confiance des STI-C de l’UE. La CPS de l’exploitant d’une CA racine contient également des dispositions détaillées relatives à la révocation ou à la fermeture de la CA racine.

    (375)Chaque CA racine doit démontrer la viabilité financière de l’entité juridique qui la met en œuvre pendant au moins trois ans. Ce plan de viabilité financière fait partie de la série initiale de documents nécessaires à l’inscription et doit être mis à jour tous les trois ans et communiqué à la CPA.

    (376)Chaque CA racine doit signaler la structure des redevances appliquées aux EA/AA et aux stations STI-C inscrites et autorisées chaque année au gestionnaire des opérations et à la CPA afin de démontrer sa viabilité financière.

    (377)Toutes les entités financières et juridiques responsables de la CA racine, de l’EA, de l’AA et des éléments centraux (CPOC et TLM) du modèle de confiance des STI-C doivent couvrir leurs tâches opérationnelles par des niveaux d’assurance adéquats permettant de compenser les erreurs opérationnelles et le coût financier du rétablissement de leurs fonctions en cas de défaillance de l’un des éléments techniques.

    9.3.Confidentialité des informations opérationnelles

    (378)Les éléments suivants sont tenus confidentiels et privés:

    ·enregistrements des demandes de la CA racine, de l’EA, de l’AA, approuvées ou rejetées;

    ·rapports d’audit de la CA racine, de l’EA, de l’AA et du TLM;

    ·plans de rétablissement après sinistre de la CA racine, de l'EA, de l'AA, du CPOC et du TLM;

    ·clés privées des éléments du modèle de confiance des STI-C (stations STI-C, TLM, EA, AA, CA racine);

    ·toute autre information considérée comme confidentielle par la CPA, les CA racine, l’EA, l’AA, le TLM et le CPOC.

    9.4.Plan en matière de protection de la vie privée

    (379)Les CPS des CA racine et les EA/AA établissent le plan et les exigences pour le traitement des données à caractère personnel et la protection de la vie privée sur la base du RGPD et d’autres cadres législatifs (par exemple nationaux) applicables.

    10.Références

    La présente annexe fait référence aux documents suivants:

    [1]

    ETSI TS 102 941 V1.2.1, «Systèmes de transport intelligents (STI) – sécurité, confiance et gestion de la vie privée» [Intelligent transport systems (ITS) – security, trust and privacy management].

    [2]

    ETSI TS 102 940 V1.3.1, «Systèmes de transport intelligents (STI) – sécurité, architecture de sécurité pour les communications STI et gestion de la sécurité» [Intelligent transport systems (ITS) – security, ITS communications security architecture and security management].

    [3]

    «Politique de certification et cadre de pratiques de certifications» [Certificate policy and certification practices framework] (RFC 3647, 1999).

    [4]

    ETSI TS 102 042 V2.4.1, «Exigences politiques pour les autorités de certification délivrant des certificats à clés publiques» [Policy requirements for certification authorities issuing public key certificates].

    [5]

    ETSI TS 103 097 V1.3.1, «Systèmes de transport intelligents (STI) – sécurité, en-tête de sécurité et formats des certificats» [Intelligent transport systems (ITS) – security, security header and certificate formats].

    [6]

    Calder A., Information security based on ISO 27001/ISO 1779: a management guide, Van Haren Publishing, 2006.

    [7]

    ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011) – Technologies de l’information – Techniques de sécurité – Gestion des risques liés à la sécurité de l’information. ISO.

    (1)    La liste des membres de l’organisme européen d’accréditation figure sur cette page:    
    http://www.european-accreditation.org/ea-members
    Top

    TABLE DES MATIÈRES

    1.Politique de sécurité en matière de STI-C2

    1.1.Définitions et acronymes2

    1.2.Définitions2

    1.3.Stratégie de sécurité de l’information3

    1.3.1.Système de management de la sécurité de l’information (ISMS)3

    1.4.Classification de l’information4

    1.5.Évaluation des risques6

    1.5.1.Généralités6

    1.5.2.Critères de risque en matière de sécurité7

    1.5.2.1.Identification des risques7

    1.5.2.2.Analyse des risques7

    1.5.2.3.Évaluation des risques8

    1.6.Traitement des risques8

    1.6.1.Généralités8

    1.6.2.Contrôles pour les stations STI-C9

    1.6.2.1.Contrôles génériques9

    1.6.2.2.Contrôles pour la communication entre différentes stations STI-C9

    1.6.2.3.Contrôles pour les stations STI-C en tant qu’entité finale11

    1.6.3.Contrôles pour les participants au CCMS de l’UE11

    1.7.Respect de cette politique de sécurité11

    2.Références12

    ANNEXEE IV

    1.Politique de sécurité en matière de STI-C

    1.1.Définitions et acronymes

    CCMS de l’UE

    Système de l’UE pour la gestion des authentifiants de sécurité des services STI-C

    CAM

    Message de sensibilisation coopérative («cooperative awareness message»)

    CP

    Politique de certification («certificate policy»)

    DENM

    Message de notification environnementale décentralisée («decentralized environmental notification message»)

    ISMS

    Système de management la sécurité de l’information («information security management system»)

    IVIM

    Message d’information infrastructure à véhicule («infrastructure-to-vehicle information message»)

    SPATEM

    Message étendu concernant les phases et le minutage de signalisation («signal phase and timing extended message»)

    SREM

    Message étendu de demande d’allumage de signal («signal request extended message»)

    SSEM

    Message étendu de demande d’état d’allumage de signal («signal request status extended message»)

    1.2.Définitions

    Disponibilité

    Fait d’être accessible et utilisable, à la demande d’une entité autorisée (ISO 27000) [2]

    Infrastructure STI-C

    Système d’installations, d’équipement et d’applications nécessaires au fonctionnement d’une organisation fournissant des services STI-C liés à des stations STI-C fixes

    Parties prenantes des STI-C

    Personne, groupe ou organisation jouant un rôle et assumant des responsabilités en ce qui concerne le réseau STI-C

    Informations confidentielles

    Informations ne devant pas être rendues disponibles ni divulguées à des personnes, des entités ou des processus non autorisés (ISO 27000) [2]

    Sécurité de l’information

    Préservation de la confidentialité, de l’intégrité et de la disponibilité de l’information (ISO 27000) [2]

    Incident lié à la sécurité de l’information

    Un ou plusieurs événements liés à la sécurité de l’information, indésirables ou inattendus, présentant une probabilité forte de compromettre les opérations liées à l’activité de l’organisme et de menacer la sécurité de l’information

    Intégrité

    Caractère exact et complet (ISO 27000) [2]

    Carte dynamique locale (LDM)

    Répertoire de données relatives aux conditions de conduite locales, mis à jour de manière dynamique, d’une station STI-C de véhicule; comprend des informations reçues des capteurs embarqués et des messages CAM et DENM (ETSI TR 102 893) [5]

    Contrôle de protocole

    Les ressources de contrôle de protocole sélectionnent un protocole de transfert de messages approprié pour une demande de message sortant et envoient le message aux couches inférieures de la pile de protocoles dans un format pouvant être traité par ces couches. Les messages entrants sont convertis dans un format pouvant être traité au sein de la station STI-C et transmis à la ressource fonctionnelle pertinente en vue d’un traitement ultérieur (ETSI TR 102 893) [5].

    1.3.Stratégie de sécurité de l’information

    1.3.1.Système de management de la sécurité de l’information (ISMS)

    (1)Chaque exploitant de station STI-C exploite un ISMS conformément à la norme ISO/IEC 27001 et en respectant les contraintes et les exigences supplémentaires établies dans la présente section.

    (2)Chaque exploitant de station STI-C détermine des questions externes et internes pertinentes en matière de STI-C, notamment:

    ·COM(2016) 766 final [10];

    ·le RGPD [6].

    (3)Chaque exploitant de station STI-C détermine les parties pertinentes pour l'ISMS et leurs exigences, y compris toutes les parties prenantes des STI-C.

    (4)La portée de l'ISMS englobe toutes les stations STI-C exploitées et tous les autres systèmes de traitement de l’information qui traitent des données STI-C sous la forme de messages STI-C conformes aux normes suivantes:

    ·CAM [7]

    ·DENM [8]

    ·IVIM [9]

    ·SPATEM [9]

    ·MAPEM [9]

    ·SSEM [9]

    ·SREM [9]

    (5)Chaque exploitant de station STI-C veille à ce que sa politique de sécurité de l’information soit conforme à cette politique.

    (6)Chaque exploitant de station STI-C s’assure que ses objectifs en matière de sécurité de l’information comprennent les objectifs de sécurité et les exigences de haut niveau de cette politique et soient conformes à ceux-ci.

    (7)Les exploitants de stations STI-C classifient les informations visées à la section 1.4.

    (8)Les exploitants de stations STI-C appliquent un processus d’évaluation des risques de sécurité de l’information conformément aux dispositions de la section 1.5 à des intervalles prévus ou lorsque des changements significatifs sont proposés ou surviennent.

    (9)Les exploitants de stations STI-C et/ou les fabricants de stations STI-C déterminent les exigences en matière d’atténuation des risques de sécurité recensés dans le cadre du processus d’évaluation des risques de sécurité de l’information, conformément à la section 1.6.

    (10)Les fabricants de stations STI-C conçoivent, développent et évaluent les stations STI-C et d’autres systèmes de traitement de l’information de manière à garantir que ceux-ci satisfont aux exigences applicables.

    (11)Les exploitants de stations STI-C exploitent ces stations et tous les autres systèmes de traitement de l’information qui mettent en œuvre des contrôles du traitement des risques de sécurité de l’information de manière appropriée et conformément à la section 1.6.

    1.4.Classification de l’information

    La présente section établit les exigences minimales en matière de classification de l’information. Elle n’empêche aucune partie prenante des STI-C d’appliquer des exigences plus strictes.

    (12)Les exploitants de stations STI-C classifient les informations traitées, une catégorie de sécurité de l'information pouvant être représentée de la manière suivante:

    catégorie de sécurité pour les informations = {(confidentialité, impact), (intégrité, impact), (disponibilité, impact)};

    (13)Les parties prenantes des STI-C classifient les informations gérées, une catégorie de sécurité du système d’information pouvant être représentée de la manière suivante:

    catégorie de sécurité pour les systèmes d’information = {(confidentialité, impact), (intégrité, impact), (disponibilité, impact)};

    (14)Les valeurs acceptables de l’impact potentiel sont «faible», «modéré» et «élevé», comme résumé dans le tableau 1.

    Tableau 1 - Définitions de l’impact potentiel pour chaque objectif de sécurité (confidentialité, intégrité et disponibilité)

    Impact potentiel

    Objectif de sécurité

    FAIBLE

    MODÉRÉ

    ÉLEVÉ

    Confidentialité

    Préserver les restrictions autorisées en matière d’accès à l’information et de divulgation de cette même information, y compris les moyens de protéger la vie privée et les informations confidentielles

    La divulgation non autorisée d’informations pourrait avoir un effet néfaste limité sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    La divulgation non autorisée d’informations pourrait avoir un effet néfaste sérieux sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    La divulgation non autorisée d’informations pourrait avoir un effet néfaste grave voire catastrophique sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    Intégrité

    Protéger contre la modification abusive ou la destruction d’informations; il s’agit notamment de veiller à la non-répudiation et à l’authenticité de l’information

    La modification ou la destruction non autorisées d’informations pourrait avoir un effet néfaste limité sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    La modification ou la destruction non autorisées d’informations pourrait avoir un effet néfaste sérieux sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    La modification ou la destruction non autorisées d’informations pourrait avoir un effet néfaste grave voire catastrophique sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    Disponibilité

    Garantir un accès rapide et fiable à l’information ainsi que son utilisation rapide et fiable

    La perturbation de l’accès à l’information, ou de l’utilisation de l’information ou d’un système d’information, pourrait avoir un effet néfaste limité sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    La perturbation de l’accès à l’information, ou de l’utilisation de l’information ou d’un système d’information, pourrait avoir un effet néfaste sérieux sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    La perturbation de l’accès à l’information, ou de l’utilisation de l’information ou d’un système d’information, pourrait avoir un effet néfaste grave voire catastrophique sur les opérations organisationnelles, les ressources organisationnelles ou les personnes.

    (15)Les types d’impacts suivants liés à la classification de l’information sont pris en compte en ce qui concerne l’ampleur des dommages ou des coûts engendrés par un incident lié à la sécurité de l’information pour le service STI-C et les parties prenantes des STI-C:

    ·sécurité routière — lorsque l’impact expose les usagers de la route à un risque imminent de blessure;

    ·sécurité — lorsque l’impact expose l’une des parties prenantes des STI-C à un risque imminent de blessure;

    ·impacts opérationnels — lorsque l’impact est substantiellement négatif pour l’efficacité du trafic routier, ou autre impact sociétal tel que l’empreinte environnementale et la criminalité organisée;

    ·caractère juridique — lorsque l’impact se traduit par des mesures de conformité juridiques et/ou réglementaires significatives à l’encontre d’une ou de plusieurs des parties prenantes des STI-C;

    ·caractère financier — lorsque l’impact se traduit par des coûts monétaires directs ou indirects pour une ou plusieurs parties prenantes des STI-C;

    ·vie privée — le RGPD ayant un impact à la fois juridique et financier;

    ·réputation — lorsque l’impact se traduit par une atteinte à la réputation d’une ou plusieurs parties prenantes des STI-C et/ou du réseau STI-C, par exemple par une couverture médiatique défavorable et/ou une pression politique majeure à l’échelle nationale ou internationale.

    (16)Les parties prenantes des STI-C respectent les valeurs d’impact minimales suivantes pour les informations traitées:

    Tableau 2: Impacts

    Informations émanant de
    stations STI-C fixes

    Informations émanant de
    stations STI-C mobiles

    Confidentialité

    CAM: faibles

    DENM: faibles

    IVIM: faibles

    MAPEM: faibles

    SPATEM: faibles

    SSEM: faibles

    CAM: faibles

    DENM: faibles

    SREM: faibles

    données à caractère personnel contenues dans l’un des trois messages: modérés

    Intégrité

    CAM: modérés

    DENM: modérés

    IVIM: modérés

    MAPEM: modérés

    SPATEM: modérés

    SSEM: modérés

    CAM: modérés

    DENM: modérés

    SREM: modérés

    Disponibilité

    CAM: faibles

    DENM: faibles

    IVIM: faibles

    MAPEM: faibles

    SPATEM: faibles

    SSEM: modérés

    CAM: faibles

    DENM: faibles

    SREM: modérés

    1.5.Évaluation des risques

    1.5.1.Généralités

    (17)L’évaluation des risques est réalisée périodiquement conformément à la norme ISO/IEC 27005. Elle comprend une documentation appropriée concernant:

    ·la portée de l’évaluation des risques, c’est-à-dire le système évalué, ses limites et la finalité du système, ainsi que l’information traitée;

    ·les critères de risque en matière de sécurité;

    ·l’évaluation des risques, y compris l’identification, l’analyse et l’évaluation.

    1.5.2.Critères de risque en matière de sécurité

    (18)Les critères d’évaluation des risques sont déterminés en tenant compte des aspects suivants:

    ·la valeur stratégique du service STI-C et du réseau STI-C pour toutes les parties prenantes des STI-C;

    ·la valeur stratégique du service STI-C et du réseau STI-C pour l’exploitant de la station STI-C du service;

    ·les conséquences sur la réputation du réseau STI-C;

    ·les exigences juridiques et réglementaires et les obligations contractuelles.

    (19)Les critères d'impact des risques sont déterminés au regard des types d’impacts liés à la classification de l’information visés à la section 1.4.

    (20)Les critères d’acceptation des risques comprennent l’identification des niveaux de risque inacceptables pour le service STI-C et les parties prenantes des STI-C, par type d’impact.

    1.5.2.1.Identification des risques

    (21)Les risques sont identifiés conformément à la norme ISO/IEC 27005. Les exigences minimales suivantes s’appliquent:

    ·les principales ressources à protéger sont les messages STI-C visés à la section 1.3.1;

    ·les ressources d’appui devraient être identifiées, dont:

    ·les informations utilisées pour les messages STI-C (par exemple, carte dynamique locale, heure, contrôle de protocole, etc.);

    ·les stations STI-C et leur logiciel, leurs données de configurations et les canaux de communication associés;

    ·les ressources de contrôle des STI-C centrales,

    ·toutes les entités au sein du CCMS de l’UE,

    ·les menaces qui pèsent sur ces ressources, ainsi que leur source, sont identifiées;

    ·les contrôles existants et planifiés sont identifiés;

    ·les vulnérabilités qui peuvent être exploitées par des menaces visant à porter atteinte aux ressources ou aux parties prenantes des STI-C sont identifiées et décrites sous la forme de scénarios d’incidents;

    ·les conséquences éventuelles des incidents liés à la sécurité sur les ressources sont identifiées sur la base de la classification de l’information.

    1.5.2.2.Analyse des risques

    (22)Les exigences minimales suivantes s’appliquent à l’analyse des risques:

    ·l’impact des incidents liés à la sécurité de l’information identifiés, sur le service STI-C et sur les parties prenantes des STI-C, est évalué sur la base de la catégorie de sécurité de l’information et de la catégorie de sécurité du système d’information, en utilisant, au moins, les trois niveaux établis à la section 1.4;

    ·les niveaux d’impact sont identifiés pour:

    ·l’ensemble du réseau STI-C / des services STI-C existants; et

    ·une entité organisationnelle/partie prenante des STI-C individuelle;

    ·le niveau le plus élevé est considéré comme l’impact total;

    ·la probabilité des scénarios d’incidents identifiés est évaluée en utilisant, au moins, les trois niveaux suivants:

    ·peu probable (valeur 1) – la réalisation du scénario d’incident est peu probable/difficile ou la motivation est très faible pour un attaquant potentiel;

    ·possible (valeur 2) – le scénario d’incident est susceptible de se produire/possible ou la motivation d’un attaquant est raisonnable;

    ·probable (valeur 3) – le scénario d’incident est susceptible de se produire/facile à réaliser et la motivation d’un attaquant potentiel est élevée;

    ·les niveaux de risque sont déterminés pour tous les scénarios d’incidents identifiés sur la base du produit de l’impact et de la probabilité, ce qui se traduit, au moins, par les niveaux de risque suivants: faible (valeurs 1 et 2), modéré (valeurs 3 et 4) et élevé (valeurs 6 et 9), lesquels sont définis comme suit:

    Tableau 3: Niveaux de risque

    Niveaux de risque en tant que produit de l’impact et de la probabilité

    Probabilité

    Peu probable (1)

    Possible (2)

    Probable (3)

    Impact

    Faible (1)

    Faible (1)

    Faible (2)

    Modéré (3)

    Modéré (2)

    Faible (2)

    Modéré (4)

    Élevé (6)

    Élevé (3)

    Modéré (3)

    Élevé (6)

    Élevé (9)

    1.5.2.3.Évaluation des risques

    (23)Les niveaux de risque sont comparés aux critères d’évaluation des risques et aux critères d’acceptation des risques afin de déterminer les risques à traiter. Les risques modérés ou élevés applicables au service STI-C et au réseau STI-C, au moins, sont traités conformément à la section 1.6.

    1.6.Traitement des risques

    1.6.1.Généralités

    (24)Les risques sont traités de l’une des manières suivantes:

    ·modification du risque au moyen des contrôles identifiés aux sections  1.6.2 ou 1.6.3, de sorte que le risque résiduel puisse être réévalué comme étant acceptable;

    ·rétention du risque (lorsque le niveau de risque répond aux critères d’acceptation des risques);

    ·évitement du risque.

    (25)Le partage de risques ou le transfert de risques n’est pas autorisé pour les risques encourus par le réseau STI-C.

    (26)Le traitement des risques est documenté, comportant notamment:

    ·la déclaration d’applicabilité conformément à la norme ISO 27001, qui définit les contrôles nécessaires et détermine:

    ·la probabilité résiduelle de survenance;

    ·la gravité résiduelle de l’impact;

    ·le niveau de risque résiduel;

    ·les motifs de la rétention du risque ou de l’évitement du risque.

    1.6.2.Contrôles pour les stations STI-C

    1.6.2.1.Contrôles génériques

    (27)Les stations STI-C mettent en œuvre des contre-mesures appropriées pour modifier les risques, conformément à la section 1.6.1. Ces contre-mesures mettent en œuvre des contrôles génériques tels que définis dans les normes ISO/IEC 27001 et ISO/IEC 27002.

    1.6.2.2.Contrôles pour la communication entre différentes stations STI-C

    (28)Les contrôles minimaux obligatoires suivants sont mis en œuvre du côté émetteur:

    Tableau 4: Contrôles du côté émetteur

    Informations émanant de
    stations STI-C fixes

    Informations émanant de
    stations STI-C mobiles

    Confidentialité

    -

    Les données à caractère personnel contenues dans les messages doivent être sécurisées au moyen d’une procédure adéquate de changement de ticket d’autorisation (AT) afin de garantir un niveau de sécurité approprié par rapport au risque de réidentification des conducteurs sur la base de leurs données diffusées. Par conséquent, les stations STI-C changent les AT de manière adéquate lors de l’envoi de messages et ne réutilisent pas les AT après un changement, sauf si le conducteur ne se comporte pas comme un conducteur moyen 1 .

    Intégrité

    Tous les messages sont signés conformément à la norme TS 103 097 [14].

    Tous les messages sont signés conformément à la norme TS 103 097 [14].

    Disponibilité

    -

    -

    (29)Les contrôles minimaux obligatoires suivants sont mis en œuvre du côté récepteur:

    Tableau 5: Contrôles du côté récepteur

    Informations émanant de
    stations STI-C fixes

    Informations émanant de
    stations STI-C mobiles

    Confidentialité

    Les données à caractère personnel reçues devraient être conservées pendant une période la plus courte possible à des fins professionnelles, avec une conservation maximale de cinq minutes pour les éléments de données bruts et identifiables.

    Un CAM ou SRM reçu ne doit pas être transmis/diffusé.

    Un DENM reçu ne peut être transmis/diffusé que dans une zone géographique limitée.

    Intégrité

    L’intégrité de tous les messages utilisés par les applications STI doit être validée conformément à la norme TS 103 097 [14].

    L’intégrité de tous les messages utilisés par les applications STI doit être validée conformément à la norme TS 103 097 [14].

    Disponibilité

    -

    Un SRM reçu doit être traité et produire un SSM transmis à l’émetteur du SRM.

    (30)Pour satisfaire aux exigences de sécurité en matière de confidentialité, d’intégrité et de disponibilité établies dans les tableaux ci-dessus, toutes les stations STI-C [stations STI-C mobiles (dont les stations STI-C de véhicule) et les stations STI-C fixes] sont évaluées et certifiées selon les critères d’évaluation de sécurité précisés dans les «critères communs»/la norme ISO 15408 2 . En raison des différentes caractéristiques des différents types de stations STI-C et des différentes exigences en matière de confidentialité de localisation, différents profils de protection peuvent être définis.

    (31)Tous les profils de protection et les documents connexes applicables à la certification de sécurité des stations STI-C sont évalués, validés et certifiés conformément à la norme ISO 15408, en application de l’accord européen de reconnaissance mutuelle, intitulé «Mutual Recognition Agreement of Information Technology Security Evaluation Certificates», du groupe des hauts fonctionnaires pour la sécurité des systèmes d’information (SOGIS) 3 . Lors de l’élaboration de ces profils de protection, le champ d’application de la certification de sécurité de la station STI-C peut être défini par le fabricant, sous réserve de l’évaluation et de l’approbation de l'Autorité de politique de certification (CPA) et d’un organisme d’évaluation de la conformité du SOG-IS, ou au moins équivalent comme décrit au paragraphe suivant.

    (32)Compte tenu de l’importance de maintenir le niveau de sécurité le plus élevé possible, les certificats de sécurité pour les stations STI-C sont délivrés dans le cadre du système de certification des critères communs (ISO 15408) par un organisme d’évaluation de la conformité reconnu par le comité de gestion dans le cadre de l’accord SOG-IS, ou délivré par un organisme d’évaluation de la conformité accrédité par une autorité nationale de certification de cybersécurité d’un État membre. Cet organisme d’évaluation de la conformité fournit au moins des conditions équivalentes d’évaluation de la sécurité, comme le prévoit l’accord de reconnaissance mutuelle SOG-IS.

    1.6.2.3.Contrôles pour les stations STI-C en tant qu’entité finale

    (33)Les stations STI-C se conforment à la politique de certification [1] en fonction de leur rôle en tant qu’entité finale du CCMS de l’UE.

    1.6.3.Contrôles pour les participants au CCMS de l’UE

    (34)Les participants au CCMS de l’UE se conforment à la politique de certification [1] en fonction de leur rôle au sein du CCMS de l’UE.

    1.7.Respect de cette politique de sécurité

    (35)Les exploitants de stations STI-C demandent et obtiennent périodiquement la certification de conformité à cette politique selon les lignes directrices pour un audit ISO 27001 au titre de la norme [12].

    (36)L’organe d’audit est accrédité et certifié par un membre de European Accreditation. Il satisfait aux exigences de la norme [11].

    (37)Dans le but d’obtenir la certification, les exploitants de stations STI-C produisent et tiennent à jour des documents répondant aux exigences en matière d’informations documentées énoncées dans la clause 7.5 de la norme [3]. En particulier, les exploitants de stations STI-C produisent et tiennent à jour les documents suivants relatifs à l'ISMS:

    ·portée de l'ISMS (section 1.3.1 et clause 4.3 de la norme [3]);

    ·politique et objectifs en matière de sécurité de l’information (section 1.3.1 et clauses 5.2 et 6.2 de la norme [3]);

    ·détails de la méthodologie d’évaluation et de traitement des risques (section 1.5 et clause 6.1.2 de la norme [3]);

    ·rapport d’évaluation des risques (section 1.5 et clause 8.2 de la norme [3]);

    ·déclaration d’applicabilité (section 1.6 et clause 6.1.3d de la norme [3]);

    ·plan de traitement des risques (section 1.6 et clauses 6.1.3e et 8.3 de la norme [3]);

    ·documents requis pour la mise en œuvre des contrôles sélectionnés (section 1.6 et annexe A de la norme [3]).

    (38)En outre, les exploitants de stations STI-C produisent et tiennent à jour les enregistrements suivants à titre de preuve des résultats obtenus:

    ·enregistrements portant sur la formation, les compétences, l’expérience et les qualifications (norme [3], clause 7.2);

    ·résultats de la surveillance et des mesures (norme [3], clause 9.1);

    ·programme d’audit interne (norme [3], clause 9.2);

    ·résultats des audits internes (norme [3], clause 9.2);

    ·résultats de la revue de direction (norme [3], clause 9.3);

    ·résultats des actions correctives (norme [3], clause 10.1).

    2.Références

    Les références suivantes sont utilisées dans la présente annexe:

    [1]

    Annexe III du présent règlement

    [2]

    ISO/IEC 27000 (2016): «Technologies de l’information – Techniques de sécurité – Systèmes de management de la sécurité l’information – Vue d’ensemble et vocabulaire»

    [3]

    ISO/IEC 27001 (2015): «Technologies de l’information — Techniques de sécurité — Systèmes de management de la sécurité de l’information — Exigences»

    [4]

    ISO/IEC 27005 (2011): «Technologies de l’information – Techniques de sécurité – Gestion des risques liés à la sécurité de l’information»

    [5]

    ETSI TR 102 893 V1.2.1, «Intelligent transport systems (ITS) – security; threat, vulnerability and risk analysis (TVRA)»

    [6]

    Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l’égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données)

    [7]

    ETSI EN 302 637-2 V1.4.0, «Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule; Ensemble d’applications de base; Partie 2: spécification du service de base de sensibilisation coopérative»

    [8]

    ETSI EN 302 637-3 V1.3.0, «Systèmes de transport intelligents (STI) - Communications de véhicule à véhicule; Ensemble d’applications de base; Partie 3: spécifications du service de base de notification environnementale décentralisée»

    [9]

    ETSI TS 103 301 V1.2.1: «Systèmes de transport intelligents (STI) – Communications de véhicule à véhicule; Ensemble d'applications de base; Protocole de couche installations et exigences en matière de communication pour les services d’infrastructure»

    [10]

    «Une stratégie européenne relative aux systèmes de transport intelligents coopératifs, jalon d’une mobilité coopérative, connectée et automatisée» [COM(2016) 766, 30 novembre 2016]

    [11]

    ISO/IEC 27006:2015, «Technologies de l’information — Techniques de sécurité — Exigences pour les organismes procédant à l’audit et à la certification des systèmes de management de la sécurité de l’information»

    [12]

    ISO/IEC 27007:2011, «Technologies de l’information — Techniques de sécurité — Lignes directrices pour l’audit des systèmes de management de la sécurité de l’information»

    [13]

    ETSI EN 302 665 V1.1.1, «Systèmes intelligents de transport (STI); Architecture de communication»

    [14]

    ETSI TS 103 097 V1.3.1. «Systèmes de transport intelligents (STI); Sûreté; Formats du certificat et de l'en-tête de sûreté» (Security, security header and certificate formats)

    (1)    La définition du comportement de conduite moyen repose sur une analyse statistique pertinente du comportement de conduite dans l’Union européenne, par exemple sur des données du centre aérospatial allemand (DLR).
    (2)    Portail consacré aux «critères communs»: http://www.commoncriteriaportal.org/cc/
    (3)    Dans le secteur du transport routier, le SOG-IS a déjà participé à la certification de sécurité des tachygraphes intelligents, par exemple. L’accord SOG-IS est actuellement le seul système en Europe à même de soutenir l’harmonisation de la certification de sécurité des produits électroniques. À ce stade, le SOG-IS ne prend en charge que le processus des «critères communs», de sorte que les stations STI-C doivent être évaluées et certifiées conformément aux «critères communs»; voir https://www.sogis.org/
    Top

    ANNEXE V

    PARTIE A

    PROCÉDURES D’ÉVALUATION DE LA CONFORMITÉ

    Module A

    Contrôle interne de la production

    1.Le contrôle interne de la production est la procédure d’évaluation de la conformité par laquelle le fabricant remplit les obligations définies aux points 2, 3 et 4, et assure et déclare sous sa seule responsabilité que les stations STI-C concernées satisfont aux exigences du présent règlement qui leur sont applicables.

    2.Documentation technique

    Le fabricant établit la documentation technique permettant d’évaluer la conformité de la station STIC aux exigences pertinentes, et notamment une analyse et une évaluation adéquates du ou des risques. La documentation précise les exigences applicables et couvre, dans la mesure nécessaire à l’évaluation, la conception, la fabrication et le fonctionnement du produit. Selon le cas, elle contient au minimum les éléments suivants:

    une description générale de la station STI-C;

    des dessins de conception et des plans de fabrication, ainsi que des schémas des composants, des sousensembles, des circuits, etc.;

    les descriptions et explications nécessaires pour comprendre ces dessins et schémas, ainsi que le fonctionnement de la station STI-C;

    une liste de normes harmonisées et/ou d’autres spécifications techniques pertinentes dont les références ont été publiées au Journal officiel de l’Union européenne, ou de normes internationales, appliquées entièrement ou en partie, et la description des solutions adoptées pour satisfaire au présent règlement lorsque de telles normes harmonisées n’ont pas été appliquées. Lorsque des normes harmonisées ont été appliquées en partie, la documentation technique précise quelles parties ont été appliquées;

    les résultats des calculs de conception, des contrôles effectués, etc.; et

    les rapports d’essais.

    3.Fabrication

    Le fabricant prend toutes les mesures nécessaires pour faire en sorte que le procédé de fabrication et le suivi de celui-ci garantissent la conformité des stations STI-C à la documentation technique visée au point 2 et aux exigences des instruments législatifs qui leur sont applicables.

    4.Marquage de conformité et déclaration de conformité

    4.1.Le fabricant appose le marquage de conformité requis par le présent règlement sur chaque station STI-C qui satisfait aux exigences applicables du présent règlement.

    4.2.Le fabricant établit une déclaration écrite de conformité concernant un modèle de produit et la tient, accompagnée de la documentation technique, à la disposition des autorités nationales pendant une durée de dix ans à partir de la fabrication du produit. La déclaration de conformité précise pour quelle station STI-C elle a été établie.

    Une copie de la déclaration est mise à la disposition des autorités compétentes à leur demande.

    5.Mandataire

    Les obligations du fabricant visées au point 4 peuvent être remplies par son mandataire, en son nom et sous sa responsabilité, pour autant qu’elles soient spécifiées dans le mandat.



    PARTIE B

    DÉCLARATION CE DE CONFORMITÉ

    1. (identification unique de la station STI-C); ...

    2.Nom et adresse du fabricant ou de son mandataire ...

    3.La présente déclaration de conformité est établie sous la seule responsabilité du fabricant (ou de l’installateur): ...

    4.Objet de la déclaration (identification de la station STI-C permettant sa traçabilité; au besoin, une photo peut être jointe). ...

    5.L’objet de cette déclaration est conforme à la législation d’harmonisation de l’Union applicable: ...

    6.Références des normes harmonisées pertinentes appliquées ou des autres spécifications par rapport auxquelles la conformité est déclarée: ...

    8.Informations supplémentaires: ...

    Signé par et au nom de: ………………………….

    (lieu et date d’établissement)

    (nom, fonction) (signature)



    PARTIE C

    STATIONS STI-C CENTRALES PROCÉDURES D’ÉVALUATION DE LA CONFORMITÉ

    Module A

    Contrôle interne de la production

    1.Le contrôle interne de la production est la procédure d’évaluation de la conformité par laquelle l’exploitant remplit les obligations définies aux points 2, 3 et 4, et assure et déclare sous sa seule responsabilité que les stations STI-C concernées satisfont aux exigences du présent règlement qui leur sont applicables.

    2.Documentation technique

    L’exploitant établit la documentation technique permettant d’évaluer la conformité de la station STIC centrale aux exigences pertinentes, et notamment une analyse et une évaluation du ou des risques adéquates. La documentation précise les exigences applicables et couvre, dans la mesure nécessaire à l’évaluation, la conception, la fabrication et le fonctionnement du produit. Selon le cas, elle contient au minimum les éléments suivants:

    une description générale de la station STI-C centrale;

    des dessins de conception et des plans de fabrication, ainsi que des schémas des composants, des sousensembles, des circuits, etc.;

    les descriptions et explications nécessaires pour comprendre ces dessins et schémas, ainsi que le fonctionnement de la station STI-C centrale;

    une liste de normes harmonisées et/ou d’autres spécifications techniques pertinentes dont les références ont été publiées au Journal officiel de l’Union européenne, ou de normes internationales, appliquées entièrement ou en partie, et la description des solutions adoptées pour satisfaire au présent règlement lorsque de telles normes harmonisées n’ont pas été appliquées. Lorsque des normes harmonisées ont été appliquées en partie, la documentation technique précise quelles parties ont été appliquées;

    les résultats des calculs de conception, des contrôles effectués, etc.; et

    les rapports d’essais.

    4.Déclaration de conformité

    L’exploitant établit une déclaration écrite de conformité concernant un modèle de produit et la tient, accompagnée de la documentation technique, à la disposition des autorités nationales aussi longtemps que la station STI-C centrale est en service. La déclaration de conformité précise pour quelle station STI-C centrale elle a été établie.

    Une copie de la déclaration est mise à la disposition des autorités compétentes à leur demande.

    5.Mandataire

    Les obligations de l’exploitant visées au point 4 peuvent être remplies par son mandataire, en son nom et sous sa responsabilité, pour autant qu’elles soient spécifiées dans le mandat.

    PARTIE D

    STATIONS STI-C CENTRALES DÉCLARATION CE DE CONFORMITÉ

    1. (identification unique de la station STI-C); ...

    2.Nom et adresse de l’exploitant ou de son mandataire: ...

    3.La présente déclaration de conformité est établie sous la seule responsabilité de l’exploitant: ...

    4.Objet de la déclaration (identification de la station STI-C centrale permettant sa traçabilité): ...

    5.L’objet de cette déclaration est conforme à la législation d’harmonisation de l’Union applicable: ...

    6.Références des normes harmonisées pertinentes appliquées ou des autres spécifications par rapport auxquelles la conformité est déclarée: ...

    8.Informations supplémentaires: ...

    Signé par et au nom de: ………………………….

    (lieu et date d’établissement)

    (nom, fonction) (signature)

    Top