Document de processus de gestion des spécifications (SMPD)

Ce document, quel que soit son titre ou son contenu, n'est pas une spécification Bluetooth soumise aux licences accordées par Bluetooth SIG Inc. («Bluetooth SIG») et ses membres en vertu du contrat de licence de brevet / droit d'auteur Bluetooth et du contrat de licence de marque Bluetooth.

CE DOCUMENT EST FOURNI «EN L'ÉTAT» ET BLUETOOTH SIG, SES MEMBRES ET LEURS AFFILIÉS NE FONT AUCUNE DÉCLARATION OU GARANTIE ET DÉCLINENT TOUTE GARANTIE, EXPRESSE OU IMPLICITE, Y COMPRIS TOUTE GARANTIE DE QUALITÉ MARCHANDE, DE TITRE, DE NON-INFRACTION, DE NON-INFRACTION QUE LE CONTENU DE CE DOCUMENT EST EXEMPT D'ERREURS.

DANS LA MESURE NON INTERDITE PAR LA LOI, BLUETOOTH SIG, SES MEMBRES ET LEURS AFFILIÉS DÉCLINENT TOUTE RESPONSABILITÉ DÉCOULANT DE OU RELATIVE À L'UTILISATION DE CE DOCUMENT ET TOUTE INFORMATION CONTENUE DANS CE DOCUMENT, Y COMPRIS LA PERTE DE REVENUS, DE PROFITS, DE DONNÉES OU DE PROGRAMMES OU D'AFFAIRES INTERRUPTION OU POUR DOMMAGES SPÉCIAUX, INDIRECTS, INDIRECTS, ACCESSOIRES OU PUNITIFS, CEPENDANT CAUSÉ ET QUELQUE SOIT LA THÉORIE DE LA RESPONSABILITÉ, ET MÊME SI BLUETOOTH SIG, SES MEMBRES OU LEURS AFFILIÉS ONT ÉTÉ AVISÉS DE LA POSSIBILITÉ DE TELS DOMMAGES.

Ce document est la propriété de Bluetooth SIG. Ce document peut contenir ou couvrir des sujets qui sont la propriété intellectuelle de Bluetooth SIG et de ses membres. La fourniture de ce document n'accorde aucune licence à aucune propriété intellectuelle de Bluetooth SIG ou de ses membres.

Ce document est sujet à changement sans préavis.

Copyright © 2004–2019 par Bluetooth SIG, Inc. La marque et les logos Bluetooth sont la propriété de Bluetooth SIG, Inc. Les autres marques et noms tiers sont la propriété de leurs propriétaires respectifs.

1. Introduction

Le document de processus de gestion des spécifications (SMPD) décrit les processus que les auteurs de spécifications etviewLes utilisateurs doivent suivre pour développer de nouvelles spécifications et améliorer les spécifications existantes (c'est-à-dire ajouter ou supprimer des fonctionnalités ou modifier des fonctionnalités spécifiques dans une spécification adoptée), maintenir les spécifications adoptées et gérer la fin de vie des spécifications adoptées. De plus, ce document décrit le processus de création, de reviewing et approuver les livres blancs.

Il existe des différences dans le processus d'élaboration des spécifications entre l'élaboration de nouvelles spécifications et l'amélioration des spécifications existantes en raison des différences inhérentes à la portée de ces tâches; ces différences sont mises en évidence dans ce document.

Le processus d'élaboration des spécifications comprend:

Une phase d'exigences (décrite dans la section 3) pour définir les exigences fonctionnelles

Une phase de développement (décrite à la section 4) pour développer et review caractéristiques
Une phase de validation (décrite dans la section 5) pour valider les spécifications au moyen de tests de prototypes interopérables (PIO)

Une phase d'adoption / d'approbation (décrite dans la section 6) pour présenter les spécifications au conseil d'administration (CA) Bluetooth SIG pour adoption / approbation

Le document Specification Errata Process (EPD) [3] décrit le processus de proposition et de reviewerrata de spécification, et les approuver en tant que corrections d'errata (tels que définis dans les statuts [2]) aux spécifications adoptées. Sauf indication contraire, toutes les références aux errata dans ce SMPD signifient des errata de spécification.

1.1 Préséance

Les statuts de Bluetooth SIG, Inc. (statuts) et les accords d'adhésion [2] prévalent sur tout contenu contradictoire dans ces documents et le SMPD. Nonobstant tout ce qui se trouve dans ce document, le CA conserve la discrétion et l'autorité ultime pour prendre des mesures et prendre des décisions même si ces actions et décisions ne suivent pas ou ne sont pas en conflit avec quoi que ce soit dans ce document, et rien dans ce document ne limite ou ne restreint l'autorité indépendante du CA. et discrétion.

En cas de conflit entre le texte du SMPD et les figures, le texte prévaut.

1.2 Groupes et comités référencés

Les types de groupes suivants sont référencés dans ce document : Groupes d'étude (SG), Groupes d'experts (EG) et Groupes de travail (WG). Un groupe de travail peut également avoir un sous-groupe qui rend compte au groupe de travail. De même, les types de comités suivants sont référencés dans ce document : Bluetooth Architectural Review Carte (BARB), Test et interopérabilité Bluetooth (BTI) et Qualification Bluetooth Review Conseil (BQRB). Ce document fait également référence au personnel technique Bluetooth SIG (BSTS) et au CA.

1.3 Comité concernantviews et approbations

Un comité review est une réview qui est menée par les membres d'un comité (généralement 3 membres) pour fournir des commentaires dans un délai spécifié (généralement 2-3 semaines), cependant le review le temps peut varier en fonction de la longueur et de la complexité du matériel et d'autres priorités au sein du comité. Le groupe demandant la review et le comité chargé de la review chacun s'accorde sur la durée de la review. Les membres du groupe et du comité utilisent les outils Bluetooth SIG pour notifier et enregistrer le début et la fin de la review. Le groupe traitera généralement les commentaires du comité lorsqu'ils seront reçus. Lorsque le comité review le délai expire, le groupe termine de répondre aux commentaires du comité et devrait également prendre en compte tout retour tardifview commentaires en gardant à l'esprit que le matériel peut être soumis à une approbation ultérieure par le comité.

L'approbation du comité est obtenue par un vote des membres du comité conformément au document de processus du groupe de travail [4].

1.4 Avis aux membres et accessibilité du matériel

Tous les avis fournis aux membres conformément à ce document peuvent être fournis par courrier électronique, comme une mise à jour technique périodique. Les notifications qui doivent être fournies à tous les membres seront envoyées à tous les membres actifs (c'est-à-dire lorsque l'adhésion n'a pas été suspendue, résiliée ou retirée). Lorsque les notifications sont envoyées par e-mail, elles seront envoyées à la dernière adresse e-mail connue (comme indiqué dans les enregistrements actuels de Bluetooth SIG) de chaque personne qui s'est inscrite sous le compte d'adhésion de la société membre et qui n'a pas choisi de ne pas recevoir de notifications par e-mail. Rien dans ce document ne modifie les obligations ou exigences de Bluetooth SIG en ce qui concerne la fourniture d'avis en vertu des statuts ou de tout autre accord entre Bluetooth SIG et un membre.

Partout où ce document fait référence à un website accessible à tous les membres, il s'agit de l'accessibilité aux personnes disposant d'un compte Bluetooth SIG actif. Les membres qui n'ont pas de compte actif peuvent créer un compte via le Bluetooth SIG website.

1.5 Modèles

Pour chaque type de document (par exemple, spécifications, livres blancs, documents de test) mentionné dans ce SMPD, Bluetooth SIG fournit un modèle. Le modèle doit être utilisé comme base pour chaque document produit conformément à la présente SMPD. Ne pas utiliser le bon modèle peut entraîner la non-approbation du document. Des modèles sont disponibles sur le Bluetooth SIG websites [8].

1.6 Types de spécifications

Il existe plusieurs types de spécifications Bluetooth SIG. Hiérarchiquement, toutes les spécifications dépendent de la spécification Bluetooth Core. Spécifications telles que pro traditionnelfiles; protocoles traditionnels ; et pro basé sur le GATTfiles, les services basés sur le GATT et les protocoles basés sur le GATT dépendent tous des caractéristiques de la spécification de base. D'autres spécifications, telles que les spécifications du modèle de maillage, dépendent du Mesh Profile spécification qui à son tour dépend de la spécification de base.

La spécification Core Specification Supplement (CSS) définit les types de données, les formats de données et les profile et les codes d'erreur de service qui sont utilisés par la spécification de base et d'autres spécifications et ne définissent eux-mêmes aucun comportement.

La spécification GATT Specification Supplement (GSS) définit les formats de caractéristiques et de descripteurs utilisés par Profiles et Services et ne définit lui-même aucun comportement.
La spécification Mesh Device Properties (MDP) définit les propriétés de maillage utilisées par le Mesh Profile et les spécifications du modèle de maillage et ne définit lui-même aucun comportement.

2. Plus deview

Cette section fournit un aperçuview des processus et ne vise pas à inclure tous les détails.

La figure 2.1 montre les six phases principales qui composent le processus de gestion des spécifications.

Les quatre premières phases se déroulent pendant le processus de développement des spécifications et comprennent la phase des exigences (section 3), la phase de développement (section 4), la phase de validation (section 5) et la phase d'adoption / approbation (section 6). Ceci est suivi de deux phases post-adoption: la phase de maintenance des spécifications (section 7) et la phase de fin de vie des spécifications (section 8).

La figure 2.2 illustre les détails des quatre phases du processus d'élaboration des spécifications. Les cases grises indiquent les principaux livrables pour chaque phase. Les cases orange résument les étapes du processus.

Dans la phase des exigences (décrite à la section 3), une proposition de démarrage d'un nouveau travail (une nouvelle proposition de travail (NWP)) lance le processus de développement de spécification en définissant les scénarios utilisateur à activer si le nouveau travail se poursuit. Si le NWP est approuvé, un groupe affecté crée un document d'exigences fonctionnelles (FRD). Une fois que le FRD est approuvé et attribué à un groupe, la phase de développement commence.

Au cours de la phase de développement (décrite à la section 4), le développement des spécifications progresse à travers une séquence de stages (0.5/DIPD à 0.9/CR) aboutissant à une ébauche complète de la spécification. La spécification 0.9/CR est mise à la disposition de tous les membres, puis soumise au CA qui examine la spécification pour approbation. Une fois approuvée, la phase de validation commence.

Au cours de la phase de validation du développement de la spécification (décrite à la section 5), la spécification 0.9/CR approuvée par le CA est mise à la disposition de tous les membres pourview et valider, et Member Review a démarré. La validation est effectuée via des tests d'interopérabilité (IOP) entre les prototypes construits par les membres. Une fois que les tests IOP sont terminés (si requis pour la spécification) et que BARB approuve le rapport de test IOP, la phase d'adoption/approbation commence.

Au cours de la phase d'adoption / d'approbation (décrite à la section 6), la spécification et les documents d'essai connexes sont finalisés; Les approbations BARB, BQRB et BTI sont reçues; et le dossier de spécification final est soumis au CA qui examine la spécification pour adoption (c.-à-d. approbation finale).

Une spécification peut avoir besoin de revenir à une phase précédente ou stage si des changements importants sont apportés. Dans certains cas, il peut également être possible de renoncer à une partie d'une phase comme décrit à la section 4.4.

La phase de maintenance des spécifications (décrite à la section 7) commence après l'adoption d'une spécification par le CA. Au cours de cette phase, les erreurs potentielles trouvées dans une spécification adoptée sont signalées et évaluées, et (si nécessaire) des corrections d'errata sont apportées à la spécification. La phase de maintenance des spécifications se poursuit jusqu'à ce que la spécification soit abandonnée ou retirée (voir Phase de fin de vie des spécifications dans le paragraphe suivant).

La phase de fin de vie des spécifications (décrite à la section 8) décrit le processus de dépréciation et de retrait des spécifications adoptées.

3. Phase des exigences

La phase des exigences commence soit par un PTN (qui déclare le désir de commencer le travail sur un ou plusieurs scénarios utilisateur) ou après une détermination que le nouveau travail souhaité est déjà couvert par leur charte de groupe de travail. Si un groupe de travail souhaite commencer un nouveau travail qui, selon lui, fait déjà partie du champ d'application de sa charte de groupe de travail, le groupe de travail doit suivre le processus défini dans la section 3.1 pour procéder directement au développement d'un FRD. Pour tous les autres éléments de travail, le groupe de travail doit suivre le processus défini dans la section 3.2. Le FRD définit la portée des exigences fonctionnelles qui sont utilisées pour construire les spécifications dans la phase de développement. La phase des exigences est illustrée à la figure 3.1.

3.1 Nouveaux travaux couverts par une charte du GT

Lorsqu'un groupe de travail souhaite commencer un nouveau travail et estime raisonnablement que la fonctionnalité qu'il souhaite ajouter est déjà dans le champ d'application de sa charte de groupe de travail, le groupe de travail peut commencer à travailler sur le FRD, à condition d'en informer immédiatement BARB. Le groupe de travail inclura dans sa notification au BARB une description du nouveau travail proposé et une copie de la charte du groupe de travail avec un texte en surbrillance qui l'autorise à commencer le nouveau travail.

Si le BARB rejette l'analyse du GT, le GT doit arrêter le travail sur le FRD et poursuivre le processus de prévision numérique du temps décrit dans la section 3.2. Si le BARB approuve l'analyse du WG, le WG en informera immédiatement BSTS (par e-mail à specification.manager@bluetooth.com) et BSTS ajoutera le point au prochain ordre du jour du CA.

Le groupe de travail inclura dans sa notification à BSTS les mêmes informations qu'il a fournies à BARB. Si le CA rejette l'analyse du groupe de travail, le groupe de travail doit arrêter les travaux sur le FRD et poursuivre le processus de prévision numérique du temps décrit dans la section 3.2. Si le CA approuve l'analyse du groupe de travail, le groupe de travail peut continuer à travailler sur le FRD comme indiqué dans la section 3.3.

3.2 Nouvelle proposition de travail (NWP)

Tout membre, GT, SG ou EG peut créer et soumettre un NWP (via le Bluetooth SIG website [10]). Un PTN doit inclure, au minimum, des informations sur les éléments suivants en utilisant le modèle officiel fourni dans [8] :

Scénarios utilisateur
Engagement des membres à développer le FRD et dans quel(s) domaine(s) (par exemple, contributeur, auteur, révieweuh, prototypage)
Proposition de leadership des travaux du FRD
Proposition d'affectation de groupe pour le travail FRD
Adresse e-mail du ou des auteurs principaux

Note: Des conseils sur le processus de prévision numérique du temps sont disponibles sur le Bluetooth SIG websites [10].

BSTS exécutera les tâches suivantes pendant le développement du NWP:

Fournissez aux auteurs un accusé de réception (généralement dans les sept jours civils suivant la réception) et décrivez les étapes suivantes.
Si nécessaire, travaillez avec le (s) auteur (s) pour que le NWP soit clair et complet. Cela peut nécessiter plusieurs itérations du NWP.
Si le NWP contient des déclarations sur des erreurs dans les spécifications Bluetooth adoptées, travaillez avec le(s) auteur(s) pour file entrées dans le système d'errata.
S'il est remarqué que le PTN est potentiellement en train de dupliquer un travail qui est déjà en cours ou qui a déjà été achevé, informez les auteurs des autres travaux pour leur évaluation.
Publier le NWP sur le NWP website accessible à tous les membres.

Avertir tous les membres que le NWP est disponible pour review et si un engagement supplémentaire des membres pour développer le FRD est nécessaire.

Les membres peuvent contacter le (s) auteur (s) pour poser des questions ou pour faire part de leurs commentaires sur le PTN.

Au moins trois entreprises membres doivent s'engager à participer à l'achèvement du FRD résultant pour que le NWP devienne un candidat à l'approbation du CA, et au moins une entreprise membre doit être membre associé ou promoteur. Sur approbation du CA du PNT, le CA attribuera le PTN à un sous-groupe ou SG composé de tous les membres pour travailler sur le FRD (décrit dans la section 3.3). Si un sous-groupe WG ou SG approprié n'existe pas, il peut en être créé un.

Pour les PNT qui ont un engagement de membres suffisant, BSTS effectuera les tâches supplémentaires suivantes:

Au moins 13 jours avant que le NWP ne soit proposé pour approbation par le CA, notifier le BARB et le groupe auquel il est recommandé d'attribuer le NWP de l'approbation en attente de la NWP. Ceci est fait pour fournir une opportunité de rétroaction dans des domaines tels que le groupe proposé, si le PTN est déjà couvert par les travaux existants, etc.
Soumettez le PTN rempli au CA.

Si le PTN est soumis par des membres qui ne sont pas associés à un groupe, demandez à l'un des membres de le présenter au CA.

Si le PTN est soumis par un groupe, demandez au président du groupe de le présenter au CA.
Invitez le président du BARB et les présidents du groupe, auquel le PTN est recommandé pour l'affectation, à la réunion du CA.
Si le NWP est approuvé et attribué par le CA, notifier le groupe auquel il a été attribué; les auteurs); les membres identifiés dans le PTN comme s'engageant à développer le FRD correspondant; et si le PTN est proposé par un groupe, le groupe du résultat et les étapes suivantes.

Une fois qu'un NWP est approuvé par le CA, mettez à jour le statut sur le NWP website.

Tout NWP peut être rejeté par le CA à sa discrétion, par ex.ample, en raison des limitations de ressources, si le travail est déjà entièrement terminé, le travail est hors de portée des documents constitutifs de Bluetooth SIG (par exemple, l'interface de programmation d'application (API)) [2], ou si le travail proposé doit être filed comme erratum. Si le NWP est rejeté, le BSTS en informera le ou les auteurs, les membres identifiés dans le NWP comme s'engageant à développer le FRD correspondant et, si le NWP est proposé par un groupe, le groupe. La notification comprendra toutes les raisons du rejet. Le ou les auteurs, les membres engagés ou le groupe peuvent demander du temps à l'ordre du jour du CA pour faire appel du rejet.

Si un membre ou un groupe souhaite proposer de supprimer une fonction d'une spécification adoptée, le groupe ou le membre doit préparer un NWP. La prévision numérique du temps doit inclure une analyse de l'impact que la suppression aura sur la rétrocompatibilité et l'interopérabilité, y compris une analyse de l'impact sur les cas de test.

Les NWP ne sont pas nécessaires pour les améliorations des spécifications CSS, GSS ou MDP: en général, les mises à jour des spécifications CSS, GSS ou MDP résultent de mises à jour d'autres spécifications qui ont leurs propres NWP.

3.3 Document des exigences fonctionnelles (FRD)

Les FRD définissent les exigences fonctionnelles pour activer les scénarios utilisateur. Un FRD doit inclure, au minimum, des informations sur les éléments suivants en utilisant le modèle officiel fourni en [8]:

Scénarios utilisateur
Exigences fonctionnelles basées sur les scénarios utilisateur
Engagement des membres à développer les spécifications résultantes
Support de prototype facultatif par les membres pour les rôles prévus
Groupe de travail recommandé pour développer les spécifications résultantes

Développement FRD

Les FRD sont créés par le sous-groupe de groupe de travail composé de tous les membres ou les membres du SG avec le soutien éditorial de BSTS. Tout membre intéressé à participer au développement de FRD peut rejoindre le groupe.

Les FRD doivent indiquer un engagement d'au moins deux (même si trois sont encouragés) sociétés membres associées ou promoteurs à participer à l'élaboration de la spécification résultante. Les GT ou SG qui soumettent un FRD doivent tenter d'obtenir un large soutien de la part des sociétés membres du groupe qui représentent le segment industriel cible prévu identifié dans le FRD.

Les nouvelles fonctionnalités proposées dans un FRD doivent être supportables sur autant de transports et d'appareils existants que possible. Cela comprend, par example, soutenant les pros du GATTfiles et services sur le transport Basic Rate/Extended Data Rate (BR/EDR) et le transport Bluetooth Low Energy (LE). Si la nouvelle fonctionnalité ne prend pas suffisamment en charge les membres pour un transport, par ex.ample en raison d'un manque d'engagement des membres à définir l'utilisation du transport ou d'un nombre potentiellement insuffisant de plates-formes de test IOP pour un ou plusieurs rôles, le support sur ce transport peut être exclu du FRD.

Sauf justification contraire, nouvelle fonctionnalité, profiles, et les services doivent être conformes aux exigences de compatibilité descendante décrites à la section 3.3.2.

Le GT ou le SG doit soumettre le FRD à BARB pour review et approbation. BARB doit approuver ou rejeter le FRD sur la base de son jugement technique. S'il est approuvé par BARB, le FRD sera mis à la disposition de tous les membres et une notification de sa disponibilité sera émise par BSTS.

Les FRD ne sont pas nécessaires pour les améliorations des spécifications CSS, GSS ou MDP: généralement, les mises à jour des spécifications CSS, GSS ou MDP résultent de mises à jour d'autres spécifications qui ont leurs propres FRD.

Exigences de compatibilité descendante

Rétrocompatibilité pour BR / EDR

Pour le fonctionnement BR / EDR, l'exigence de compatibilité descendante est définie comme l'interopérabilité avec la partie BR / EDR de la spécification Bluetooth Core v1.1 et versions ultérieures.

Rétrocompatibilité pour Bluetooth Low Energy

Pour le fonctionnement LE, l'exigence de compatibilité descendante est définie comme l'interopérabilité avec la partie LE de la spécification Bluetooth Core v4.0 et versions ultérieures.

Compatibilité descendante pour les spécifications autres que la spécification principale

Pour les spécifications autres que la spécification Bluetooth Core, la compatibilité descendante d'une version donnée doit être maintenue avec toutes les versions antérieures qui ont le même numéro de version principale. Par example, la version 1.3 doit être compatible avec les versions 1.2, 1.1 et 1.0, mais la version 2.0 peut ne pas être compatible avec les versions 1.0, 1.1, 1.2 et 1.3. Notez qu'une augmentation du numéro de version principale de la spécification principale n'implique pas un manque de compatibilité descendante avec les versions précédentes.

Exemption des exigences de compatibilité descendante

Le GT ou le SG peut proposer d'exempter une fonctionnalité spécifique de l'exigence de compatibilité descendante si une justification est fournie. Par example, s'il est démontré que la fonctionnalité a de faibles taux d'adoption sur le marché ou, en raison de problèmes d'interopérabilité, il est préférable de supprimer ou de remplacer la fonctionnalité que de modifier la fonctionnalité. Le groupe de travail ou le SG doit inclure toutes les exemptions de compatibilité descendante dans le FRD, qui sont approuvées par BARB après approbation du FRD. Toute exemption approuvée par le BARB sera présentée au CA pour approbation à la 0.9/CR Stage.

3.4 Charte du groupe de travail

Lorsque le BARB approuve un FRD qu'il est proposé d'attribuer à un groupe de travail existant, ce groupe de travail doit préparer un projet de mise à jour de sa charte pour ajouter la nouvelle fonctionnalité au champ d'application (à moins que le CA n'ait préalablement approuvé l'analyse du groupe de travail selon laquelle une mise à jour de la charte du groupe de travail est non requis). Cependant, lorsque BARB approuve un FRD qui est proposé d'être affecté à un nouveau groupe de travail, le BARB et les membres qui souhaitent développer la fonctionnalité décrite dans le FRD doivent préparer un projet de charte pour un nouveau groupe de travail avec la nouvelle fonctionnalité incluse dans le champ d'application de la charte. .

Une fois la charte du groupe de travail nouvelle ou mise à jour préparée, elle doit être soumise à BARB pour réexamen.view et approbation. Une fois que le BARB aura approuvé la charte, le projet de charte du GT nouveau ou mis à jour sera soumis au CA pour approbation.

Une fois que le CA approuve la charte, le groupe de travail auquel le travail de développement des spécifications a été assigné par le CA doit travailler en étroite collaboration avec le groupe qui a préparé le FRD au cas où des mises à jour ou des clarifications nécessaires de ce FRD seraient nécessaires. Si une mise à jour du FRD est nécessaire pendant la phase de développement, les processus décrits dans la section 3.3 et cette section doivent être suivis; cependant, le développement des spécifications peut se produire en parallèle avec les mises à jour de la charte FRD et WG.

3.5 Exigences Exigences de sortie de phase

La phase des exigences est terminée et la phase de développement commence lorsqu'une charte de groupe de travail avec la portée nécessaire pour le FRD est confirmée ou approuvée par le CA et que les exigences suivantes ont été satisfaites:

Le NWP a été soit approuvé par le CA, soit le CA a convenu qu'un NWP n'est pas nécessaire.
Le FRD et la charte correspondante du GT ont été approuvés par BARB.

4. Phase de développement

Au cours de la phase de développement, le ou les groupes de travail affectés créent la nouvelle spécification et / ou améliorent une spécification existante. Le FRD définit les exigences de la spécification Bluetooth nouvelle ou améliorée. Aucune fonctionnalité n'est autorisée dans la spécification qui n'est pas raisonnablement liée aux exigences du FRD. L'objectif est de créer une spécification 0.9 / CR prête pour la phase de validation (décrite dans la section 5) à la fin de la phase de développement.
Au cours de la phase de développement, une spécification (ou amélioration de la spécification) progresse à travers trois staget.

Pour une nouvelle spécification, les trois stagils sont :

0.5 Stage
0.7 Stage
0.9 Stage

Pour une amélioration des spécifications, les trois stagils sont :

Projet de document de proposition d'amélioration (DIPD) Stage
Document de proposition d'amélioration finale (FIPD) Stage
Demande de modification (CR) Stage

Chaque stage est décrit plus en détail dans les sous-sections qui suivent. La figure 4.1 ci-dessous illustre les différents documents que le GT préparera à chaque stage.

Figure 4.1 : Plusview du cahier des chargestages qui se produisent pendant la phase de développement

Le rôle de BARB tout au long du processus de développement des spécifications est de fournir aux GT des conseils et une assistance technique. Les groupes de travail peuvent, à tout moment, demander à BARB des conseils techniques concernant l'élaboration de spécifications et les concepts architecturaux à utiliser dans une spécification. Les groupes de travail sont particulièrement encouragés à solliciter rapidement des commentaires de BARB pour les fonctionnalités qui ont des considérations architecturales plus complexes.

4.1 0.5/DIPDStage

Pendant le 0.5/DIPD Stage, le groupe de travail développera les éléments suivants en utilisant les modèles officiels fournis dans [8] :

Pour une nouvelle spécification, un projet de spécification 0.5, qui doit inclure, au minimum, des informations sur les éléments suivants:

Architecture pour couvrir les exigences telles que définies dans le FRD
Pour les protocoles, les points d'accès aux services définis
Pour les services, les données et les comportements exposés
Pour les prosfiles, protocoles identifiés et fonctionnalités spécifiées

2. Pour une amélioration de la spécification, un projet de DIPD, qui doit inclure, au minimum, des informations sur les éléments suivants:

Arrière-plan: La portée des travaux, les objectifs guidant les travaux et la manière dont cette proposition spécifique s'inscrit dans le champ d'application

Surview de proposition : Un résumé des fonctionnalités étendues (flexibilité accrue, performances améliorées, etc.) fournies par le DIPD, y compris une description claire de la manière dont la nouvelle fonctionnalité s'intègre dans la version actuelle des spécifications. Si le groupe de travail a évalué plusieurs propositions, ces propositions doivent être incluses pour permettre au BARB de déterminer si une diligence raisonnable suffisante a été faite lors de la sélection de la proposition préférée.
Couverture des exigences: Un résumé de la couverture des exigences fonctionnelles donnée par la proposition, avec référence aux exigences système appropriées et aux scénarios d'utilisation indiqués dans le FRD associé
Définition du problème: Un énoncé des problèmes résolus par la (les) proposition (s)

Critères de sélection : Une déclaration concernant les critères de sélection / de performance à partir des paramètres d'évaluation associés qui ont guidé le processus de sélection
Justification du choix: Un examen des métriques d'évaluation qui justifient le choix entre les propositions et révèlent des compromis
Description: Une description de la fonctionnalité et des protocoles étendus. Cette section peut s'adapter à différents besoins en ajoutant des sous-sections pertinentes.

3. Stratégie de test: Une description de la fonctionnalité proposée pour être testée (ou non testée) dans le cadre du programme de qualification Bluetooth et comment la fonctionnalité qu'il est proposé de tester (par exemple, les attentes sur le(s) testeur(s) inférieur(s) ou le(s) testeur(s) supérieur(s), et si les tests seront attribués en tant que tests de conformité ou d'interopérabilité ou une combinaison des deux). Cela peut être dans un document séparé ou dans une section séparée dans la spécification 0.5/DIPD. Les conventions à utiliser dans une Stratégie de Test sont décrites dans Stratégie de Test et Terminologieview (TSTO) [5].

Le principal public des documents à ce stage sont les membres du GT et BARB qui review les propositions architecturales et la couverture des besoins, et les BTI qui reviews la stratégie de test. Dans la plupart des cas, les documents à ce stage ne sont pas destinés à contenir du texte qui est prévu pour être inclus dans la spécification finale.

BSTS doit review tous les documents pour assurer la cohérence avec les directives de rédaction Bluetooth [1] et identifier les problèmes à résoudre par le groupe de travail. BARB doit review la spécification 0.5/DIPD. Pour une amélioration des spécifications, BARB doit également review le DIPD pour la conformité aux exigences de compatibilité descendante décrites à la section 3.3.2. RTC doit review la stratégie de test.

BARB doit approuver ou rejeter la spécification 0.5/DIPD en fonction de son jugement technique. Si elle est approuvée par BARB, la spécification 0.5/DIPD sera disponible sur le Bluetooth SIG website à tous les membres associés et promoteurs et une notification de sa disponibilité sera émise par BSTS. Au 0.5/DIPD Stage, l'approbation de la stratégie de test n'est pas requise.
Le 0.5/DIPD Stage n'est pas requis pour les améliorations des spécifications CSS, GSS ou MDP

0.5/DIPD Stage conditions de sortie

Le 0.5/DIPD Stage est complet et le 0.7/FIPD Stage commence lorsque les conditions de sortie suivantes sont remplies :

BSTS a terminé reviewla spécification 0.5/DIPD et la stratégie de test.

BARB a approuvé la spécification 0.5 / DIPD.
BTI a terminé sa review de la stratégie de test.
BSTS a mis la spécification approuvée 0.5 / DIPD à la disposition de tous les membres associés et promoteurs.

4.2 0.7/FIPD Stage

Pendant la 0.7/FIPD Stage, le groupe de travail développera les éléments suivants en utilisant les modèles officiels fournis dans [8] :

Pour une nouvelle spécification, un projet de spécification 0.7, qui doit inclure, au minimum, des informations sur les éléments suivants:

Une description de tous les changements qui ont été apportés depuis l'approbation du BARB 0.5, y compris les propositions nouvelles ou modifiées, les critères de sélection et la justification du choix. Les modifications doivent être décrites avec le même niveau de détail que celui requis dans le 0.5 Stage.
Toutes les exigences fonctionnelles du FRD ont été prises en compte.

2. Pour une amélioration de la spécification, un projet de FIPD, qui doit inclure, au minimum, des informations sur les éléments suivants:

Une description de tous les changements qui ont été apportés depuis le DIPD approuvé par le BARB, y compris les propositions nouvelles ou modifiées, les critères de sélection et la justification du choix. Les modifications doivent être décrites avec le même niveau de détail que celui requis dans le DIPD Stage.

Au besoin, approfondir les domaines décrits dans la section 4.1 concernant la DIPD.
Une description complète de l'amélioration.
Une description architecturale mise à jour.
Toutes les exigences fonctionnelles du FRD ont été prises en compte.

3. 0.7 / Documents de test FIPD, qui doivent inclure, au minimum, des informations sur les points suivants:

Une suite de tests, constituée d'une liste d'objectifs de test tels que décrits dans le TSTO [5].

Une déclaration de conformité d'implémentation (ICS), comme décrit dans le TSTO [5].

Pour les améliorations de spécification, la suite de tests et l'ICS peuvent être fournis sous forme de documents séparés ou de sections supplémentaires dans le FIPD.

Le public principal des documents produits à ce stage sont les membres du GT et BARB qui review la description complète de la fonctionnalité ou de l'amélioration, y compris du texte prévu pour être inclus dans la spécification finale. BTI est le public pour review des documents d'essai.

BSTS sera réview les parties nouvelles ou modifiées de la spécification 0.7/FIPD et les documents de test pour la cohérence avec les directives de rédaction Bluetooth, y compris les conventions linguistiques établies par Bluetooth SIG. BARB sera réview la spécification 0.7/FIPD.

BSTS aidera le groupe de travail à préparer les documents de test 0.7 / FIPD conformément au TSTO [5].

RTC doit review les documents de test 0.7/FIPD. Le groupe de travail doit fournir la spécification 0.7/FIPD à BTI comme référence lors de la reviewles documents de test 0.7/FIPD, que BTI renouvelleraview conformément à la spécification RTC Review Liste de contrôle du processus [6].

Après BARB a terminé son review de la spécification 0.7/FIPD et BTI a terminé sa review des documents de test 0.7/FIPD, BSTS fera le reviewed 0.7/FIPD spécification disponible pour tous les membres associés et promoteurs.

Le 0.7/FIPD Stage n'est pas requis pour les améliorations des spécifications CSS, GSS ou MDP.

0.7/FIPD Stage conditions de sortie

Le 0.7/FIPD Stage est complet et le 0.9/CR Stage commence lorsque les conditions de sortie suivantes sont remplies :

BSTS a terminé reviewla spécification 0.7/FIPD et les documents de test.
BARB a terminé reviewla spécification 0.7/FIPD.
RTC a terminé reviewing la 0.7/FIPD Test Suite (Test Purposes) et 0.7/FIPD ICS.
BSTS a fait le reviewed 0.7/FIPD spécification disponible pour tous les membres associés et promoteurs.

4.3 0.9/RC Stage

Il existe deux types de CR: un CR intégré, qui est un document suivi des modifications d'une spécification adoptée entière montrant toutes les modifications depuis la version précédente, et un CR abrégé, qui est un document qui fournit des instructions pour modifier uniquement les sections concernées de la version de spécification sur laquelle le CR est basé.

Pendant la 0.9/CR Stage, le groupe de travail développera les éléments suivants en utilisant les modèles officiels fournis dans [8] :

Pour une nouvelle spécification, une ébauche complète du contenu de la spécification 0.9, qui doit inclure, au minimum, des informations sur les éléments suivants:

Une description de tous les changements qui ont été apportés depuis le BARB-reviewed 0.7 spécification (ou puisque la spécification 0.5 si la production de la spécification 0.7 avait été supprimée), y compris les nouvelles ou
propositions modifiées, critères de sélection et justification du choix. Les modifications doivent être décrites avec le même niveau de détail que celui requis dans le 0.5 Stage et 0.7 Stage.

2. Pour une amélioration des spécifications:

Soit un CR intégré, qui doit inclure, au minimum, des informations sur les éléments suivants:

Une description de tous les changements qui ont été apportés depuis le BARB-reviewed FIPD (ou depuis le DIPD si le FIPD a été levé) y compris les propositions nouvelles ou modifiées, les critères de sélection et la justification du choix. Les modifications doivent être décrites avec le même niveau de détail que celui requis dans le DIPD Stage et FIPD Stage.
Toutes les modifications proposées à la spécification précédemment adoptée à l'aide du suivi des modifications.
Tous les errata techniques approuvés (avec chaque erratum référencé avec un numéro d'erratum), présentés à l'aide du suivi des modifications, qui n'ont pas encore été incorporés dans la version de spécification précédemment adoptée, et qui ont un impact sur le texte associé à l'amélioration de la spécification; ou qui ont un impact sur les tests de la PIO.

3. Ou un CR abrégé, qui doit inclure, au minimum, des informations sur les éléments suivants:

Une description de tous les changements qui ont été apportés depuis le BARB-reviewed FIPD (ou depuis le DIPD si le FIPD a été levé) y compris les propositions nouvelles ou modifiées, les critères de sélection et la justification du choix. Les modifications doivent être décrites avec le même niveau de détail que celui requis dans le DIPD Stage et FIPD Stage.
Tous les changements proposés à chaque section et paragraphe concernés de la spécification que le CR propose de changer.
Tous les errata techniques approuvés (avec chaque erratum référencé avec un numéro d'erratum), indiqués à l'aide d'un balisage, qui n'ont pas encore été incorporés dans la version de spécification précédemment adoptée, et qui ont un impact sur le texte associé à l'amélioration de la spécification; ou qui ont un impact sur les tests de la PIO.

4. Un CR CSS (si de nouvelles entrées sont requises par la spécification), qui peut être incorporé dans un CR abrégé de la spécification.
5. Un CR GSS (si de nouvelles entrées sont requises par la spécification), qui peut être incorporé dans un CR abrégé de la spécification.
6. Un MDP CR (si de nouvelles entrées sont requises par la spécification), qui peut être incorporé dans un CR abrégé de la spécification.
7. Documents de test 0.9 / CR, qui doivent inclure, au minimum, des informations sur les éléments suivants en utilisant le modèle officiel fourni en [8]:

La suite de tests 0.9 / CR, qui comprend des cas de test complets et le tableau de mappage de cas de test associé (TCMT), comme décrit dans le TSTO [5].
Le 0.9 / CR ICS, comme décrit dans le TSTO [5].
Si la configuration des tests nécessite des paramètres spécifiques pour l'implémentation sous test (IUT), la 0.9 / CR Implementation eXtra Information for Testing (IXIT).

La liste de référence de cas de test 0.9 / CR (TCRL) (facultative pour les mises à jour des spécifications de base)

8. Une analyse de la couverture des tests indiquant quelles exigences de spécification sont testées ou non testées dans la suite de tests 0.9 / CR (pour les améliorations des spécifications, l'analyse de la couverture des tests doit uniquement inclure les fonctionnalités nouvellement ajoutées et impactées, et non les zones non impactées de la spécification d'origine).
9. Un plan de test de la PIO.

Pour les améliorations de spécification, la suite de tests, ICS et IXIT peuvent être fournis soit sous forme de documents séparés, soit sous forme de sections supplémentaires dans le CR abrégé.

Dans la plupart des cas, un CR intégré ou abrégé doit être basé sur la version précédemment adoptée de la spécification, mais il peut également être basé sur le dernier projet intermédiaire. Le dernier numéro de version de la spécification provisoire intermédiaire doit être le numéro de version associé à une version du document gelée et qui ne changera pas avec le temps. Sinon, des informations d'identification supplémentaires (telles que la date du document et un URL à un emplacement permanent) doivent être fournis pour identifier la version «de référence» spécifique. Si un brouillon intermédiaire est utilisé, tous les changements qui ne sont pas directement liés au CR dans une section donnée que le CR modifie doivent être inclus, mais ne doivent pas obligatoirement être affichés à l'aide d'un balisage. Si les parties pertinentes du projet intermédiaire sont mises à jour ultérieurement, le CR doit être mis à jour pour refléter les mises à jour du projet intermédiaire.

Idéalement, le matériel CR abrégé est intégré dans un projet de spécification complète et dans les documents de test complets respectivement, avant la phase de validation, mais ils peuvent également être intégrés au début de la phase de validation. Si plusieurs fonctionnalités sont en cours de développement pour une spécification (par exemple, la spécification de base), il peut être souhaitable d'intégrer les fonctionnalités dans un seul projet une fois les tests de PIO terminés.

BSTS sera réview la spécification 0.9/CR et les documents de test pour la cohérence avec les directives de rédaction Bluetooth. Ensuite, BARB review la spécification 0.9/CR suivie plus tard du plan de test IOP (comme décrit dans la section 4.3.1). Une fois que la spécification 0.9/CR est soumise par le groupe de travail à BARB pour review, BSTS le rendra accessible à tous les membres pourview et aviser tous les membres de sa disponibilité. À partir de ce stade du processus d'élaboration des spécifications, BSTS mettra à la disposition de tous les membres les projets de spécifications soumis à BARB avec des notifications périodiques envoyées à tous les membres.

Pour une amélioration de la spécification, le groupe de travail recommandera au CA si les versions précédentes de la spécification doivent être déconseillées ou retirées, y compris les raisons techniques de la ou des recommandations.

BARB sera réview l'analyse par le groupe de travail de la conformité de la spécification 0.9/CR aux exigences données dans le FRD, de tout problème de sécurité potentiel, de tout problème réglementaire, de la conformité avec l'architecture Bluetooth et, pour une amélioration de la spécification, de la conformité avec les exigences de compatibilité descendante décrites dans la section 3.3.2 .XNUMX. Si BARB identifie des problèmes de sécurité potentiels, BARB informera BSTS pourview et la coordination avec le Groupe d'experts en sécurité ; et si BARB identifie des implications réglementaires, BARB informera BSTS deview et coordonner avec le comité de réglementation et le conseiller juridique de Bluetooth SIG. BARB doit approuver ou rejeter la spécification 0.9/CR en fonction de son jugement technique et de la prise en compte des facteurs décrits dans ce paragraphe.

RTC sera réview les documents de test 0.9/CR prenant en compte l'analyse de couverture de test. BTI doit approuver ou rejeter les documents de test 0.9/CR.

Après que BARB a approuvé la spécification 0.9/CR, le groupe de travail soumet le plan de test IOP à BARB pour review.

La spécification 0.9 / CR approuvée par BARB est présentée au BoD pour approuver le début des tests de PIO et la publication de la spécification 0.9 / CR à tous les membres.

Pour mettre en évidence les problèmes juridiques potentiels, les groupes de travail peuvent demander une spécification review par le conseil juridique de Bluetooth SIG (review) avant le recours légal obligatoireview a lieu pendant la phase d'adoption/approbation. Cependant, pour les améliorations des spécifications, la review devrait être fait sur un CR intégré (par opposition à un CR abrégé) et cela devrait être préprogrammé aussi longtemps à l'avance que possible afin que les ressources soient disponibles.

Plan de test de la PIO

Le groupe de travail développera un plan de test IOP écrit qui doit satisfaire à toutes les exigences définies ci-dessous pour une utilisation pendant la phase de validation lors des événements de test IOP. Les groupes de travail doivent soumettre le plan de test IOP à BARB pour review avant le début des événements de test IOP. Pour les améliorations de spécifications simples (en particulier celles qui ne nécessitent pas de modification ou d'ajout de cas de test dans la suite de tests), les tests IOP peuvent ne pas être nécessaires, et le groupe de travail peut soumettre une demande à BARB pour une dérogation aux tests IOP en utilisant le processus défini dans la rubrique 4.4.

Le plan de test de la PIO doit inclure:

Scénarios de test pour vérifier toutes les nouvelles fonctionnalités obligatoires, facultatives et conditionnelles
Au moins un cas de test pour chaque code opération
Au moins un cas de test pour chaque paramètre
Au moins un cas de test pour chaque type de paquet
Cas de test de compatibilité descendante pour les améliorations de spécification afin que les exigences énumérées au paragraphe 3.3.2 soient satisfaites pour toutes les fonctionnalités améliorées (voir également la section 4.3.1.1).

Cas de test où l'IUT est exposé à des valeurs en dehors des plages définies ou à des aspects comportementaux considérés comme non valides ou inattendus (cas de test de comportement non valide). Notez que l'on s'attend à ce qu'un testeur tel que PTS ou un autre outil de test soit l'initiateur de tout comportement invalide.
Tout numéro attribué temporairement (sélectionné en coordination avec BSTS pour éviter tout chevauchement lors des prochains événements de test IOP) à utiliser lors de l'événement de test IOP, comme décrit au paragraphe 4.3.1.2.
Identification du nombre requis d'implémentations indépendantes qui doivent réussir chaque cas de test, en tenant compte des exigences de couverture décrites à la section 4.3.1.3

Identification de tous les cas de test dans la suite de tests qui, selon le groupe de travail, devraient être exclus et justification de leur exclusion. Celles-ci incluent généralement: • Les scénarios de test de vérification future (par exemple, des tests communs afin que d'éventuels ajouts futurs puissent être pris en compte, tels que des caractéristiques supplémentaires, des caractéristiques d'extension ou l'utilisation de bits ou de champs réservés pour une utilisation future (RFU))
• Cas de test qui sont un sous-ensemble d’autres tests inclus
• Scénarios de test génériques pratiquement identiques aux tests exécutés pour plusieurs autres spécifications (par exemple, déclenchement de codes d'erreur courants)
• Cas de test avec le même objectif de test que les cas de test qui s'exécutent sur un autre transport (par exemple, un cas de test BR / EDR qui est similaire à un cas de test LE)
• Robustesse ou test de résistance de la mise en œuvre

Le plan de test IOP peut également inclure des tests propres aux tests IOP, tels que des cas de test de bout en bout qui enchaînent des séquences plus complexes qui peuvent ressembler à un scénario utilisateur typique.

Bien que l'approbation du plan de test de la PIO par le BARB ne soit pas requise (étant entendu que le plan de test de la PIO continuera à être modifié et amélioré à chaque événement de test de la PIO), l'approbation par le BARB du rapport de test de la PIO est requise (voir la section 5.1.1) . Si un plan de test de PIO ne satisfait pas à toutes les exigences définies à la section 4.3.1, le groupe de travail doit présenter un résumé de toutes les variations connues et la justification de chaque variation par rapport à BARB avant le début des événements de test de la PIO.

Le plan de test IOP et les cas de test doivent être principalement basés sur le contenu des documents de test de la spécification associée.

Pour rendre les événements de test IOP efficaces, le groupe de travail doit avoir le plan de test IOP et tous les cas de test associés complétés et disponibles pour les implémenteurs idéalement au moins un mois avant le premier événement de test IOP.

Planification des tests de compatibilité descendante
Pour les améliorations des spécifications, les tests IOP de compatibilité descendante doivent envisager une vérification par rapport à toutes les versions actives et obsolètes de la spécification, car ces spécifications et fonctionnalités couramment trouvées dans les produits Bluetooth peuvent avoir une durée de vie très longue (par exemple, les véhicules). Le groupe de travail doit analyser le niveau approprié de test de compatibilité descendante nécessaire (le cas échéant), y compris les versions à tester et les tests à effectuer, et fournir cette analyse à BARB. BARB doit review l'analyse et recommander des changements (le cas échéant) pour le groupe de travail à intégrer dans le plan de test IOP.

Les membres participant aux tests de compatibilité descendante sont encouragés à apporter des appareils hérités qui ont été qualifiés par rapport aux versions précédentes des spécifications. Le groupe de travail doit signaler tout échec de compatibilité descendante dans le rapport de test IOP. Les sociétés membres sont également encouragées à effectuer des tests de compatibilité descendante dans leurs propres laboratoires en dehors du lieu de l'événement de test PIO et à signaler tout problème lié aux spécifications au groupe de travail.

Numéros attribués temporaires utilisés dans les tests de PIO
BSTS et BARB doivent être consultés pour coordonner l'attribution temporaire des numéros attribués qui seront utilisés lors de l'événement de test PIO afin qu'il n'y ait pas de chevauchements ou de conflits avec d'autres spécifications. Ces valeurs temporaires doivent être incluses dans le plan de test de la PIO et ne seront pas affectées à une utilisation par les spécifications adoptées.

Pour les tests IOP où une ou plusieurs nouvelles valeurs UUID 16 bits sont proposées, les valeurs comprises entre 0x7F00 et 0x7FFF sont réservées pour les tests IOP.

Pour les tests IOP où une ou plusieurs nouvelles valeurs PSM (Fixed Protocol Service Multiplexer) sont proposées, les valeurs commençant à la fin de la plage valide de 0x0000 à 0x007F, comme spécifié dans la spécification de base, seront utilisées.

Exigences de couverture
Le groupe de travail doit fournir la preuve à BARB que le nombre requis (tel que décrit dans les sections qui suivent) d'implémentations indépendantes a réussi chaque cas de test. Toute demande de WG pour des exceptions au nombre requis d'implémentations indépendantes doit être indiquée dans le plan de test IOP qui est soumis à BARB.

Les implémentations sont considérées comme indépendantes les unes des autres tant que toutes les parties pertinentes pour la validation ont été développées indépendamment, c'est-à-dire par des équipes différentes (qui ne proviennent pas nécessairement d'entreprises différentes). BSTS peut aider à évaluer si les prototypes peuvent être considérés comme indépendants les uns des autres afin de préserver l'anonymat et la confidentialité des détails de mise en œuvre.

Notez que les outils de test, y compris PTS, ne sont pas considérés comme des implémentations indépendantes.

Exigences de couverture de la spécification de base IOP
Une fonctionnalité de spécification de base définit généralement un ou plusieurs rôles où chaque rôle est conçu pour interagir avec un ou plusieurs autres rôles ou éventuellement avec lui-même.

Pour chaque paire de rôles qui sont conçus pour interagir les uns avec les autres, il doit être démontré qu'au moins trois implémentations indépendantes de chaque rôle interagissent avec trois implémentations indépendantes du rôle complémentaire.

Pour chaque rôle qui peut interagir avec un autre périphérique dans le même rôle, au moins trois implémentations indépendantes de ce rôle doivent démontrer qu'elles peuvent interagir les unes avec les autres dans ce rôle.

Spécifications de service Exigences de couverture IOP
Au moins trois implémentations de service indépendantes doivent démontrer qu'elles interagissent avec au moins une implémentation client, qui peut être PTS.

Profile et spécifications du protocole Exigences de couverture IOP
Profile et les spécifications de protocole définissent généralement un ou plusieurs rôles où chaque rôle est conçu pour interagir avec un ou plusieurs autres rôles, ou éventuellement avec lui-même.

Pour chaque paire de rôles conçus pour interagir les uns avec les autres, au moins deux implémentations indépendantes de chaque rôle doivent démontrer qu'elles interagissent avec deux implémentations indépendantes du rôle complémentaire.

Pour chaque rôle pouvant interagir avec un autre appareil dans le même rôle, au moins trois implémentations indépendantes de ce rôle doivent démontrer qu'elles interagissent les unes avec les autres dans ce rôle.

Spécification du modèle Exigences de couverture IOP
Au moins trois implémentations de modèle de serveur ou de modèle de contrôle indépendant doivent démontrer qu'elles interagissent avec au moins une implémentation de client (qui peut être PTS), et au moins une implémentation de modèle de client doit démontrer qu'elle interagit avec au moins une implémentation de modèle de serveur et PTS.

Numérotation des versions des spécifications

Pendant la 0.9/CR Stage, le GT doit préparer une recommandation à présenter au CA concernant le numéro de version à appliquer à la spécification une fois adoptée.

Les versions des spécifications se divisent en deux types: les versions complètes, qui incluent des fonctionnalités nouvelles ou mises à jour, et les versions de maintenance (également appelées «versions point-Z»), qui intègrent des errata techniques et éditoriaux, mais n'incluent pas les nouvelles ou mises à jour fonctionnalités. Les versions complètes ont des numéros en deux parties sous la forme de XY, tels que 2.1 ou 5.0, tandis que les versions de maintenance ont des numéros en trois parties sous la forme de XYZ, tels que 2.1.2. La valeur de Z ne peut pas être 0.

Pour deux versions quelconques, l'une est appelée «version supérieure» et l'autre est la «version inférieure». Ceci est déterminé selon les règles suivantes:

Si les composants X diffèrent, celui avec la valeur X la plus élevée est la «version supérieure».
Si les composants X sont identiques, mais que les composants Y diffèrent, celui avec la valeur Y la plus élevée est la «version supérieure».
Si les composants XY sont identiques, mais que les composants Z diffèrent, celui avec la valeur Z la plus élevée est la «version supérieure». Un numéro en deux parties XY est, à cet effet, traité comme un numéro en trois parties XY0.

Par exempleample, les numéros de version suivants seraient dans l'ordre de la version la plus basse à la version la plus élevée : 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Pour CSS, chaque mise à jour incrémente uniquement le composant X du numéro de version.

Conditions préalables à l'approbation du CA
À la fin de la phase de développement des spécifications, les exigences suivantes doivent être remplies avant qu'une spécification 0.9 / CR ne soit soumise au CA pour approbation:

Le groupe de travail a terminé l'analyse de la couverture des tests.
BSTS a terminé reviewing la spécification 0.9/CR et les documents de test.
BARB a approuvé la spécification 0.9 / CR.
BARB a approuvé le CSS CR (si de nouvelles entrées sont requises par la spécification) qui peut être intégré dans un CR abrégé de la spécification.
BARB a approuvé le GSS CR et MDP CR (si de nouvelles entrées sont requises par la spécification).
BTI a approuvé la suite de tests 0.9/CR, ICS et TCRL, ainsi qu'un IXIT (à condition que l'IXIT soit nécessaire pour effectuer les tests dans la suite de tests). Le TCRL est facultatif à ce stage pour les mises à jour de la spécification de base.
Le groupe de travail a soumis le plan de test IOP à BARB pour review (si le test n'est pas annulé par BARB).

Les documents présentés au CA doivent inclure la spécification 0.9 / CR approuvée par BARB et une présentation au CA qui doit inclure:

Toute demande connue de dérogation aux tests de PIO ou à l'une des exigences définies à la section 4.3.1
Une liste de transports pris en charge par la spécification (par exemple, BR / EDR, LE, etc.)
Pour une amélioration de la spécification, toute dérogation aux exigences de compatibilité descendante (décrites dans la section 3.3.2) qui est demandée par le groupe de travail
Pour une amélioration de la spécification, une recommandation du groupe de travail pour le numéro de version à appliquer à la spécification adoptée
Pour une amélioration de la spécification, la recommandation de fin de vie du groupe de travail pour la ou les versions précédentes de la spécification adoptée, y compris toutes les raisons techniques pour lesquelles la dépréciation ou le retrait de toute version précédente de la spécification est ou n'est pas recommandée, et la justification pour la recommandation
Toute préoccupation grave non résolue de la part des membres du BARB ou du BTI (par exemple, les raisons pour lesquelles aucun vote lors des approbations, les préoccupations résultant de la réview des documents de test, ou des préoccupations que la spécification 0.9/CR est en dehors du champ d'application de la FRD ou de la charte)
L'état de préparation du Profile Tuning Suite (PTS) ou d'autres outils nécessaires associés à l'adoption qui sont préparés par BSTS

Le CA peut choisir d'approuver la spécification 0.9 / CR pour les tests de PIO comme requis par les statuts [2], avant que BTI n'approuve les documents de test 0.9 / CR et avant que le groupe de travail ne confirme que le plan de test de PIO répond aux exigences définies dans la section 4.3.1. 0.9. Le CA peut également conditionner son approbation de la spécification 0.9 / CR pour les tests de PIO à l'approbation par BTI des documents de test XNUMX / CR.

0.9/RC Stage conditions de sortie
Le 0.9/CR Stage est terminé et la phase de validation commence lorsque le CA approuve le début des tests IOP.

4.4 Dérogations au processus d'élaboration des spécifications

Un groupe de travail peut demander de renoncer à une ou plusieurs des étapes de processus suivantes:

Le 0.5/DIPD Stage
Le 0.7/FIPD Stage
Test de la PIO pendant la phase de validation

Pour demander une dérogation, le groupe de travail doit utiliser le modèle de dérogation de processus fourni par Bluetooth SIG [8] et soumettre une demande de dérogation à chaque comité (c.view ou approuver le projet de spécification ou les documents de test associés au stage que le GT propose de déroger, et chacun de ces comités doit approuver la demande de dérogation.

Une demande de dérogation doit inclure les éléments suivants:

Une identification de la stage(s) auquel le GT souhaite renoncer
Une justification pourquoi le stage(s) doit être supprimé
Une identification de chaque comité (c'est-à-dire, BTI et/ou BARB) qui est requis pourview et approuver la demande de dérogation

Le comité qui examine la dérogation peut exiger qu'un représentant du groupe de travail fasse une présentation pour justifier la renonciation au processus SMPD avant de se prononcer sur la demande de dérogation.

Si une dérogation demande de renoncer à plusieurs étapes et qu'une partie de la renonciation est rejetée et qu'une partie est approuvée, la réponse du comité doit indiquer quelles étapes de la demande de dérogation ont été approuvées et lesquelles ont été rejetées. Si une demande de dérogation est rejetée, la notification de rejet doit inclure les raisons du rejet.

5. Phase de validation

Au cours de la phase de validation, le groupe de travail effectuera des tests IOP sur la spécification 0.9/CR dans le but de fournir un rapport de test IOP pour BARB review et approbation. Dans la mesure du possible, les tests IOP des améliorations des spécifications doivent être effectués par rapport au projet de spécification intégré. En outre, le membre Review, comme l'exigent les statuts [2], commence au cours de cette phase.

Si la spécification (ou l'amélioration) ne nécessite pas de test de PIO, alors le test de PIO au cours de la phase de validation peut être annulé en utilisant le processus décrit dans la section 4.4.

Tout au long des tests IOP (qui peuvent être un ou plusieurs événements), le groupe de travail doit suivre les problèmes à l'aide du système de suivi des problèmes de Bluetooth SIG et itérer pour incorporer les mises à jour de la spécification préliminaire, des documents de test et du plan de test IOP. Une fois les tests IOP terminés, le groupe de travail doit terminer les mises à jour du projet de spécification et des documents de test pour résoudre tous les problèmes, et préparer et soumettre un rapport de test IOP à BARB pour réexamen.view et approbation. Ceci est illustré à la figure 5.1.

Pendant la phase de validation, plusieurs activités peuvent commencer. Ces activités peuvent se dérouler en parallèle et inclure les éléments suivants:

La spécification 0.9/CR approuvée par le CA est mise à la disposition de tous les membres par BSTS avec notification du début du Member Review période requise par les statuts.
Toutes les mises à jour requises sont incorporées dans le CSS (qui peut être intégré dans un CR abrégé de la spécification).
Les définitions de caractéristiques ou de descripteurs sont incorporées dans la spécification GSS ainsi que dans le PTS pour les tests IOP.
Les définitions des propriétés de maillage sont incorporées dans la spécification MDP ainsi que dans le PTS pour les tests IOP.
BSTS permet l'enregistrement de la plate-forme IOP et l'outil de saisie des résultats en vue des tests de la PIO.
Test de la PIO, si nécessaire (voir section 5.1).
Review les commentaires et les problèmes, y compris ceux soumis à la suite des tests IOP, sont traités et les modifications sont incorporées dans le projet de spécification.

5.1 Test de la PIO

L'objectif principal des tests IOP est de valider la spécification par, par ex.ample, vérifiant l'exactitude et l'ambiguïté dans le texte, reviewpour toute erreur et omission de conception fondamentale, et fournir une validation par rapport aux exigences précédemment établies et développées plus tôt dans le processus d'élaboration des spécifications. Les tests IOP peuvent entraîner des modifications du projet de spécification et plusieurs événements de test IOP peuvent être nécessaires pour effectuer tous les tests requis.

Il est important de donner aux membres extérieurs au GT la possibilité de participer aux tests IOP car ils fournissent un view de la spécification et peut révéler des zones d'ambiguïté dans la spécification qui peuvent ne pas être évidentes pour les membres du groupe de travail qui ont développé le projet. Avant chaque événement de test IOP, BSTS mettra à disposition les détails de l'événement, le dernier projet de spécification, la suite de tests et le plan de test IOP et informera tous les membres idéalement un mois avant chaque événement. Le projet de spécification, la suite de tests et le plan de test IOP mis à jour utilisés lors d'un événement test IOP doivent être disponibles au moins une semaine avant chaque événement.

Pendant les tests de la PIO, des combinaisons de plates-formes par paires tenteront d'exécuter les tests et les participants aux tests de PIO enregistreront les résultats réussite / échec de chaque test et leurs commentaires. Un résumé anonyme de ces résultats (faisant référence par exemple à «Plateforme A», «Plateforme B», etc.) et tout commentaire, sera recueilli pendant les événements de test IOP et mis à la disposition des membres du WG pendant et après l'IOP. événement de test. Dans le cas où des informations supplémentaires sont nécessaires pour mieux comprendre les commentaires ou les échecs survenus pendant les tests de la PIO, BSTS peut agir en tant qu'intermédiaire pour recueillir des informations supplémentaires auprès du membre soumissionnaire.

Si possible, le PTS doit être mis à jour pour prendre en charge les tests IOP avec des plates-formes à toutes les couches au-dessus de l'interface contrôleur hôte (HCI), et être présent aux événements de test IOP pour ces couches. D'autres outils de test peuvent également être présents lors des événements de test de la PIO. Un résumé des résultats des tests avec PTS ou d'autres outils de test (le cas échéant) doit être inclus dans le rapport de test de la PIO.

Les tests PIO seront ouverts à tous les membres qui souhaitent fournir une implémentation prototype, cependant, Bluetooth SIG peut conditionner la participation à l'acceptation d'accords avec Bluetooth SIG (y compris les accords de participation et de confidentialité). Le groupe de travail est responsable du traitement et de la résolution des problèmes découverts lors des tests de PIO et de la mise à jour des documents concernés; Les modifications approuvées par le WG doivent être incorporées en tant que mises à jour du projet de spécification et des documents de test à utiliser à chaque événement de test PIO.

Avant la phase de validation, les groupes de travail peuvent effectuer des tests de PIO préliminaires lors d'événements qui ne sont ouverts qu'aux membres du groupe de travail, mais les résultats des tests informels peuvent ne pas être inclus dans les résultats des tests de PIO.

Il peut arriver que toutes les étapes menant au premier événement de test PIO soient suivies, y compris une date et un lieu de PIO annoncés avec l'intention de commencer le test de PIO, mais l'approbation du BoD n'avait pas été obtenue avant le début de l'événement de test. Dans ce cas, le CA peut autoriser l'inclusion des résultats de tests qui ont été collectés avant l'approbation du CA pour commencer les tests de PIO, à condition que les résultats collectés soient basés sur la même spécification et que la suite de tests soit approuvée par le CA.

Le test de la PIO n'est pas requis pour les améliorations des spécifications CSS, GSS ou MDP.

Rapport de test PIO
Une fois les tests IOP terminés, le groupe de travail doit soumettre le rapport de test IOP à BARB dans le but de démontrer que le nombre requis de plates-formes indépendantes a réussi les tests requis. BARB doit review et approuver ou rejeter le rapport de test IOP et informera le groupe de travail si des tests IOP supplémentaires sont nécessaires avant de soumettre l'ensemble de spécifications du projet de vote au CA. Le BSTS et le groupe de travail doivent s'assurer qu'aucune information d'identification des membres n'apparaît dans le rapport de test IOP avant de soumettre le rapport à BARB.

Le rapport de test de la PIO doit inclure:

Une liste de tous les événements de test IOP qui se sont produits pendant la phase de validation, y compris leurs dates et emplacements.
Le nombre de sociétés membres et de plates-formes indépendantes qui ont participé à chaque événement IOP, y compris si PTS a été utilisé.
Une liste des versions de la spécification, de la suite de tests et du plan de test IOP utilisées à chaque événement.
Un résumé analytique indiquant si tous les cas de test répondaient aux critères de réussite minimum.
Un résumé de tout écart par rapport aux exigences du plan de test PIO définies à la section 4.3.1 et la justification de chaque écart.
Un résumé de la couverture PTS pour les cas de test dans la suite de tests.
Une liste de tous les cas de test (y compris les tests de compatibilité descendante) du plan de test IOP, le nombre de tests réussis, le nombre d'échecs de test et si les critères minimum ont été satisfaits par cas de test, y compris une explication des raisons pour lesquelles certaines exigences n'étaient pas rencontré.
Un résumé des problèmes, des commentaires et des questions à chaque événement (y compris ceux filed par rapport à la spécification pendant les tests IOP) et l'impact sur la spécification et les documents de test.

5.2 Exigences de sortie de la phase de validation

La phase de validation est terminée et la phase d'approbation / adoption commence lorsque BARB a approuvé le rapport de test PIO (sauf si les tests ont été annulés par BARB) et que toutes les exigences suivantes ont été remplies:

BSTS a mis la spécification 0.9/CR approuvée à la disposition de tous les membres pour Member Review tel que requis par les statuts et avisé tous les membres de sa disponibilité.
Tous les problèmes qui ont été identifiés lors des tests de PIO et qui ont un impact sur les tests ont été intégrés et testés.
WG a terminé le test de la PIO (à moins que le test n'ait été annulé par BARB).

6. Phase d'adoption / d'approbation

Au cours de la phase d'adoption/d'approbation, la spécification et les documents de test associés sont finalisés, l'approbation BARB, BQRB et BTI est reçue, un avis de la date d'adoption proposée est émis avec la version finale du projet de spécification soumis au CA pour adoption ( Vote Draft) et le cahier des charges final est soumis au CA. Après la durée minimale de Member Review requis par les statuts [2]) a été satisfaite, le CA examinera la spécification pour adoption à la date d'adoption. Après adoption, la spécification est publiée et le système de qualification est activé. La phase d'adoption/approbation est illustrée à la figure 6.1.

6.1 Ébauche de vote

L'ébauche de vote est créée en incorporant des mises à jour (fournies dans la phase de validation) dans les documents de spécification requis et en préparant une ébauche finale de la nouvelle spécification. Pour les améliorations de spécification, BSTS créera la spécification intégrée en intégrant un ou plusieurs CR dans la version supérieure précédemment adoptée de la spécification (voir la section 4.3.2) si elle n'est pas déjà terminée avant la phase de validation.

Si des modifications sont apportées à la spécification au cours de cette phase et que le WG, BARB ou BTI détermine que tout changement nécessite des tests de PIO supplémentaires, la spécification retournera à la partie de test de PIO de la phase de validation pour que le groupe de travail effectue les tests supplémentaires. Au cours de la phase d'adoption / d'approbation, les documents suivants seront complétés et mis à la disposition du CA avant la date d'adoption:

Le projet de vote
Toutes les spécifications de support (c.-à-d. CSS, GSS, MDP) requises pour le type de spécification (ou d'amélioration) pertinent, si elles n'ont pas été précédemment adoptées
Pour les améliorations de spécification, une version avec suivi des modifications de la version de spécification adoptée montrant les modifications proposées dans l'ébauche de vote
Une description par le groupe de travail de toutes les exigences de compatibilité descendante (telles que décrites dans la section 3.3.2) qui n'ont pas été satisfaites et la justification de toute dérogation
Une description du groupe de travail de toutes les exigences du plan de test IOP (telles que décrites dans la section 4.3.1) qui n'ont pas été respectées et la justification de tout écart ainsi que le rapport de test IOP (qui peut être fourni en fournissant un lien vers une copie sur le Bluetooth SIG webet données clients liées)
Une recommandation du groupe de travail pour la dépréciation ou le retrait de toute version précédente de la spécification adoptée avec une justification, mettant en évidence les changements depuis la 0.9/CR Stage recommandation de fin de vie
Un résumé, préparé par le groupe de travail, des modifications apportées aux caractéristiques ou fonctionnalités depuis la spécification 0.9 / CR (le cas échéant)
Un résumé, préparé par le BARB, des préoccupations soulevées par les membres du BARB selon lesquelles la spécification produite par le groupe de travail dépasse le champ d'application de la charte approuvée par le CA (le cas échéant)
Une liste des questions juridiques non résolues restantes de review (le cas échéant)
La suite de tests approuvée par le BTI, ainsi que le résumé approuvé par le WG de la couverture des tests de la spécification du projet de vote. En cas de fonctionnalité nouvellement ajoutée ou modifiée sans couverture de test, une justification écrite de l'omission est requise
Les ICS et IXIT approuvés par BTI (si requis par la spécification)
Le TCRL approuvé à la fois par BTI et BQRB
Un rapport préparé par BSTS avec BTI concernant l'état de préparation des outils (par exemple, PTS et autres outils de test, Bluetooth Launch Studio), y compris si des cas de test dans le TCRL ne sont pas pris en charge par les outils de test
Un résumé, préparé par le groupe de travail, de tous les numéros attribués nécessaires
Une liste de contrôle d'adoption préparée par BSTS et le groupe de travail montrant que tous les livrables de cette section ont tous été achevés
Toutes les autres informations demandées par le CA

Pendant la phase d'adoption / d'approbation, le groupe de travail doit utiliser le système de suivi des problèmes de Bluetooth SIG pour capturer les problèmes et les commentaires par rapport au projet de spécification et aux documents de test afin qu'ils soient pris en compte dans la finalisation du projet de spécification de vote. Pour une amélioration de la spécification, tous les errata approuvés pertinents (c'est-à-dire les errata approuvés non encore intégrés) doivent être incorporés et doivent être identifiés à l'aide des modifications suivies.

Le groupe de travail doit soumettre le projet de spécification final au BSTS pour examen juridiqueview. Pour les nouvelles spécifications, la review comprendra l'ensemble des spécifications. Pour les améliorations de spécifications, le review se concentrera principalement sur les parties modifiées de la spécification. L'objet de la review est principalement d'identifier les risques juridiques que le groupe de travail devrait considérer et chercher à résoudre. Les commentaires juridiques seront classés en fonction de la gravité. Si une option juridique review a été réalisée au 0.9/CR Stage, la version qui est soumise pour review doit montrer, en tant que modifications suivies, toutes les modifications apportées depuis cette version (générées par le groupe de travail ou le BSTS). À l'issue de la re juridiqueview, le groupe de travail et le BSTS se mettront d'accord sur les commentaires à intégrer dans le projet de spécification. S'il y a des commentaires juridiques non résolus de legal review sur le projet de spécification, le président du GT peut demander du temps sur l'ordre du jour du CA pour convenir d'une résolution.

Parallèlement à la review, le GT doit soumettre le projet de spécification à BARB pour review. Lors de la soumission initiale à BARB, BSTS informera tous les membres que le projet de spécification a été soumis à BARB pour réexamen.view et qu'il est également disponible pour Member Review. Si le groupe de travail soumet des mises à jour du projet de spécification pour BARB re-review, BSTS enverra périodiquement des notifications supplémentaires à tous les membres.

À la fin de BARB review, le GT et le BARB se mettront d'accord sur les commentaires à intégrer dans le projet de spécification.

Si le review entraîne des changements substantiels, des modifications supplémentairesview par BARB peut être requis. De même, si le BARB review entraîne des changements substantiels, BSTS déterminera si une relégation juridique supplémentaireview de ces changements est nécessaire. À l'issue de la re juridiqueview et BARB review, BARB doit approuver ou rejeter le projet de vote.

Si des documents de test nécessitent une mise à jour, BSTS aidera le groupe de travail à mettre à jour les documents de test. BTI doit approuver ou rejeter les documents de test. S'il est approuvé par BTI, BTI aidera à finaliser le TCRL et fournira ce document au BQRB avec l'ICS, l'IXIT et la suite de tests associés. BSTS estimera la date de la réunion du CA à laquelle le CA a l'intention de voter sur l'adoption du projet de vote (date d'adoption) et le fournira des RTC à utiliser dans le TCRL. L'approbation de la spécification par le BARB, l'approbation BTI de tous les documents de test (y compris la suite de tests, TCRL, ICS et IXIT) et l'approbation par le BQRB du TCRL doivent avoir lieu au plus tard à la date d'adoption.

BSTS informera tous les membres de la finalisation et de la disponibilité du projet de vote et de la date d'adoption. La date d'adoption sera fixée au plus tôt 60 jours après que les membres ont été informés de la spécification 0.9/CR approuvée par le CA, à moins que le membreview la période est raccourcie par le CA conformément aux statuts, et au moins 14 jours après la notification de la date d'adoption aux membres conformément aux statuts. Pour les cas où plusieurs CR ont été intégrés dans un projet de vote, le début de Member Review est la date à laquelle les membres ont été informés du plus récent CR approuvé par le CA.

Après notification de la date d'adoption aux membres, les corrections approuvées par le CA aux erreurs typographiques dans l'ébauche de vote sont autorisées. La chronologie de l'adoption des spécifications est illustrée à la figure 6.2.

6.2 Numéros attribués

Bluetooth SIG maintient un ensemble de numéros attribués accessible au public sur les numéros attribués Bluetooth SIG website [7]. Ces numéros attribués sont regroupés dans divers espaces numériques (un ensemble de numéros liés sans doublons). Les numéros attribués peuvent chevaucher d'autres numéros attribués dans différents espaces numériques, mais aucun numéro dans un espace numérique ne peut être réutilisé. Les différents espaces numériques sont définis dans la spécification qui définit l'utilisation des numéros attribués.

Une fois que BARB aura approuvé le rapport de test IOP, le groupe de travail soumettra une demande à BARB pour l'attribution de nouveaux numéros dans les espaces de numéros requis par la spécification finale. BARB sera réview la demande et travailler avec BSTS pour déterminer les numéros attribués. Après approbation du BARB, BSTS programmera la publication des numéros attribués pour qu'ils soient rendus publics sur les numéros attribués Bluetooth SIG. website [7] dans la semaine suivant l'adoption du cahier des charges.

Une fois la publication des numéros attribués sur le Bluetooth SIG Assigned Numbers website ou dans une spécification adoptée se produit, les numéros attribués sont destinés à être immuables (pour ne pas changer de valeur ou de signification). S'ils deviennent inutilisables pour une raison quelconque, ils deviennent des valeurs réservées et ne peuvent pas être réutilisés.

6.3 Exigences de sortie de la phase d'adoption / d'approbation

La phase d'approbation / d'adoption est terminée lorsque le CA a adopté la spécification et que les activités post-adoption suivantes sont terminées:

BSTS a rendu les derniers numéros attribués publiquement disponibles sur le Bluetooth SIG website.
BSTS a rendu la spécification adoptée publiquement disponible sur le Bluetooth SIG website
BSTS a rendu tous les documents justificatifs (par exemple, CSS, GSS, MDP) requis pour la spécification pertinente accessibles au public sur le Bluetooth SIG website.
BSTS a mis les documents de test associés à la disposition de tous les membres sur le Bluetooth SIG website.
Pour les améliorations des spécifications, BSTS a créé une version informative avec suivi des modifications de la version de spécification précédemment adoptée avec toutes les modifications apportées par la version nouvellement adoptée et l'a mise à la disposition de tous les membres sur le Bluetooth SIG. website.
BSTS a activé le système de qualification.
BSTS a informé tous les membres de la disponibilité de la spécification adoptée et de tous les documents justificatifs.

Le Bluetooth SIG prévoit d'achever ces activités post-adoption dans la semaine suivant l'adoption de la spécification.

7. Phase de maintenance des spécifications

La phase de mise à jour des spécifications commence une fois la phase d'adoption / d'approbation terminée. Si des problèmes sont détectés (par exemple, des ambiguïtés de formulation ou des erreurs techniques) avec la spécification ou les documents de test associés, ils doivent être documentés en créant des propositions d'errata à l'aide de l'outil Bluetooth SIG Errata. Les propositions d'erratum de spécification seront traitées, catégorisées et approuvées conformément à l'EPD [3]. Les erratums de la suite de tests sont traités et classés selon le TSTO [5]. En cas de conflit entre le SMPD et l'EPD ou le TSTO, le SMPD a la priorité.

L'erratum de spécification ne doit être utilisé que pour corriger des erreurs techniques ou éditoriales dans les spécifications Bluetooth finales adoptées. L'ajout, les modifications et la suppression de fonctionnalités ne peuvent être effectués qu'au moyen du processus d'amélioration des spécifications défini précédemment dans ce document.

7.1 Processus d'erratum accéléré

Lorsqu'un erratum est approuvé à la suite du processus défini dans l'EPD [3], le GT, le BARB ou le BSTS peuvent recommander qu'il soit considéré comme urgent et qu'il soit accéléré. Lorsque cela se produit, le BSTS ainsi que le GT ou le BARB présenteront la recommandation au CA. Le CA décidera d'accepter ou de rejeter la recommandation. Si la recommandation est acceptée, le BSTS incorporera immédiatement l'erratum approuvé dans le modèle d'erratum [8] et travaillera avec le groupe de travail responsable pour finaliser une correction d'errata accélérée à soumettre au groupe de travail pour réexamen.view et approbation.

Un plusview du processus d'erratum accéléré est illustré à la figure 7.1.

Les documents suivants doivent être remplis et mis à la disposition du CA avant la date d'adoption:

Le projet de correction d'errata accélérée approuvée par le BARB.
Une description du groupe de travail de toutes les exigences de compatibilité ascendante (telles que décrites dans la section 3.3.2) qui n'ont pas été satisfaites et la justification de toute dérogation.
Une liste des questions juridiques non résolues restantes de review (le cas échéant).
La suite de tests approuvée par BTI, ICS et IXIT (si requis par l'erratum).
Le TCRL approuvé BTI et BQRB (si requis par l'erratum).
Un rapport complété par BSTS avec BTI concernant l'état de préparation de l'outil (par exemple, PTS et autres outils de test, Bluetooth Launch Studio), y compris si des cas de test dans le TCRL ne sont pas pris en charge par les outils de test et une explication (si requis par l'erratum ).
Une liste de contrôle d'adoption remplie par BSTS et le groupe de travail montrant que les livrables de cette section ont tous été achevés.
Toutes les autres informations demandées par le CA.

BSTS travaillera avec le groupe de travail responsable pour finaliser le projet de correction accélérée des errata et créer une version à soumettre au groupe de travail responsable pour réexamen.view et approbation.

Le groupe de travail doit soumettre la correction d'errata accélérée au BSTS pour examen juridiqueview. À l'issue de la re juridiqueview, le groupe de travail et le BSTS se mettront d'accord sur les commentaires à intégrer dans la correction accélérée des errata. S'il y a des commentaires juridiques non résolus de legal review sur la correction accélérée des errata, le président du groupe de travail peut demander du temps à l'ordre du jour du conseil d'administration pour solliciter l'avis du conseil d'administration sur la résolution.

Parallèlement à la review, le groupe de travail doit soumettre la correction d'errata accélérée à BARB pour réexamenview. Une fois la correction d'errata accélérée soumise à BARB, BSTS la rendra accessible à tous les membres pourview et aviser tous les membres de sa disponibilité. À la fin de BARB review, le GT et le BARB se mettront d'accord sur les commentaires à intégrer dans la correction accélérée des errata.

Si des documents de test nécessitent une mise à jour, BSTS aidera le groupe de travail à mettre à jour les documents de test. Après l'approbation par BTI des documents de test, BTI aidera à finaliser le TCRL et remettra le document au BQRB avec l'ICS, l'IXIT et la suite de tests associés, le cas échéant. BSTS estimera la date d'adoption et la fournira à BTI pour une utilisation dans le TCRL. L'approbation par le BARB de la correction accélérée d'errata, l'approbation BTI de tous les documents de test (y compris la suite de tests, TCRL, ICS et IXIT le cas échéant) et l'approbation par le BQRB du TCRL doivent avoir lieu au plus tard à la date d'adoption.

BSTS informera tous les membres de la finalisation et de la disponibilité de la correction d'errata accélérée et de la date d'adoption proposée. La date d'adoption sera fixée et notifiée à tous les membres conformément aux statuts [2] et la date d'adoption sera d'au moins 14 jours après la notification aux membres. Après notification de la date d'adoption proposée aux membres, le CA peut approuver les corrections d'erreurs typographiques dans la correction accélérée des errata sans fournir un avis supplémentaire de la date d'adoption proposée et attendre les 14 jours requis.

Bluetooth SIG rendra accessible au public la correction accélérée d'errata adoptée et prévoit de le faire dans la semaine suivant son adoption. Une notification de sa disponibilité sera émise par BSTS à tous les membres.

Le processus d'erratum accéléré est terminé lorsque le CA a adopté la correction d'errata accélérée et que les activités post-adoption suivantes sont terminées:

BSTS a mis la correction d'errata accélérée adoptée et les documents de test associés (si requis par l'erratum) à la disposition du public sur le Bluetooth SIG website.
BSTS a activé le système de qualification (si requis par l'erratum).
BSTS a informé tous les membres de la disponibilité de la correction d'errata accélérée adoptée.

À la fin de ces activités, la correction d'errata sera programmée pour être intégrée dans les spécifications concernées, soit dans le cadre d'une amélioration prévue des spécifications, soit dans une prochaine version de maintenance comme décrit à la section 7.2.

7.2 Processus de validation de maintenance (spécifications .Z)

Sur une base approximativement annuelle, BSTS déterminera s'il existe des errata approuvés (appelés corrections d'errata) qui sont classés comme techniques / élevés ou techniques / critiques et qui n'ont pas encore été incorporés dans le texte de toute spécification active (c.-à-d. une spécification adoptée qui n'a pas été déconseillée ou retirée). Voir l'annexe A pour les définitions de classification des errata. Un propriétaire de spécification (soit le groupe de travail agréé pour maintenir la spécification, soit BARB si aucun groupe de travail n'est agréé pour maintenir la spécification) peut également demander une version de maintenance antérieure d'une spécification active dans laquelle incorporer tout errata approuvé. Sur décision du BSTS ou à la demande du propriétaire de la spécification, le processus de certification après maintenance commencera.

Un plusview du processus de mise à jour après maintenance est illustré dans Error! Source de référence introuvable.

Au début du processus de mise à jour de maintenance, BSTS, en collaboration avec le propriétaire de la spécification, BARB et BTI, développera et présentera un plan au CA pour incorporer les corrections d'errata dans la version de spécification publiée. Le plan proposé doit indiquer si les corrections d'errata seront incorporées dans une version de maintenance de la spécification (c.-à-d. Une version .Z) ou une amélioration de la spécification qui est déjà en cours (c.-à-d. Une version XY). Le plan proposé devrait tenir compte du fait que de nouvelles fonctionnalités obligatoires ont été ajoutées entre les versions des spécifications adoptées, du moment estimé pour l'adoption de la prochaine amélioration de la spécification et d'autres facteurs.

Après l'approbation d'un plan par le CA, BSTS, en collaboration avec le propriétaire de la spécification, procédera à l'incorporation de toutes les corrections d'errata techniques / moyennes, techniques / élevées et techniques / critiques dans un projet de spécification appelé «ébauche de version de maintenance». Pour les corrections d'errata rédactionnelles ou techniques / faibles, si la correction d'errata s'applique à plus d'une version de la spécification, BSTS, sauf indication contraire du CA, intégrera ces errata uniquement dans la version de spécification supérieure la plus récente lors de la prochaine mise à jour de cette version. . Aucune modification ne peut être incluse dans une version de maintenance provisoire autre que l'incorporation de corrections d'errata. Chaque version de la version de maintenance doit identifier toutes les corrections d'errata incorporées à l'aide du suivi des modifications pour montrer les modifications proposées à la version précédemment adoptée de la spécification publiée.

Le moment de l'incorporation proposée pour chaque correction d'errata dans un brouillon de version de maintenance dépendra de l'impact de la suite de tests: toutes les corrections d'errata qui n'ont pas d'impact sur la suite de tests peuvent être incorporées immédiatement, mais les corrections d'errata qui ont un impact sur la suite de tests le seront traité de manière à ce que la synchronisation coïncide avec une mise à jour du TCRL.

BTI et BSTS établiront une date limite pour l'inclusion des corrections d'errata ayant un impact sur la suite de tests dans un projet de version de maintenance. Ce délai est généralement de 3 à 6 mois avant la date d'approbation prévue de la prochaine version majeure de TCRL. Les corrections d'errata ayant un impact sur la suite de tests qui ne respectent pas la date limite d'inclusion seront traitées dans le cadre de la prochaine version annuelle de TCRL. Par conséquent, à moins qu'une version antérieure ne soit demandée, le délai maximum pour les corrections d'errata techniques / élevées ou techniques / critiques à inclure dans une mise à jour des spécifications est d'environ 15 à 18 mois.

Le propriétaire de la spécification doit soumettre l'ébauche de version après maintenance qu'il a approuvée comme finale pour révision juridique.view. Le review se concentrera principalement sur les parties modifiées de la spécification. À l'issue de la re juridiqueview, le propriétaire de la spécification et le BSTS se mettront d'accord sur les commentaires à intégrer dans le projet de version de maintenance. S'il y a des commentaires juridiques non résolus de legal review sur l'ébauche de la version de maintenance, le propriétaire de la spécification peut demander du temps à l'ordre du jour du conseil d'administration pour solliciter l'avis du conseil d'administration sur la résolution.

Parallèlement à la review, le propriétaire de la spécification doit soumettre l'ébauche de la version de maintenance à BARB pour review. Une fois que le projet de version de maintenance est soumis à BARB, BSTS le rendra accessible à tous les membres pourview et aviser tous les membres de sa disponibilité. À la fin de BARB review, le propriétaire de la spécification et BARB conviendront des commentaires à intégrer dans le projet de spécification.

Pour les corrections d'errata qui ont un impact sur les documents de test, et lorsque les errata de test correspondants seront traités à temps pour la prochaine version de TCRL, BSTS travaillera avec le propriétaire de la spécification et BTI pour mettre à jour les documents de test. Une fois que BTI a approuvé les documents de test, BSTS estimera la date d'adoption et fournira la date d'adoption proposée à BTI pour une utilisation dans le TCRL. BTI fournira le TCRL au BQRB ainsi que l'ICS, l'IXIT et la suite de tests associés, le cas échéant. L'approbation de la spécification par le BARB, l'approbation BTI de tous les documents de test (y compris la suite de tests, TCRL, ICS et IXIT le cas échéant) et l'approbation par le BQRB du TCRL doivent avoir lieu au plus tard à la date d'adoption.

BSTS informera tous les membres de la finalisation et de la disponibilité du projet de vote et de la date d'adoption proposée. La date d'adoption sera fixée et notifiée à tous les membres conformément aux statuts et la date d'adoption sera d'au moins 14 jours après la notification de l'avis aux membres. Après notification de la date d'adoption proposée aux membres, le CA peut approuver les corrections d'erreurs typographiques dans l'ébauche de vote sans fournir un avis supplémentaire de la date d'adoption proposée et attendre les 14 jours requis.

Les documents suivants doivent être remplis et mis à la disposition du CA avant la date d'adoption:

Le projet de vote
Une version avec suivi des modifications de l'ébauche de vote montrant toutes les modifications apportées à la version adoptée de la spécification qui a la même valeur XY (par exemple, si l'ébauche de vote est proposée en tant que version 1.4.2, les modifications seront suivies par rapport à la 1.4.1 version de la spécification)
Une recommandation du propriétaire de la spécification pour l'abandon ou le retrait de toute (s) version (s) précédente (s) de la spécification adoptée avec une justification
Une liste des questions juridiques non résolues restantes de review (le cas échéant)
La suite de tests approuvée par BTI, ICS et IXIT (si requis par la version de maintenance)
Le TCRL approuvé BTI et BQRB (si requis par la certification après maintenance)
Un rapport complété par BSTS avec BTI concernant l'état de préparation de l'outil (par exemple, PTS et autres outils de test, Bluetooth Launch Studio), y compris tous les cas de test dans le TCRL qui ne sont pas pris en charge par les outils de test, et une explication (si nécessaire par la maintenance Libération)
Une liste de contrôle d'adoption remplie par BSTS et le propriétaire de la spécification montrant que les livrables de cette section ont tous été achevés
Toutes les autres informations demandées par le CA

Le processus de mise à jour après maintenance est terminé lorsque le CA a adopté l'ébauche de vote et que les activités post-adoption suivantes ont été achevées:

BSTS a mis la spécification adoptée et les documents de test associés (si requis par la version de maintenance) à la disposition du public sur le Bluetooth SIG website.
BSTS a mis à disposition de tous les membres sur le Bluetooth SIG une version informative avec suivi des modifications de la version de spécification précédemment adoptée avec toutes les modifications incorporées dans la version nouvellement adoptée. website.
BSTS a activé le système de qualification.
BSTS a informé tous les membres de la disponibilité de la spécification adoptée et des pièces justificatives.

Le Bluetooth SIG prévoit d'achever ces activités post-adoption dans la semaine suivant l'adoption de la spécification.

À la fin de ces activités, la spécification reste dans la phase de maintenance des spécifications jusqu'à ce que la spécification soit déconseillée ou retirée, comme défini dans la section 8.

8. Phase de fin de vie des spécifications

Les spécifications peuvent être obsolètes ou retirées lorsqu'elles sont remplacées par des versions plus récentes, jugées techniquement insuffisantes ou pour d'autres raisons. Les spécifications obsolètes et retirées sont archivées et ne sont plus mises à jour. Les spécifications obsolètes et retirées sont traitées différemment dans le programme de qualification Bluetooth.

Tout membre, groupe ou comité peut soumettre des recommandations pour désapprouver ou retirer une spécification avec un calendrier associé à BSTS (par e-mail à

spécification.manager@bluetooth.com) à tout moment. BSTS peut également recommander l'abandon ou le retrait d'une spécification et du calendrier associé. BSTS renverra la recommandation au BARB et au groupe ou au comité responsable du maintien de la spécification pour review et commentaires.

BARB et le groupe ou comité responsable évalueront les recommandations visant à déconseiller ou retirer une spécification et considéreront les critères (non exhaustifs) suivants:

Y a-t-il des fonctionnalités dans une version précédente de la spécification qui sont obsolètes ou ne devraient pas être utilisées?
Une nouvelle fonctionnalité obligatoire a-t-elle été ajoutée aux versions ultérieures?
Y a-t-il des lacunes dans les versions antérieures qui nuisent au fonctionnement ou à l'interopérabilité qui ont été corrigées dans les versions ultérieures et sont nécessaires pour faire progresser les scénarios utilisateur existants?
Des fonctionnalités supplémentaires sont-elles nécessaires dans les versions ultérieures pour faire progresser de nouveaux scénarios utilisateur?
Y a-t-il une meilleure convivialité et interopérabilité dans les versions ultérieures?
Y a-t-il des améliorations de sécurité dans les versions ultérieures?

BARB et le groupe ou la commission responsable peuvent proposer une recommandation alternative.

Après avoir reçu les commentaires de BARB ou du groupe ou du comité responsable du maintien de la spécification, BSTS soumettra les recommandations et les commentaires au CA pour examen. Le CA peut inviter le groupe ou le comité responsable du maintien des spécifications concernées à se réunir et à discuter des recommandations. Le CA examinera les recommandations et les commentaires et pourra accepter ou modifier la proposition. Le conseil d'administration demandera à BSTS d'informer tous les membres des propositions de désapprobation ou de retrait des spécifications et des délais associés pour une période de 30 jours.view période pour permettre à tous les membres de fournir des commentaires supplémentaires avant de prendre sa décision finale.

Le CA prendra en considération les commentaires reçus des membres. Une fois que le CA approuve la dépréciation ou le retrait d'une spécification, BSTS informera tous les membres de la décision et du calendrier associé.

8.1 Dépréciation

Une fois qu'une spécification est obsolète, les événements suivants se produisent:

La spécification ne sera plus mise à jour.
Le GT responsable sera review tous les errata en suspens écrits par rapport à la spécification obsolète pour déterminer s'ils s'appliquent à d'autres spécifications. Les errata peuvent être rejetés dans le système d'errata et réécrits en fonction des spécifications applicables.
Le WG ou le BSTS créera des errata pour mettre à jour toutes les références nécessaires aux spécifications obsolètes dans d'autres spécifications.
BTI mettra à jour les documents de test applicables pour indiquer la dépréciation de la spécification.
BSTS mettra à jour le Bluetooth SIG website avec des conseils concernant les spécifications alternatives à utiliser.
Les nouveaux errata ne peuvent plus être soumis à une spécification obsolète.
La spécification ne sera référencée dans aucune spécification future.
BSTS archivera une version de la spécification marquée comme obsolète pour que les membres puissent y accéder à des fins historiques.

8.2 Rétractation

Une fois qu'une spécification est retirée, en plus des étapes qui s'appliquent à la dépréciation, ce qui suit se produit:

BTI mettra à jour les documents d'essai applicables pour indiquer le retrait de la spécification.
BSTS mettra à jour le Bluetooth SIG website avec des conseils concernant les spécifications alternatives à utiliser.
BSTS archivera une version de la spécification marquée comme retirée pour que les membres puissent y accéder à des fins historiques.

Le BoD peut choisir de retirer une spécification immédiatement sans d'abord désapprouver la spécification.

9. Processus du livre blanc

Les livres blancs sont créés à des fins d'information uniquement. Le processus de livre blanc suivant s'applique à tous les GT, EG, SG et comités Bluetooth. Cette section ne s'applique pas aux documents d'information à utiliser uniquement dans le Bluetooth SIG.

Ce processus est illustré dans la figure 9.1 ci-dessous.

Avant qu'un groupe ou comité ne commence à travailler sur un livre blanc qu'il a l'intention de publier par Bluetooth SIG, le groupe ou comité préparera à la fois une proposition de mise à jour de la charte définissant clairement le contenu proposé du livre blanc et une présentation de la proposition de livre blanc.

La présentation de la proposition de livre blanc doit inclure au minimum:

La nécessité du livre blanc
Un résumé du contenu proposé du livre blanc
Une explication des raisons pour lesquelles il n'est pas recommandé d'inclure le contenu dans une spécification
Le public visé
Tous les plans de maintenance (c'est-à-dire, le temps estimé avant la prochaine version de ce livre blanc peut être nécessaire)
Recommandations sur la façon de gérer les versions précédentes du livre blanc, le cas échéant (par exemple, archivage)

La mise à jour de la charte et la présentation de la proposition de livre blanc doivent être soumises pour BARB review. Sur review et l'approbation de la mise à jour de la charte par BARB, BSTS soumettra la mise à jour de la charte au CA pour approbation avec la présentation de la proposition de livre blanc à l'appui.

Si le CA approuve la mise à jour de la charte, le groupe ou le comité peut procéder à l'élaboration du livre blanc.

Lorsque le groupe ou le comité a terminé l'élaboration du livre blanc, BSTS effectuera une re rédactionview pour assurer la cohérence avec les directives de rédaction Bluetooth.

Après résolution des commentaires du BSTS, le groupe doit soumettre le livre blanc au BSTS pour examen juridique.view. À l'issue de la re juridiqueview, le groupe et BSTS se mettront d'accord sur les commentaires à intégrer dans le livre blanc. S'il y a des commentaires juridiques non résolus de legal review sur le livre blanc, le président du groupe peut demander du temps sur l'ordre du jour du conseil d'administration pour solliciter l'avis du conseil d'administration sur la résolution.

Parallèlement à la review, le groupe doit soumettre le livre blanc à BARB pour review. Dans le cadre de leur review, BARB peut recommander si une partie du livre blanc doit être retirée du livre blanc et incorporée dans une spécification suivant le processus de la section 3. BARB peut également décider de soumettre le livre blanc à d'autres groupes ou comités pour réexamenview. À la fin de BARB review, le groupe et BARB se mettront d'accord sur les retours à intégrer dans le livre blanc.

Une fois que le BARB a approuvé le livre blanc, le livre blanc approuvé par le BARB sera présenté par le groupe ou comité de rédaction au CA pour approbation.

Le processus du livre blanc est terminé lorsque le CA a approuvé le livre blanc et que les activités post-approbation suivantes ont été achevées:

BSTS a rendu public le livre blanc approuvé sur le Bluetooth SIG website.
BSTS informe tous les membres du livre blanc approuvé.
Si le livre blanc est une amélioration d'un livre blanc existant, BSTS archivera une version du livre blanc pour que les membres puissent y accéder à des fins historiques.

Le Bluetooth SIG prévoit d'achever les activités post-approbation dans un délai d'une semaine après l'approbation du livre blanc.

10. Références

Les documents Bluetooth référencés sont disponibles sur le Bluetooth website http://www.bluetooth.com.

Directives de rédaction Bluetooth (disponibles sur la page Modèles et documents du groupe de travail, à l'adresse https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Statuts de Bluetooth SIG, Inc. (disponibles sur la page Documents de gouvernance, à l'adresse https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Document Processus d'errata de spécification Bluetooth (disponible sur la page Modèles et documents du groupe de travail, à l'adresse https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Document de processus du groupe de travail (disponible sur la page Modèles et documents du groupe de travail, à l'adresse https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Stratégie de test et terminologie terminéeview document (disponible sur la page Exigences du test de qualification, à l'adresse https://www.bluetooth.com/specifications/qualification-test-requirements)
Spécification RTC Review Liste de contrôle du processus (disponible sur la page Modèles et documents des groupes de travail, à l'adresse https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Numéros attribués Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Modèles et documents du groupe de travail (disponibles sur la page Modèles et documents du groupe de travail, à l'adresse https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Supplément aux spécifications du GATT (GSS) (disponible sur la page Spécifications du GATT, à l'adresse https://www.bluetooth.com/specifications/gatt)
Soumettre une idée pour une nouvelle spécification https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Acronymes et abréviations

Tableau A: Acronymes et abréviations

Annexe A - Classification de la gravité de l'erratum

Cette annexe résume les directives de classification de gravité pour un erratum de spécification. Ce tableau sera ajouté à une future révision de l'EPD, puis cette section sera supprimée.

En savoir plus sur ce manuel et télécharger le PDF :

Document de processus de gestion des spécifications (SMPD) - PDF optimisé
Document de processus de gestion des spécifications (SMPD) - PDF original

Des questions sur votre manuel ? Postez-les dans les commentaires !

Références

Manuel d'utilisation