Documento de proceso de xestión de especificación (SMPD)

Este documento, independentemente do seu título ou contido, non é unha especificación Bluetooth suxeita ás licenzas concedidas por Bluetooth SIG Inc. ("Bluetooth SIG") e os seus membros segundo o Acordo de licenza de patentes / dereitos de autor Bluetooth e o Acordo de licenza de marca comercial Bluetooth.

ESTE DOCUMENTO FORMÉTASE "TAL COMO" E BLUETOOTH SIG, OS SEUS MEMBROS E OS SEUS AFILIADOS NON FAN REPRESENTACIÓNS NIN GARANTÍAS E RINUNCIAN TODAS AS GARANTÍAS, EXPRESAS O IMPLÍCITAS, INCLUÍDO CALQUERA GARANTÍA DE COMERCIABILIDADE, TITULARIDADE, TITLE. QUE O CONTIDO DESTE DOCUMENTO ESTÁ LIBRE DE ERROS.

NA MESURA QUE NON ESTÁ PROHIBIDO POLA LEI, BLUETOOTH SIG, OS SEUS MEMBROS E OS SEUS AFILIADOS DESCÁNGASE TODA A RESPONSABILIDADE QUE XAIXE OU RELACIÓN CO USO DESTE DOCUMENTO E CALQUERA INFORMACIÓN CONTIDA NESTE DOCUMENTO. INTERRUPCIÓN, OU POR DANOS ESPECIAIS, INDIRECTOS, CONSECUENTES, INCIDENTAIS O PUNITIVOS, NON obstante, causados e independentemente da teoría da responsabilidade e, aínda que o BLUETOOTH SIG, os seus membros ou os seus afiliados fosen asesorados dos posibles.

Este documento é propietario de Bluetooth SIG. Este documento pode conter ou cubrir asuntos que sexan propiedade intelectual de Bluetooth SIG e dos seus membros. O envío deste documento non outorga ningunha licenza a ningunha propiedade intelectual de Bluetooth SIG nin dos seus membros.

Este documento está suxeito a cambios sen previo aviso.

Copyright © 2004–2019 por Bluetooth SIG, Inc. A marca e os logotipos Bluetooth son propiedade de Bluetooth SIG, Inc. Outras marcas e nomes de terceiros son propiedade dos seus respectivos propietarios.

1. Introdución

O documento de proceso de xestión de especificación (SMPD) describe os procesos que os autores e as especificacións reviewOs seguidores deben seguir para desenvolver novas especificacións e mellorar as especificacións existentes (é dicir, para engadir ou eliminar funcionalidades ou para cambiar a funcionalidade específica nunha especificación adoptada), manter as especificacións adoptadas e xestionar o final da vida útil das especificacións adoptadas. Ademais, este documento describe o proceso para crear, reviewing e aprobar libros brancos.

Hai diferenzas no proceso de desenvolvemento de especificación entre desenvolver novas especificacións e mellorar as especificacións existentes debido ás diferenzas inherentes no alcance desas tarefas; estas diferenzas resáltanse neste documento.

O proceso de desenvolvemento de especificación inclúe:

Unha fase de requisitos (descrita na sección 3) para definir os requisitos funcionais
Unha fase de desenvolvemento (descrita na sección 4) para desenvolver e review especificacións

Unha fase de validación (descrita na sección 5) para validar as especificacións mediante probas de prototipo interoperable (IOP)
Unha fase de adopción / aprobación (descrita na sección 6) para presentar as especificacións ao Consello de administración (SX) de Bluetooth SIG para a súa adopción / aprobación

O documento de proceso de especificación de erratas (EPD) [3] describe o proceso para propoñer e reviewintroducindo erratas de especificación e aprobándoas como correccións de erratas (como se define nos estatutos [2]) ás especificacións adoptadas. A non ser que se indique o contrario, todas as referencias a erratas neste SMPD significan erradas de especificación.

1.1 Precedencia

Os estatutos de Bluetooth SIG, Inc. (estatutos) e os acordos de adhesión [2] prevalecen sobre calquera contido conflitivo neses documentos e no SMPD. Non obstante todo o que figura neste documento, o Consello de Administración conserva a máxima discreción e autoridade para tomar medidas e tomar decisións aínda que esas accións e decisións non sigan nin entren en conflito con nada neste documento e nada neste documento limita ou restrinxe a autoridade independente do Consello de Administración. e discreción.

Se hai conflitos entre o texto do SMPD e as cifras, o texto primará.

1.2 Grupos e comités referenciados

Neste documento faise referencia aos seguintes tipos de grupos: grupos de estudo (SG), grupos de expertos (EG) e grupos de traballo (GT). Un GT tamén pode ter un subgrupo que informe ao GT. Do mesmo xeito, neste documento faise referencia aos seguintes tipos de comités: Bluetooth Architectural Review Board (BARB), proba e interoperabilidade Bluetooth (ITV) e Re Qualification Bluetoothview Taboleiro (BQRB). Este documento tamén fai referencia ao persoal técnico de Bluetooth SIG (BSTS) e ao BoD.

1.3 Comité reviews e aprobacións

Un comité review é un review que é conducido por membros dun comité (normalmente 3 membros) para proporcionar comentarios nun tempo especificado (normalmente 2-3 semanas), con todoview o tempo pode variar dependendo da extensión e complexidade do material e doutras prioridades dentro do comité. O grupo que solicita a review e o comité que dirixe a review cada un acorda a duración do review. Os membros do grupo e do comité usan as ferramentas Bluetooth SIG para notificar e rexistrar o inicio e o final da review. Polo xeral, o grupo procesará os comentarios do comité cando se reciba. Cando o comité review o tempo expira, o grupo completa os comentarios do comité e tamén debe considerar calquera re-chegada tardíaview comentarios tendo en conta que o material pode estar suxeito á aprobación posterior por parte do comité.

A votación dos membros do comité obtense a aprobación dun comité de conformidade co documento de proceso do grupo de traballo [4].

1.4 Avisos aos membros e accesibilidade dos materiais

Todos os avisos facilitados aos membros segundo este documento poden facilitarse por correo electrónico, como unha actualización técnica periódica. As notificacións que se proporcionarán a todos os membros enviaranse a todos os membros activos (é dicir, cando a adhesión non foi suspendida, cesada ou retirada). Cando se envían notificacións por correo electrónico, enviaranse ao último enderezo de correo electrónico coñecido (como se reflicte nos rexistros actuais de Bluetooth SIG) de cada individuo que se rexistrou na conta de membro da compañía membro e que non optou por non recibir notificacións por correo electrónico. Nada neste documento modifica as obrigas ou requisitos de Bluetooth SIG con respecto á notificación prevista nos estatutos ou calquera outro acordo entre Bluetooth SIG e calquera membro.

Onde queira que este documento se refira a websitio accesible a todos os membros, refírese á accesibilidade para as persoas que teñen unha conta Bluetooth SIG activa. Os membros que non teñan unha conta activa poden crear unha conta a través do Bluetooth SIG websitio.

1.5 Modelos

Para cada tipo de documento (por exemplo, especificacións, libros brancos, documentos de proba) mencionados neste SMPD, Bluetooth SIG proporciona un modelo. O modelo debe usarse como base para cada documento producido segundo este SMPD. Se non se usa o modelo correcto pode producirse a aprobación do documento. Os modelos están dispoñibles no Bluetooth SIG websitio [8].

1.6 Tipos de especificación

Hai varios tipos de especificacións Bluetooth SIG. Xerárquicamente, todas as especificacións dependen da especificación do núcleo Bluetooth. Especificacións como a tradicional profiles; protocolos tradicionais; e profesional baseado no GATTfileOs servizos baseados en GATT e os protocolos baseados en GATT dependen das características da especificación principal. Outras especificacións, como as especificacións do modelo Mesh, dependen do Mesh Profile especificación que á súa vez depende da especificación básica.

A especificación do complemento de especificación central (CSS) define tipos de datos, formatos de datos e pro comúnfile e códigos de erro de servizo que son utilizados pola especificación principal e outras especificacións e que non define por si mesmos ningún comportamento.

A especificación GATT Specification Supplement (GSS) define os formatos característicos e descritores que usa Profiles e Servizos e non define por si mesmo ningún comportamento.
A especificación Mesh Device Properties (MDP) define as propiedades de malla usadas por Mesh Profile e as especificacións do modelo de malla e non define por si mesmo ningún comportamento.

2. Rematadoview

Esta sección ofrece un sobreview dos procesos e non pretende incluír todos os detalles.

A figura 2.1 mostra as seis fases principais que compoñen o proceso de xestión de especificación.

As primeiras catro fases prodúcense durante o proceso de desenvolvemento das especificacións e consisten na fase de requisitos (sección 3), na fase de desenvolvemento (sección 4), na fase de validación (sección 5) e na fase de adopción / aprobación (sección 6). A isto séguenlle dúas fases posteriores á adopción: a fase de mantemento das especificacións (sección 7) e a fase de finalización da especificación (sección 8).

A figura 2.2 ilustra detalles das catro fases dentro do proceso de desenvolvemento de especificación. Os cadros grises indican os principais resultados para cada fase. As caixas laranxas resumen os fitos do proceso.

Na fase de requisitos (descrita na sección 3), unha proposta para iniciar un novo traballo (unha nova proposta de traballo (NWP)) inicia o proceso de desenvolvemento de especificación definindo os escenarios de usuario que se habilitarán se o novo traballo continúa. Se se aproba o NWP, un grupo asignado crea un Documento de requirimentos funcionais (FRD). Unha vez aprobado o FRD e asignado a un grupo, comeza a fase de desenvolvemento.

Durante a fase de desenvolvemento (descrita na sección 4), o desenvolvemento das especificacións progresa a través dunha secuencia de stages (0.5 / DIPD a 0.9 / CR) culminando cun borrador completo da especificación. A especificación 0.9 / CR ponse a disposición de todos os membros e despois envíase ao Consello de Administración que considera a especificación para a súa aprobación. Unha vez aprobada, comeza a fase de validación.

Durante a fase de validación do desenvolvemento de especificación (descrita na sección 5), a especificación 0.9 / CR aprobada por BoD ponse a disposición de todos os membros para review e validar, e Membro Review está iniciado. A validación lévase a cabo mediante probas de interoperabilidade (IOP) entre prototipos construídos polos membros. Unha vez completada a proba de PIO (se é necesario para a especificación) e BARB aproba o informe de proba de PIO, comeza a Fase de Adopción / Aprobación.

Durante a fase de adopción / aprobación (descrita na sección 6), finalízanse a especificación e os documentos de proba relacionados; Recíbense as aprobacións BARB, BQRB e BTI; e o paquete de especificación final envíase ao Consello de Administración que considera a especificación para a súa adopción (é dicir, a aprobación final).

Unha especificación pode ter que volver a unha fase anterior ou stage se se fan cambios significativos. Nalgúns casos, tamén pode ser posible renunciar a parte dunha fase como se describe na sección 4.4.

A Fase de Mantemento de Especificacións (descrita na Sección 7) comeza despois de que o BoD adopte unha especificación. Durante esta fase infórmanse e avalíanse os posibles erros atopados nunha especificación adoptada e (se é necesario) fanse correccións de erratas na especificación. A fase de mantemento de especificación continúa ata que a especificación está obsoleta ou retirada (ver Fase de fin de vida das especificacións no parágrafo seguinte).

A fase de fin de vida das especificacións (descrita na sección 8) describe o proceso para desaprobar e retirar as especificacións adoptadas.

3. Fase de requisitos

A fase de requisitos comeza xa cun NWP (que indica o desexo de iniciar o traballo nun ou máis escenarios de usuario) ou logo de determinar que o novo traballo desexado xa está cuberto pola súa carta de traballo. Se un GT quere comezar un novo traballo que cre que xa está dentro do alcance da súa carta de GT, o GT debe seguir o proceso definido na sección 3.1 para proceder directamente ao desenvolvemento dun FRD. Para o resto de elementos de traballo, o GT debe seguir o proceso definido na sección 3.2. O FRD define o alcance dos requisitos funcionais que se usan para construír especificacións na fase de desenvolvemento. A fase de requisitos está ilustrada na figura 3.1.

3.1 Novo traballo cuberto por unha carta do GT

Cando un GT quere comezar un novo traballo e cre razoablemente que a funcionalidade que quere engadir xa está dentro do alcance da súa carta de GT, o GT pode comezar a traballar no FRD, sempre que o notifiquen inmediatamente a BARB. O GT incluirá na súa notificación a BARB unha descrición do novo traballo proposto e unha copia da carta do GT con linguaxe destacada que os autoriza a comezar o novo traballo.

Se BARB rexeita a análise do GT, o GT debe deixar de traballar no FRD e continuar co proceso NWP descrito na sección 3.2. Se BARB aproba a análise do GT, o GT avisará inmediatamente a BSTS (por correo electrónico a specification.manager@bluetooth.com) e BSTS engadirá o punto á seguinte axenda do BoD.

O GT incluirá na súa notificación a BSTS a mesma información que proporcionou a BARB. Se o BoD rexeita a análise do GT, o GT debe deixar de traballar no FRD e continuar co proceso NWP descrito na sección 3.2. Se o consello de administración aproba a análise do grupo de traballo, o grupo de traballo pode seguir traballando no FRD como se describe na sección 3.3.

3.2 Nova proposta de traballo (NWP)

Calquera membro, WG, SG ou EG pode crear e enviar un NWP (a través do Bluetooth SIG websitio [10]). Un NWP debe incluír, como mínimo, información sobre o seguinte usando o modelo oficial fornecido en [8]:

Escenarios de usuario
Compromiso dos membros para desenvolver o FRD e en que áreas (por exemplo, Colaborador, Autor, Reviewer, Prototipado)

Proposta de liderado do traballo de FRD
Proposta de tarefa grupal para o traballo de FRD
Enderezo de correo electrónico dos autores principais

Nota: A guía sobre o proceso NWP está dispoñible no Bluetooth SIG websitio [10].

BSTS realizará as seguintes tarefas durante o desenvolvemento do NWP:

Proporcione aos autores un acuse de recibo (normalmente dentro dos sete días naturais posteriores á recepción) e describa os seguintes pasos.

Se é necesario, traballe cos autores para que o NWP sexa claro e completo. Isto pode requirir varias iteracións do NWP.
Se o NWP contén declaracións sobre erros nas especificacións Bluetooth adoptadas, colabore co autor (s) para file entradas no sistema de erratas.
Se se observa que o NWP está a duplicar un traballo que xa está en curso ou que xa está rematado, comuníquelo aos autores do outro traballo para a súa avaliación.

Envía o NWP ao NWP websitio accesible a todos os membros.
Notifique a todos os membros que o NWP está dispoñible para review e se é necesario un compromiso adicional de membros para desenvolver o FRD.

Os membros poden poñerse en contacto co (s) autor (es) para facer preguntas ou proporcionar comentarios sobre o NWP.

Polo menos tres empresas membros deben comprometerse a participar na conclusión do FRD resultante para que o NWP sexa candidato á aprobación do BoD e polo menos unha empresa membro debe ser membro asociado ou promotor. Tras a aprobación do NWP polo BoD, o BoD asignará o NWP a un subgrupo ou SG existente de todos os membros para traballar no FRD (descrito na sección 3.3). Se non existe un subgrupo WG ou SG apropiado, pódese crear un.

Para os NWP que teñan o compromiso de membro suficiente, BSTS realizará as seguintes tarefas adicionais:

Polo menos 13 días antes de que se propoña a aprobación do NWP polo Consello de Administración, avise a BARB e ao grupo ao que se recomenda a asignación do NWP da aprobación do NWP pendente. Isto faise para proporcionar unha oportunidade de retroalimentación en áreas como o grupo proposto, se o NWP xa está cuberto por traballos existentes, etc.

Envíe o NWP completado ao BoD.

Se o NWP é enviado por membros que non están asociados a un grupo, prepare un dos membros para presentar o NWP ao Consello de Administración.
Se o NWP é enviado por un grupo, organice para que o presidente do grupo presente o NWP ao Consello de Administración.

Invite á presidencia BARB e ás presidencias do grupo, ás que se recomenda a asignación do NWP, á reunión do Consello de Administración.
Se o consello de administración aproba e asigna o NWP, avise ao grupo ao que foi asignado; o autor (es); os membros identificados no NWP como comprometidos a desenvolver o FRD correspondente; e se un grupo propón o NWP, o grupo do resultado e os seguintes pasos.

Despois de que o BoD aprobe un NWP, actualice o estado no NWP websitio.

O BoD pode rexeitar calquera NWP ao seu criterio, por exemploample, debido ás limitacións de recursos, se o traballo xa está completamente rematado, o traballo está fóra do alcance dos documentos gobernantes de Bluetooth SIG (por exemplo, a Interface de programación de aplicacións (API)) [2], ou se o traballo proposto debería ser filed como unha errata. Se o NWP é rexeitado, BSTS notificará ao autor ou autores, aos membros identificados no NWP como comprometidos a desenvolver o FRD correspondente e, se un grupo propón o NWP, o grupo. A notificación incluirá calquera motivo para o rexeitamento. O autor (s), os membros comprometidos ou o grupo poden solicitar tempo na axenda do Consello de Administración para apelar o rexeitamento.

Se un membro ou grupo quere propoñer eliminar unha característica dunha especificación adoptada, o grupo ou membro debe preparar un NWP. O NWP debe incluír unha análise do impacto que terá a eliminación na compatibilidade e interoperabilidade, incluíndo unha análise do impacto nos casos de proba.

Non se requiren NWP para melloras nas especificacións CSS, GSS ou MDP: normalmente, as actualizacións das especificacións CSS, GSS ou MDP resultan das actualizacións doutras especificacións que teñen os seus propios NWP.

3.3 Documento de requisitos funcionais (FRD)

Os FRD definen os requisitos funcionais para habilitar escenarios de usuario. Un FRD debe incluír, como mínimo, información sobre o seguinte usando o modelo oficial fornecido en [8]:

Escenarios de usuario
Requisitos funcionais baseados nos escenarios do usuario

Compromiso dos membros para desenvolver as especificacións resultantes
Soporte opcional de prototipos por parte dos membros para as funcións previstas
GT recomendado para desenvolver as especificacións resultantes

Desenvolvemento de FRD

Os FRD son creados polo subgrupo WG asignado por todos os membros ou os membros da SG co apoio editorial de BSTS. Calquera membro interesado en participar no desenvolvemento de FRD pode unirse ao grupo.

Os FRD deben indicar o compromiso de polo menos dúas (aínda que se recomenda a tres) empresas membros de nivel asociado ou promotor de participar no desenvolvemento da especificación resultante. Os GT ou SG que envíen un FRD deberían tentar acadar un amplo apoio de empresas membros do grupo que representan o segmento da industria obxectivo identificado no FRD.

A nova funcionalidade proposta nun FRD debería ser compatible con tantos transportes como dispositivos existentes. Isto inclúe, por exemploample, apoiando a profesional baseado no GATTfiles e servizos tanto no transporte Tarifa básica / Tarifa de datos estendida (BR / EDR) como no transporte Bluetooth Low Energy (LE). Se a nova funcionalidade carece de soporte de membro suficiente para un transporte, por exemploampDebido á falta de compromiso dos membros para definir o uso do transporte ou a un número potencialmente insuficiente de plataformas de proba IOP para un ou máis papeis, o apoio a ese transporte pode excluírse do FRD.

A non ser que se xustifique o contrario, a nova funcionalidade, profileOs servizos deben cumprir cos requisitos de compatibilidade inversa descritos na sección 3.3.2.

O WG ou o SG deben enviar o FRD a BARB para que o reintegreview e aprobación. BARB debe aprobar ou rexeitar o FRD en función do seu criterio de enxeñaría. Se o aproba BARB, o FRD porase a disposición de todos os membros e BSTS emitirá a notificación da súa dispoñibilidade.

Non se requiren FRD para melloras nas especificacións CSS, GSS ou MDP: normalmente, as actualizacións das especificacións CSS, GSS ou MDP resultan das actualizacións doutras especificacións que teñen os seus propios FRD.

Requisitos de compatibilidade con versións anteriores

Compatibilidade con versións anteriores para BR / EDR

Para a operación BR / EDR, o requisito de compatibilidade con versións anteriores defínese como interoperación coa parte BR / EDR da especificación do núcleo Bluetooth v1.1 e posteriores.

Compatibilidade con versións anteriores para Bluetooth de baixo consumo

Para a operación LE, o requisito de compatibilidade con versións anteriores defínese como interoperación coa parte LE da especificación do núcleo Bluetooth v4.0 e posteriores.

Compatibilidade con versións anteriores para especificacións distintas da especificación básica

Para especificacións distintas da especificación do núcleo Bluetooth, a compatibilidade cunha versión anterior debe manterse con todas as versións anteriores que teñan o mesmo número de versión principal. Por example, a versión 1.3 debe ser compatible coas versións 1.2, 1.1 e 1.0, pero é posible que a versión 2.0 non sexa compatible coas versións 1.0, 1.1, 1.2 e 1.3. Teña en conta que un incremento do número de versión principal da Especificación Core non implica a falta de compatibilidade con versións anteriores.

Exención dos requisitos de compatibilidade con versións anteriores

O WG ou SG poden propoñer a exención de funcionalidades específicas do requisito de compatibilidade con versións anteriores se se ofrece unha xustificación. Por example, se se demostra que a funcionalidade ten baixas taxas de adopción do mercado ou, por problemas de interoperabilidade, é mellor eliminar ou substituír a funcionalidade que modificar a funcionalidade. O WG ou o SG deben incluír as exencións de compatibilidade con versións anteriores no FRD, que sexan aprobadas polo BARB logo da aprobación do FRD. Calquera exención aprobada por BARB presentarase ao Consello de Administración para a súa aprobación no 0.9 / CR Stage.

3.4 Carta do grupo de traballo

Cando BARB aproba un FRD que se propón asignar a un GT existente, ese GT debe preparar un borrador de actualización á súa carta para engadir a nova funcionalidade ao alcance (a non ser que o BoD aprobara previamente a análise do GT de que unha actualización de carta de WG é Non requerido). Non obstante, cando BARB aproba un FRD que se propón asignar a un novo GT, BARB e os membros que estean interesados en desenvolver a funcionalidade descrita no FRD deberán preparar un borrador de carta para un novo GT coa nova funcionalidade incluída no ámbito da carta. .

Unha vez que se prepara o novo ou actualizado WG charter, deberá enviarllo a BARB para que o reintegraview e aprobación. Unha vez que BARB aprobe a carta, o borrador da carta nova ou actualizada do GT será sometido ao Consello de Administración para a súa aprobación.

Unha vez que o BoD aproba a carta, o GT ao que o BoD asignou o traballo de desenvolvemento de especificación debe traballar en estreita colaboración co grupo que preparou o FRD no caso de que sexan necesarias as actualizacións ou aclaracións necesarias para ese FRD. Se se precisa unha actualización de FRD durante a fase de desenvolvemento, débense seguir os procesos descritos na sección 3.3 e nesta sección; con todo, o desenvolvemento de especificacións pode ocorrer en paralelo coas actualizacións de cartas FRD e WG.

3.5 Requisitos Requisitos de saída de fase

A fase de requisitos está completa e a fase de desenvolvemento comeza cando unha carta de GT con alcance necesario para o FRD é confirmada ou aprobada polo consello de administración e se cumpren os seguintes requisitos:

O NWP foi aprobado polo BoD ou o BoD acordou que un NWP non é necesario.

A carta de FRD e correspondente WG foi aprobada por BARB.

4. Fase de desenvolvemento

Durante a fase de desenvolvemento, os GT asignados crean a nova especificación e / ou melloran unha especificación existente. O FRD define os requisitos da nova ou mellorada especificación Bluetooth. Na especificación non se permite ningunha funcionalidade que non estea razoablemente relacionada cos requisitos do FRD. O obxectivo é crear unha especificación 0.9 / CR que estea lista para a fase de validación (descrita na sección 5) ao finalizar a fase de desenvolvemento.
Durante a fase de desenvolvemento, unha especificación (ou mellora de especificación) avanza en tres stages.

Para unha nova especificación, os tres stagson:

0.5 Stage
0.7 Stage

0.9 Stage

Para unha mellora das especificacións, os tres stagson:

Borrador do documento de proposta de mellora (DIPD) Stage

Documento de proposta de mellora final (FIPD) Stage
Solicitude de cambio (CR) Stage

Cada stage descríbese máis adiante nas subseccións seguintes. A figura 4.1 seguinte ilustra os diversos documentos que o GT preparará en cada stage.

Figura 4.1: Máisview da especificación stagque ocorren durante a fase de desenvolvemento

O papel de BARB ao longo do proceso de desenvolvemento de especificación é proporcionar aos grupos de traballo asesoramento e asistencia técnica. Os GT poden, en calquera momento, facer solicitudes a BARB de asesoramento técnico sobre o desenvolvemento de especificación e os conceptos arquitectónicos que se empregarán nunha especificación. Anímase especialmente aos grupos de traballo a solicitar comentarios temperáns de BARB sobre características que teñen consideracións arquitectónicas máis complexas.

4.1 0.5 / DIPD Stage

Durante o 0.5 / DIPD Stage, o GT desenvolverá o seguinte empregando os modelos oficiais fornecidos en [8]:

Para unha nova especificación, un borrador da especificación 0.5, que debe incluír, como mínimo, información sobre o seguinte:

Arquitectura para cubrir os requisitos establecidos no FRD

Para protocolos, definíronse os puntos de acceso ao servizo
Para servizos, datos e comportamento expostos
Para profiles, protocolos identificados e funcionalidade especificada

2. Para unha mellora das especificacións, un borrador do DIPD, que debe incluír, como mínimo, información sobre o seguinte:

Antecedentes: O alcance do traballo, os obxectivos que guían o traballo e como se encaixa esta proposta específica no ámbito
Acabadoview da proposta: Un resumo da funcionalidade estendida (maior flexibilidade, mellor rendemento, etc.) proporcionada polo DIPD, incluíndo unha descrición clara de como a nova funcionalidade encaixa na versión de especificación actual. Se o GT avaliou varias propostas, estas propostas deberían incluírse para permitir a BARB a oportunidade de determinar se se fixo a debida dilixencia na selección da proposta preferida.

Cobertura dos requisitos: Un resumo da cobertura dos requirimentos funcionais dada pola proposta, con referencia aos requirimentos do sistema adecuados e aos escenarios de uso indicados no FRD asociado
Definición do problema: Unha declaración dos problemas resoltos pola (s) proposta (s)
Criterios de selección: Unha afirmación relativa aos criterios de selección / rendemento a partir de métricas de avaliación asociadas que guiaron o proceso de selección

Xustificación da elección: Un exame das métricas de avaliación que xustifican a elección entre as propostas e revelan as compensacións
Descrición: Unha descrición da funcionalidade e protocolos ampliados. Esta sección pode adaptarse a diferentes necesidades engadindo sub-seccións relevantes.

3. Estratexia de proba: Unha descrición da funcionalidade que se propón probar (ou non probar) como parte do Programa de cualificación Bluetooth e como se propón probar a funcionalidade (por exemplo, expectativas sobre o (s) proba (s) inferior (s) ou o (s) testador (s) superior (s) e se as probas atribuiranse como probas de conformidade ou interoperabilidade ou unha combinación de ambas). Pode estar nun documento separado ou nunha sección separada dentro da especificación 0.5 / DIPD. As convencións que se empregarán nunha Estratexia de proba descríbense na Estratexia de proba e Terminoloxía terminadaview documento (TSTO) [5].

A audiencia principal dos documentos neste stage son os membros do WG e BARB os que o sonview as propostas arquitectónicas e a cobertura de requirimentos e a ITV que reviewé a estratexia de proba. Na maioría dos casos, os documentos deste stagNon están destinados a conter texto que está previsto incluír na especificación final.

BSTS debe volverview todos os documentos para que sexan coherentes coas Directrices de redacción de Bluetooth [1] e identifique os problemas que o GT poderá tratar. BARB debe volverview a especificación 0.5 / DIPD. Para mellorar a especificación, BARB tamén debe volverview o DIPD para o cumprimento dos requisitos de compatibilidade inversa descritos na sección 3.3.2. A ITV debe volverview a estratexia de proba.

BARB debe aprobar ou rexeitar a especificación 0.5 / DIPD en función do seu criterio de enxeñaría. Se a aproba BARB, a especificación 0.5 / DIPD estará dispoñible no Bluetooth SIG websitio para todos os membros asociados e promotores e a notificación da súa dispoñibilidade será emitida por BSTS. No 0.5 / DIPD Stage, non é necesaria a aprobación da estratexia de proba.
O 0.5 / DIPD Stage non é necesario para melloras nas especificacións CSS, GSS ou MDP

0.5 / DIPD StagRequisitos de saída

O 0.5 / DIPD Stage está completo e o 0.7 / FIPD Stage comeza cando se cumpren os seguintes requisitos de saída:

BSTS completou reviewespecificando a especificación 0.5 / DIPD e a estratexia de proba.

BARB aprobou a especificación 0.5 / DIPD.
BTI completou a súa review da estratexia de proba.
BSTS puxo a disposición da especificación 0.5 / DIPD a todos os membros asociados e promotores.

4.2 0.7 / FIPD Stage

Durante o 0.7 / FIPD Stage, o GT desenvolverá o seguinte empregando os modelos oficiais fornecidos en [8]:

Para unha nova especificación, un borrador da especificación 0.7, que debe incluír, como mínimo, información sobre o seguinte:

Unha descrición de todos os cambios que se fixeron desde a aprobación BARB 0.5, incluíndo propostas novas ou modificadas, criterios de selección e xustificación da elección. Os cambios deben describirse no mesmo nivel de detalle que o requirido no 0.5 Stage.

Todos os requisitos funcionais da FRD abordados.

2. Para unha mellora das especificacións, un borrador do FIPD, que debe incluír, como mínimo, información sobre o seguinte:

Unha descrición de todos os cambios realizados desde o DIPD aprobado por BARB, incluíndo propostas novas ou modificadas, criterios de selección e xustificación da elección. Os cambios deben describirse no mesmo nivel de detalle que o requirido no DIPD Stage.

Se é necesario, desenvolvéronse as áreas que foron descritas na sección 4.1 en relación ao DIPD.
Unha descrición completa da mellora.
Unha descrición arquitectónica actualizada.
Todos os requisitos funcionais da FRD abordados.

3. Documentos de proba 0.7 / FIPD, que deben incluír, como mínimo, información sobre o seguinte:

Unha suite de probas, que consiste nunha lista de fins de proba como se describe no TSTO [5].
Unha declaración de conformidade de implementación (ICS), como se describe no TSTO [5].

Para melloras de especificación, Test Suite e ICS poden subministrarse como documentos separados ou como seccións adicionais no FIPD.

A audiencia principal dos documentos producidos neste stage son os membros do WG e BARB os que o sonview a descrición completa da característica ou mellora incluído algún texto previsto para a súa inclusión na especificación final. BTI é o público de review dos documentos da proba.

BSTS volveráview as partes novas ou modificadas da especificación 0.7 / FIPD e documentos de proba para a coherencia coas Directrices de redacción de Bluetooth, incluíndo as convencións de idiomas establecidas por Bluetooth SIG. BARB volveráview a especificación 0.7 / FIPD.

BSTS axudará ao GT na preparación dos documentos de proba 0.7 / FIPD segundo o TSTO [5].

A ITV debe volverview os documentos de proba 0.7 / FIPD. O GT debe proporcionar a BTI a especificación 0.7 / FIPD como referencia cando se reviewing os documentos de proba 0.7 / FIPD, que revertirá a ITVview segundo a especificación BTI Review Lista de verificación de procesos [6].

Despois de que BARB completase o seu review da especificación 0.7 / FIPD e BTI completou a súa review dos documentos de proba 0.7 / FIPD, BSTS fará a reviewEd 0.7 / Especificación FIPD dispoñible para todos os membros asociados e promotores.

O 0.7 / FIPD Stage non é necesario para melloras nas especificacións CSS, GSS ou MDP.

0.7 / FIPD StagRequisitos de saída

O 0.7 / FIPD Stage está completo e o 0.9 / CR Stage comeza cando se cumpren os seguintes requisitos de saída:

BSTS completou reviewincluíndo a especificación 0.7 / FIPD e os documentos de proba.
BARB rematou reviewespecificando a especificación 0.7 / FIPD.
A ITV rematouviewing o 0.7 / FIPD Test Suite (Test Purpose) e 0.7 / FIPD ICS.
BSTS fixo a reviewEd 0.7 / Especificación FIPD dispoñible para todos os membros asociados e promotores.

4.3 0.9 / CR Stage

Hai dous tipos de CR: un CR integrado, que é un documento con seguimento de cambios de toda unha especificación adoptada que mostra todos os cambios realizados desde a versión anterior, e un CR abreviado, que é un documento que proporciona instrucións para modificar só as seccións afectadas de a versión de especificación na que se basea o CR.

Durante o 0.9 / CR Stage, o GT desenvolverá o seguinte empregando os modelos oficiais fornecidos en [8]:

Para unha nova especificación, un borrador completo da especificación 0.9, que debe incluír, como mínimo, información sobre o seguinte:

Unha descrición de todos os cambios que se fixeron desde o BARB-reviewespecificación 0.7 ed (ou desde que se renunciou á especificación 0.5 se produciu a especificación 0.7), incluíndo nova ou
propostas modificadas, criterios de selección e xustificación da elección. Os cambios deben describirse no mesmo nivel de detalle que o requirido no 0.5 Stage e 0.7 Stage.

2. Para unha mellora das especificacións:

Ou un CR integrado, que debe incluír, como mínimo, información sobre o seguinte:
Unha descrición de todos os cambios que se fixeron desde o BARB-reviewed FIPD (ou desde o DIPD se se renuncia ao FIPD) incluíndo propostas novas ou modificadas, criterios de selección e xustificación da elección. Os cambios deben describirse no mesmo nivel de detalle que o requirido no DIPD Stage e FIPD Stage.
Todos os cambios propostos á especificación adoptada previamente mediante o seguimento de cambios.
Todas as erratas técnicas aprobadas (con cada errata referenciada cun número de errata), mostradas mediante o seguimento de cambios, que aínda non se incorporaron á versión de especificación adoptada anteriormente e ese texto de impacto asociado á mellora da especificación; ou que impactan doutro xeito nas probas de PIO.

3. Ou un CR abreviado, que debe incluír, como mínimo, información sobre o seguinte:

Unha descrición de todos os cambios que se fixeron desde o BARB-reviewed FIPD (ou desde o DIPD se se renuncia ao FIPD) incluíndo propostas novas ou modificadas, criterios de selección e xustificación da elección. Os cambios deben describirse no mesmo nivel de detalle que o requirido no DIPD Stage e FIPD Stage.
Todos os cambios propostos a cada sección e parágrafo afectados da especificación que o CR propón cambiar.
Todas as erratas técnicas aprobadas (con cada errata referenciada cun número de errata), mostradas mediante o marcado, que aínda non se incorporaron á versión de especificación adoptada anteriormente e ese texto de impacto asociado á mellora da especificación; ou que impactan doutro xeito nas probas de PIO.

4. Un CSS CR (se a especificación esixe novas entradas), que pode incluír nun CR abreviado da especificación.
5. Un GSS CR (se a especificación esixe novas entradas), que pode incluír nun CR abreviado da especificación.
6. Un CR MDP (se a especificación esixe novas entradas), que pode estar incrustado nun CR abreviado da especificación.
7. Documentos de proba 0.9 / CR, que deben incluír, como mínimo, información sobre o seguinte utilizando o modelo oficial fornecido en [8]:

A suite de probas 0.9 / CR, que inclúe casos de proba completos de contido e a táboa de mapeo de casos de proba (TCMT) asociada, como se describe no TSTO [5].
O 0.9 / CR ICS, como se describe no TSTO [5].
Se a configuración das probas require parámetros específicos para a implementación baixo proba (IUT), a información eXtra de implementación 0.9 / CR para probas (IXIT).
A Lista de Referencia de Casos de Proba 0.9 / CR (TCRL) (opcional para actualizacións da Especificación Core).

8. Unha análise de cobertura de proba que indique os requisitos de especificación que se proban ou non dentro da suite de probas 0.9 / CR (para melloras de especificación, a análise de cobertura de proba só debe incluír a funcionalidade recentemente engadida e afectada e non as áreas sen impacto de a especificación orixinal).
9. Un plan de proba de PIO.

Para melloras de especificación, Test Suite, ICS e IXIT poden subministrarse como documentos separados ou como seccións adicionais no CR abreviado.

Na maioría dos casos, un CR integrado ou abreviado debería basearse na versión da especificación adoptada anteriormente, pero tamén pode basearse no último borrador intermedio. O último número de versión de especificación de borrador intermedio debe ser o número de versión asociado a unha versión do documento que está conxelada e que non cambiará co paso do tempo. En caso contrario, información adicional de identificación (como a data do documento e a URL a unha localización permanente) debe proporcionarse para identificar a versión específica "de base". Se se usa un borrador intermedio, deben incluírse calquera cambio non directamente relacionado co CR dentro dunha sección determinada que o CR modifique, pero non é necesario que se mostren mediante o marcado. Se posteriormente se actualizan as partes relevantes do borrador intermedio, o CR deberá actualizarse para reflectir as actualizacións do borrador intermedio.

O ideal sería que o material CR abreviado estea integrado nun borrador da especificación completa e dos documentos completos da proba antes da fase de validación, pero tamén se poden integrar ao comezo da fase de validación. Se se están a desenvolver varias funcións para unha especificación (por exemplo, a Especificación básica), pode ser desexable integrar as funcións nun único borrador despois de completar a proba de PIO.

BSTS volveráview a especificación 0.9 / CR e os documentos de proba para a coherencia coas Directrices de redacción de Bluetooth. Entón BARB volveráview a especificación 0.9 / CR seguida posteriormente polo plan de proba IOP (como se describe na sección 4.3.1). Unha vez que o WG envía a especificación 0.9 / CR a BARB para review, BSTS fará que sexa accesible para todos os membrosview e notificar a todos os membros a súa dispoñibilidade. A partir deste momento no proceso de desenvolvemento de especificación, BSTS fará que os borradores da especificación presentada a BARB estean dispoñibles para todos os membros con avisos periódicos enviados a todos os membros.

Para unha mellora da especificación, o GT recomendará ao Consello de Administración se as versións anteriores da especificación deberían estar obsoletas ou retiradas, incluíndo os motivos técnicos das recomendacións.

BARB volveráview a análise do GT sobre o cumprimento da especificación 0.9 / CR cos requisitos dados no FRD, os posibles problemas de seguridade, os problemas normativos, a conformidade coa arquitectura Bluetooth e, para unha mellora das especificacións, o cumprimento dos requisitos de compatibilidade posterior descritos na sección 3.3.2. .XNUMX. Se BARB identifica algún problema de seguridade potencial, BARB avisará a BSTS para que o reintegreview e coordinación co Grupo de expertos en seguridade; e se BARB identifica algunha implicación regulamentaria, BARB notificará a BSTS que o reintegreview e coordinarse co Comité Regulador e o asesor legal de Bluetooth SIG. BARB debe aprobar ou rexeitar a especificación 0.9 / CR en función do seu criterio de enxeñaría e da consideración dos factores descritos neste parágrafo.

BTI volveráview os documentos de proba 0.9 / CR tendo en conta a análise da cobertura da proba. A ITV debe aprobar ou rexeitar os documentos de proba 0.9 / CR.

Despois de que BARB aprobe a especificación 0.9 / CR, o WG envía o plan de proba de PIO a BARB para a súa review.

A especificación 0.9 / CR aprobada por BARB preséntase ao Consello de Administración para aprobar o inicio das probas IOP e a publicación da especificación 0.9 / CR a todos os membros.

Para resaltar posibles problemas legais, os GT poden solicitar unha nova especificaciónview polo asesor legal de Bluetooth SIG (legal review) antes da re legal obrigatoriaview ten lugar durante a fase de adopción / aprobación. Non obstante, para melloras de especificación, o re legalview debería facerse nun CR integrado (en oposición a un CR abreviado) e este debería programarse coa maior antelación posible para que os recursos estean dispoñibles.

Plan de proba de PIO

O GT desenvolverá un plan de proba IOP escrito que debe cumprir todos os requisitos definidos a continuación para o seu uso durante a fase de validación nos eventos de proba IOP. Os grupos de traballo deben enviar o plan de proba de PIO a BARB para a súa review antes de que comecen os eventos de proba de PIO. Para melloras de especificación simples (especialmente aquelas que non requiren modificar nin engadir ningún caso de proba no Test Suite), é posible que non sexan necesarias probas de IOP e o WG pode presentar unha solicitude a BARB para unha exención da proba de IOP usando o proceso definido na sección 4.4.

O plan de proba IOP debe incluír:

Proba casos para verificar todas as novas funcións obrigatorias, opcionais e condicionais
Polo menos un caso de proba para cada código operativo
Polo menos un caso de proba para cada parámetro
Polo menos un caso de proba para cada tipo de paquete
Casos de proba de compatibilidade con versións anteriores para melloras de especificación para que se cumpran os requisitos listados na sección 3.3.2 para todas as funcionalidades melloradas (ver tamén a sección 4.3.1.1).
Casos de proba onde a IUT está exposta a valores fóra dos rangos definidos ou a aspectos de comportamento considerados inválidos ou inesperados (casos de proba de comportamento non válidos). Teña en conta que se espera que un probador como PTS ou outra ferramenta de proba sexa o iniciador de calquera comportamento non válido.
Calquera número asignado temporal (seleccionado en coordinación con BSTS para evitar a superposición nos próximos eventos de proba de IOP) para ser usado no evento de proba de IOP, como se describe na sección 4.3.1.2.
Identificación do número requirido de implementacións independentes que deben superar cada caso de proba, tendo en conta os requisitos de cobertura descritos na sección 4.3.1.3
Identificación de calquera caso de proba no Test Suite que o GT cre que debe excluírse e a xustificación da súa exclusión. Normalmente inclúen: • Casos de proba de probas futuras (por exemplo, probas comúns para que se poidan acomodar posibles adicións futuras, como características adicionais, características de extensión ou o uso de bits ou campos Reserved for Future Use (RFU))
• Probas que son un subconxunto doutras probas incluídas
• Casos de proba xenéricos que son practicamente idénticos a probas que se executan para outras especificacións (por exemplo, desencadear códigos de erro comúns)
• Casos de proba co mesmo propósito que os casos de proba que atropelan outro transporte (por exemplo, un caso de proba BR / EDR similar a un caso de proba LE)
• Robustidade ou probas de esforzo da implementación

O plan de proba IOP tamén pode incluír probas exclusivas das probas IOP, como casos de proba de extremo a extremo que xuntan secuencias máis complexas que poden parecerse a un escenario típico de usuario.

Aínda que non é necesaria a aprobación por BARB do plan de proba IOP (ao entender que o plan de proba IOP seguirá modificándose e mellorándose con cada evento de proba IOP), é necesaria a aprobación BARB do informe de proba IOP (ver Sección 5.1.1) . Se un plan de proba IOP non cumpre todos os requisitos definidos na sección 4.3.1, o WG debería presentar un resumo das varianzas coñecidas e as razóns para cada varianza a BARB antes de que comecen os eventos de proba IOP.

O plan de proba IOP e os casos de proba deben basearse principalmente no contido dos documentos de proba da especificación asociada.

Para facer os eventos de proba IOP eficientes, o WG debería ter o plan de proba IOP e todos os casos de proba asociados completados e dispoñibles para os implementadores idealmente polo menos un mes antes do primeiro evento de proba IOP.

Planificación de probas de compatibilidade con versións anteriores
Para melloras de especificación, as probas de IOP de compatibilidade con versións anteriores deben considerar a verificación contra todas as versións activas e obsoletas da especificación porque esas especificacións e funcionalidades que se atopan normalmente nos produtos Bluetooth poden ter unha vida moi longa (por exemplo, vehículos). O GT debe analizar o nivel axeitado de probas de compatibilidade con versións anteriores necesarias (se as hai), incluíndo as versións para probar e as probas a realizar e proporcionar esta análise a BARB. BARB debe volverview a análise e recomenda cambios (se os hai) para que o GT poida incorporalo ao plan de proba de PIO.

Recoméndase aos membros que participan nas probas de compatibilidade con versións anteriores que traian dispositivos herdados que foron cualificados con respecto ás versións de especificación anteriores. O GT debe informar de calquera fallo de compatibilidade con versións anteriores no informe de proba de PIO. Tamén se recomenda ás empresas membros que realicen probas de compatibilidade con versións anteriores nos seus propios laboratorios fóra da localización do evento de proba IOP e que denuncien ao WG calquera problema relacionado coas especificacións.

Números asignados temporais empregados nas probas de PIO
Débese consultar a BSTS e BARB para coordinar a asignación temporal dos números asignados que se utilizarán no evento de proba IOP para que non haxa solapamentos ou choques con outras especificacións. Estes valores temporais deben incluírse no plan de proba IOP e non serán asignados para o seu uso por ningunha especificación adoptada.

Para probas IOP onde se propoñen un ou máis novos valores UUID de 16 bits, os valores dentro do intervalo de 0x7F00 a 0x7FFF resérvanse para probas IOP.

Para probas de IOP onde se propoñan un ou máis valores de Multiplexor de servizo de protocolo fixo (PSM), empregaranse valores que comezan desde o final do intervalo válido de 0x0000 a 0x007F, como se especifica na especificación do núcleo.

Requisitos de cobertura
O GT debe proporcionarlle a proba de BARB que o número requirido (como se describe nas seccións seguintes) de implementacións independentes superou cada caso de proba. Calquera solicitude de WG de excepcións ao número requirido de implementacións independentes debe indicarse no plan de proba IOP que se presenta a BARB.

Considérase que as implementacións son independentes entre si sempre que todas as partes relevantes para a validación foron desenvolvidas de forma independente, é dicir, por diferentes equipos (que non necesariamente proceden de diferentes empresas). BSTS pode axudar a avaliar se os prototipos poden considerarse independentes entre si para preservar o anonimato e a confidencialidade dos detalles da implementación.

Teña en conta que as ferramentas de proba, incluído o PTS, non se consideran implementacións independentes.

Especificacións básicas Requisitos de cobertura IOP
Unha característica de especificación básica normalmente define un ou máis roles onde cada rol está deseñado para interoperar con un ou máis outros roles ou posiblemente consigo mesmo.

Para cada par de roles deseñados para interoperar entre si, polo menos tres implementacións independentes de cada rol deben demostrarse para interoperar con tres implementacións independentes do rol complementario.

Para cada rol que poida interoperar con outro dispositivo no mesmo rol, polo menos tres implementacións independentes dese rol deben demostrar que poden interactuar entre elas nese rol.

Especificación do servizo Requisitos de cobertura de PIO
Polo menos tres implementacións de servizos independentes deben demostrar que interoperan con polo menos unha implementación de cliente, que pode ser PTS.

Profile e requisitos de cobertura de PIO de especificación de protocolo
Profile e as especificacións do protocolo normalmente definen un ou máis roles onde cada rol está deseñado para interoperar con un ou máis outros roles, ou posiblemente consigo mesmo.

Para cada par de roles deseñados para interoperar entre si, polo menos dúas implementacións independentes de cada rol deben demostrar que interoperan con dúas implementacións independentes do rol complementario.

Para cada rol que poida interoperar con outro dispositivo no mesmo rol, polo menos tres implementacións independentes dese rol deben demostrar que interactúan entre elas nese rol.

Especificación do modelo Requisitos de cobertura de PIO
Polo menos tres implementacións de modelos de control independentes ou modelos de control deben demostrar que interoperan con polo menos unha implementación de cliente (que pode ser PTS) e polo menos unha implementación de modelo de cliente debe demostrar que interopera con polo menos unha implementación de modelo de servidor e PTS.

Numeración de versión de especificación

Durante o 0.9 / CR Stage, o GT debe preparar unha recomendación para presentar ao Consello de Administración sobre o número de versión que se aplicará á especificación cando se adopte.

As versións das especificacións divídense en dous tipos: versións de versión completa, que inclúen funcións novas ou actualizadas, e versións de mantemento (tamén coñecidas como "versións dot-Z"), que integran erratas técnicas e editoriais, pero non inclúen novas ou actualizadas. características. As versións de versión completa teñen números de dúas partes en forma de XY, como 2.1 ou 5.0, mentres que as versións de mantemento teñen números de tres partes en forma de XYZ, como 2.1.2. O valor de Z non pode ser 0.

Para dúas versións, unha denomínase "versión superior" e a outra é a "versión inferior". Isto determínase segundo as seguintes regras:

Se os compoñentes X difiren, o que ten o valor X máis alto é a "versión superior".
Se os compoñentes X son os mesmos, pero os compoñentes Y difiren, o que ten o valor Y máis alto é a "versión superior".
Se os compoñentes XY son os mesmos, pero os compoñentes Z difiren, o que ten o valor Z máis alto é a "versión superior". Para este propósito, un número de dúas partes XY trátase como un número de tres partes XY0.

Por example, os seguintes números de versión estarían en orde da versión máis baixa á versión máis alta: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Para CSS, cada actualización incrementa só o compoñente X do número de versión.

Requisitos previos para a aprobación do consello de administración
Ao finalizar a fase de desenvolvemento de especificación deberán cumprirse os seguintes requisitos antes de que se presente ao BoD unha aprobación de especificación 0.9 / CR para a súa aprobación:

O GT completou a análise da cobertura das probas.
BSTS completou reviewing a especificación 0.9 / CR e os documentos de proba.
BARB aprobou a especificación 0.9 / CR.
BARB aprobou o CSS CR (se a especificación esixe novas entradas) que pode incluír nun CR abreviado da especificación.
BARB aprobou os GSS CR e MDP CR (se a especificación esixe novas entradas).
BTI aprobou o 0.9 / CR Test Suite, ICS e TCRL, xunto cun IXIT (sempre que sexa necesario o IXIT para realizar as probas no Test Suite). O TCRL é opcional neste momentotage para actualizacións da especificación principal.
O GT presentou o plan de proba de PIO a BARB para a súa review (se BARB non renuncia á proba).

Os documentos presentados ao consello de administración deben incluír a especificación 0.9 / CR aprobada por BARB e unha presentación ao consello de administración que debe incluír:

Calquera solicitude coñecida para renunciar ás probas de PIO ou calquera dos requisitos definidos na sección 4.3.1
Lista de transportes compatibles coa especificación (por exemplo, BR / EDR, LE, etc.)
Para unha mellora das especificacións, as exencións dos requisitos de compatibilidade con versións anteriores (descritas na sección 3.3.2) que o WG solicita
Para unha mellora da especificación, unha recomendación do GT para que o número de versión se aplique á especificación adoptada
Para unha mellora da especificación, a recomendación de fin de vida do GT para a (s) versión (s) anterior (s) da especificación adoptada, incluíndo calquera motivo técnico polo que se recomenda ou non a depreciación ou retirada de calquera versión anterior da especificación e a xustificación para a recomendación
Calquera preocupación seria non resolta por parte dos membros do BARB ou do BTI (por exemplo, razóns para non haber votos durante as aprobacións, preocupacións derivadas da review de documentos de proba ou preocupacións de que a especificación 0.9 / CR está fóra do alcance do FRD ou da carta)
O estado de preparación do Profile Tuning Suite (PTS) ou outras ferramentas necesarias asociadas á adopción que prepara BSTS

O consello de administración pode optar por aprobar a especificación 0.9 / CR para a proba de PIO segundo o requirido polos estatutos [2], antes de que BTI aprobe os documentos de proba de 0.9 / CR e antes de que o GT confirme que o plan de proba de PIO cumpre os requisitos definidos na sección 4.3.1. 0.9. O consello de administración tamén pode condicionar a aprobación da especificación 0.9 / CR para probas de PIO despois da aprobación de BTI dos documentos de proba XNUMX / CR.

0.9 / CR StagRequisitos de saída
O 0.9 / CR Stage está completa e a fase de validación comeza cando o BoD aproba o inicio das probas de PIO.

4.4 Renuncias ao proceso de desenvolvemento de especificación

Un GT pode solicitar a renuncia a un ou máis dos seguintes pasos do proceso:

O 0.5 / DIPD Stage
O 0.7 / FIPD Stage
Probas de PIO dentro da fase de validación

Para solicitar unha exención, o GT debe empregar o modelo de exención de proceso fornecido por Bluetooth SIG [8] e presentar unha solicitude de exención a cada comité (é dicir, BARB ou BTI) que estea obrigada a review ou aprobar o proxecto de especificación ou os documentos de proba asociados no stage que o GT propón a renuncia e cada un deses comités debe aprobar a solicitude de exención.

A solicitude de exención debe incluír o seguinte:

Unha identificación do stage (s) que o GT quere renunciar
Unha xustificación por que o stagHai que renunciar aos e
Unha identificación de cada comité (é dicir, ITV e / ou BARB) que se esixeview e aprobar a solicitude de exención

O comité que considere a exención pode requirir que un representante do GT faga unha presentación para xustificar a exención do proceso SMPD antes de decidir a solicitude de exención.

Se unha renuncia solicita a renuncia a varios pasos e parte da renuncia é rexeitada e parte é aprobada, a resposta do comité debe indicar que pasos na solicitude de renuncia foron aprobados e cales foron rexeitados. Se se rexeita unha solicitude de exención, a notificación de rexeitamento deberá incluír os motivos do rexeitamento.

5. Fase de validación

Durante a fase de validación, o WG realizará probas de PIO na especificación 0.9 / CR co obxectivo de entregar un informe de proba de PIO para BARB review e aprobación. Sempre que sexa posible, as probas de PIO de melloras de especificación deberían realizarse contra a especificación de borrador integrado. Ademais, o membro Review, como requiren os estatutos [2], comeza durante esta fase.

Se a especificación (ou a mellora) non precisa de probas de PIO, entón pódese renunciar ás probas de PIO dentro da fase de validación usando o proceso descrito na sección 4.4.

Ao longo das probas de IOP (que poden ser un ou máis eventos), o WG debería facer un seguimento dos problemas mediante o sistema de seguimento de problemas de Bluetooth SIG e repetir para incorporar actualizacións do borrador de especificación, documentos de proba e plan de proba IOP. Unha vez finalizada a proba de PIO, o GT debe completar as actualizacións do borrador de especificación e documentos de proba para tratar todos os problemas e preparar e enviar un informe de proba de PIO a BARB paraview e aprobación. Isto móstrase na figura 5.1.

Durante a fase de validación hai varias actividades que poden comezar. Estas actividades poden ocorrer en paralelo e inclúen o seguinte:

A especificación 0.9 / CR aprobada pola BoD ponse a disposición de todos os membros por BSTS coa notificación do inicio do Membro Review período esixido polos Estatutos.
Calquera actualización requirida incorpórase a CSS (que pode estar incrustada nun CR abreviado da especificación).
Inclúense definicións de características ou descritores na especificación GSS, así como PTS para probas IOP.
As definicións de propiedades de malla están incorporadas á especificación MDP, así como PTS para probas de IOP.
BSTS habilita o rexistro da plataforma IOP e a ferramenta de entrada de resultados en preparación para a proba de IOP.
Probas de PIO, se é necesario (ver Sección 5.1).
Review os comentarios e problemas, incluídos os enviados como resultado das probas de PIO, son procesados e os cambios incorpóranse ao borrador de especificación.

5.1 Probas de PIO

O obxectivo principal das probas de PIO é validar a especificación, por exemploample, comprobando a precisión e a ambigüidade dentro do texto, reviewSe hai erros e omisións de deseño fundamentais e se proporciona validación fronte aos requisitos establecidos previamente desenvolvidos anteriormente no proceso de desenvolvemento de especificación. A proba de IOP pode producir cambios na especificación de borrador e poden ser necesarios varios eventos de proba de IOP para completar todas as probas requiridas.

É importante dar aos membros fóra do GT a oportunidade de participar nas probas de PIO porque proporcionan un independente view da especificación e pode descubrir áreas de ambigüidade na especificación que poden non ser evidentes para os membros do GT que desenvolveron o borrador. Antes de cada evento de proba IOP, BSTS fará dispoñibles os detalles do evento, a última especificación de borrador, o Test Suite e o plan de proba IOP e avisará a todos os membros idealmente un mes antes de cada evento. A especificación de borrador actualizada, Suite de proba e plan de proba IOP utilizados nun evento de proba IOP deberían estar dispoñibles polo menos unha semana antes de cada evento.

Durante a proba IOP, as combinacións de plataformas parellas intentarán executar as probas e os participantes nas probas IOP rexistrarán os resultados de cada proba e comentarios de cada proba. Un resumo anonimizado destes resultados (referido a, por exemplo, "Plataforma A", "Plataforma B", etc.) e calquera comentario recollerase durante os eventos de proba do PIO e porase a disposición dos membros do GT durante e despois do PIO evento de proba. No caso de que se precise información adicional para comprender mellor os comentarios ou fallos ocorridos durante as probas de PIO, BSTS pode actuar como intermediario para recoller máis información do membro que envía.

Se é posible, PTS debería actualizarse para soportar probas de IOP con plataformas en todas as capas por riba da interface de controlador de host (HCI) e estar presente nos eventos de proba de IOP para esas capas. Outras ferramentas de proba tamén poden estar presentes nos eventos de proba IOP. No informe de proba de PIO debería incluírse un resumo dos resultados das probas con PTS ou outras ferramentas de proba (se as hai).

A proba IOP estará aberta a todos os membros que queiran proporcionar unha implementación de prototipo, con todo, Bluetooth SIG pode condicionar a participación na aceptación de acordos con Bluetooth SIG (incluídos os acordos de participación e confidencialidade). O GT é o responsable de procesar e resolver os problemas descubertos durante as probas de PIO e de actualizar os documentos afectados; Os cambios aprobados por WG deben incorporarse como actualizacións do borrador de especificacións e documentos de proba para o seu uso en cada evento de proba IOP.

Antes da fase de validación, os GT poden realizar probas preliminares de IOP en eventos que só están abertos a membros do GT, pero os resultados das probas informais poden non estar incluídos nos resultados da proba de IOP.

Pode ocorrer que se sigan todos os pasos previos ao primeiro evento de proba de IOP, incluída a data e o lugar de IOP anunciados coa intención de iniciar as probas de IOP, pero a aprobación do BoD non se asegurou antes do inicio do evento de proba. Neste caso, o Consello de Administración pode autorizar a inclusión dos resultados das probas que se recolleron antes da aprobación do Consello de Administración para iniciar as probas de PIO, sempre que os resultados recollidos estivesen baseados na mesma especificación e o Consello de probas fose aprobado polo Consello de Administración.

Non se requiren probas de PIO para melloras nas especificacións CSS, GSS ou MDP.

Informe de proba de PIO
Despois de completar a proba de PIO, o GT debe presentar o informe de proba de PIO a BARB co obxectivo de demostrar que o número necesario de plataformas independentes superou as probas requiridas. BARB debe volverview e aprobará ou rexeitará o informe de proba de PIO e avisará ao GT se é necesario realizar probas de PIO adicionais antes de enviar o paquete de especificación de Proxecto de votación ao Consello de Administración. BSTS e o WG deben asegurarse de que non apareza información de identificación de membros no informe de proba IOP antes de enviar o informe a BARB.

O informe de proba IOP debe incluír:

Unha lista de todos os eventos de proba de PIO ocorridos durante a fase de validación, incluídas as súas datas e localizacións.
O número de empresas membros e plataformas independentes que participaron en cada evento IOP, incluído se se utilizou PTS.
Unha lista das versións do plan de proba, Suite de proba e IOP utilizadas en cada evento.
Un resumo executivo que indica se todos os casos de proba cumpriron ou non os criterios mínimos de aprobación.
Un resumo de calquera varianza dos requisitos do plan de proba IOP definidos na sección 4.3.1 e o fundamento de cada varianza.
Un resumo da cobertura de PTS para casos de proba no Test Suite.
Unha lista de todos os casos de proba (incluídas as de compatibilidade con versións anteriores) do plan de proba IOP, o número de aprobados da proba, o número de fallos na proba e se se cumpriron os criterios mínimos por caso de proba, incluída unha explicación de por que non se cumprían os requisitos coñecido.
Un resumo de problemas, comentarios e preguntas en cada evento (incluídos aqueles filed contra a especificación durante a proba IOP) e o impacto na especificación e nos documentos de proba.

5.2 Requisitos de saída da fase de validación

A fase de validación está completa e a fase de aprobación / adopción comeza cando BARB aprobou o informe de proba IOP (a menos que BARB renunciase ás probas) e se cumpriron todos os seguintes requisitos:

BSTS puxo a disposición de todos os membros a especificación 0.9 / CR aprobada para Membro Review como requiren os estatutos e notificaron a todos os membros a súa dispoñibilidade.
Incorporáronse e probáronse todos os problemas identificados durante as probas de PIO e que teñen un impacto na proba.
WG completou as probas de PIO (a menos que BARB renunciase ás probas).

6. Fase de Adopción / Aprobación

Durante a fase de aprobación / aprobación, finalízanse as especificacións e os documentos de proba relacionados, recíbese a aprobación BARB, BQRB e BTI, emítese un aviso da Data de adopción proposta xunto coa versión final do proxecto de especificación presentado ao Consello de Administración para a súa adopción ( Borrador de votación), e o paquete de especificación final envíase ao Consello de Administración. Despois da duración mínima do membro Review esixido polos estatutos [2]), o consello de administración considerará a especificación para a súa adopción na data de adopción. Despois da adopción, a especificación publícase e o sistema de cualificación está habilitado. A fase de adopción / aprobación está ilustrada na figura 6.1.

6.1 Proxecto de votación

O borrador de votación créase incorporando actualizacións (fornecidas na fase de validación) nos documentos de especificación requiridos e preparando un borrador final da nova especificación. Para melloras de especificación, BSTS creará a especificación integrada integrando un ou varios CR na versión superior da especificación adoptada anteriormente (ver Sección 4.3.2) se aínda non se completou antes da fase de validación.

Se se fan cambios na especificación durante esta fase e o WG, BARB ou BTI determina que calquera cambio require probas IOP adicionais, a especificación volverá á parte de proba IOP da fase de validación para que o WG realice as probas adicionais. Durante a fase de adopción / aprobación, os seguintes documentos completaranse e poñeranse a disposición do Consello de Administración antes da data de adopción:

O borrador da votación
Todas as especificacións de soporte (por exemplo, CSS, GSS, MDP) necesarias para o tipo de especificación (ou mellora) relevante, se non se adoptaron previamente
Para melloras de especificación, unha versión con seguimento de cambios da versión de especificación adoptada que mostra os cambios propostos no borrador de votación
Unha descrición do GT de calquera requisito de compatibilidade con versións anteriores (como se describe na sección 3.3.2) que non se cumpriron e a xustificación de calquera exención
Unha descrición do GT de calquera requisito do plan de proba IOP (como se describe na sección 4.3.1) que non se cumpriu e a xustificación de calquera desviación xunto co informe de proba IOP (que se pode proporcionar proporcionando unha ligazón a unha copia en o Bluetooth SIG websitio)
Unha recomendación do GT para a depreciación ou retirada de calquera versión (s) anterior (s) da especificación adoptada xunto cunha xustificación, que resalta os cambios desde o 0.9 / CR StagRecomendación de fin de vida
Un resumo, elaborado polo GT, dos cambios nas funcións ou funcionalidades desde a especificación 0.9 / CR (se hai)
Un resumo, elaborado por BARB, das preocupacións formuladas polos membros de BARB de que a especificación producida polo GT está fóra do alcance da carta aprobada polo Consello de Administración (se existe)
Unha lista de cuestións xurídicas pendentes da resolución legalview (se hai)
A suite de probas aprobada pola ITV, xunto co resumo aprobado polo WG da cobertura das probas da especificación do borrador de votación. En caso de funcionalidade recentemente engadida ou modificada sen cobertura da proba, é necesaria unha xustificación por escrito da omisión
ICS e IXIT aprobados pola ITV (se a especificación o esixe)
O TCRL aprobado por BTI e BQRB
Un informe elaborado por BSTS xunto con BTI sobre o estado de preparación das ferramentas (por exemplo, PTS e outras ferramentas de proba, Bluetooth Launch Studio) incluído se algún caso de proba no TCRL non é compatible coas ferramentas de proba.
Un resumo, elaborado polo GT, de todos os números asignados necesarios
Unha lista de verificación de adopción preparada por BSTS e o GT que demostra que todos os entregables desta sección completáronse
Toda a outra información solicitada polo Consello de Administración

Durante a fase de aprobación / aprobación, o GT debería empregar o sistema de seguimento de problemas de Bluetooth SIG para capturar problemas e comentarios contra o proxecto de especificación e os documentos de proba para que se teñan en conta na finalización do proxecto de votación. Para unha mellora da especificación, todas as erratas aprobadas relevantes (é dicir, as erratas aprobadas aínda non integradas) deben incorporarse e deben identificarse mediante cambios de seguimento.

O GT debe presentar o borrador de especificación final a BSTS para que poida solicitar unha notificación legalview. Para novas especificacións, o re legalview incluirá a especificación completa. Para melloras de especificación, o review centrarase principalmente nas partes cambiadas da especificación. O propósito da re legalview consiste principalmente en identificar os riscos legais que o GT debería considerar e tratar de resolver. Os comentarios legais clasificaranse en función da gravidade. Se é legal unha opciónview realizouse no 0.9 / CR Stage, a versión que se somete a solicitude legalview debe mostrar, como cambios rastrexados, todos os cambios realizados desde esa versión (xerados polo WG ou BSTS). Ao finalizar a re legalview, o GT e BSTS acordarán os comentarios que se incorporarán ao borrador de especificación. Se hai comentarios legais non resoltos de re legalview no proxecto de especificación, o presidente do GT pode solicitar tempo na axenda do BoD para acordar a resolución.

En paralelo coa re legalview, o GT debe presentar o proxecto de especificación a BARB para que o reintegreview. Tras a presentación inicial a BARB, BSTS notificará a todos os membros que o borrador de especificación foi remitido a BARB para a súa solicitudeview e que tamén está dispoñible para Member Review. Se o GT envía actualizacións ao borrador de especificación para BARB re-review, BSTS enviará avisos adicionais a todos os membros periódicamente.

Ao rematar BARB review, o WG e BARB acordarán os comentarios que se incorporarán ao proxecto de especificación.

Se o legal review resulta en calquera cambio de fondo, re adicionalview por BARB pode ser necesario. Do mesmo xeito, se o BARB review resultado de calquera cambio de fondo, BSTS determinará se hai unha nova legalidadeview deses cambios é necesario. Ao finalizar a re legalview e BARB review, BARB debe aprobar ou rexeitar o borrador de votación.

Se algún documento de proba require actualización, BSTS axudará ao GT na actualización dos documentos de proba. A ITV debe aprobar ou rexeitar os documentos da proba. Se o aproba BTI, BTI axudará a finalizar o TCRL e entregará este documento a BQRB xunto cos ICS, IXIT e Test Suite asociados. BSTS estimará a data da reunión do Consello de Ministros cando o Consello de Ministros pretende votar sobre a adopción do borrador de votación (data de adopción) e proporcionarao ITV para o seu uso no TCRL. A aprobación BARB da especificación, a aprobación BTI de todos os documentos de proba (incluídos Test Suite, TCRL, ICS e IXIT) e a aprobación BQRB do TCRL deben producirse na data de adopción ou antes dela.

BSTS informará a todos os membros da finalización e dispoñibilidade do borrador de votación e da data de adopción. A data de adopción establecerase antes dos 60 días despois de que se notificase aos membros a especificación 0.9 / CR aprobada polo BoD, a non ser que o membro Review o período de tempo é acurtado polo Consello de Administración de acordo cos estatutos e, polo menos, 14 días despois do aviso da data de adopción é proporcionado aos membros de acordo cos estatutos. Para os casos en que se integraron varios CR nun borrador de votación, o inicio de Member Review é a data na que se notificou aos membros o CR máis recente aprobado por BoD.

Despois de que se notifique a data de adopción aos membros, permítense correccións aprobadas por BoD para erros tipográficos no borrador de votación. A liña de tempo da adopción de especificación está ilustrada na figura 6.2.

6.2 Números asignados

Bluetooth SIG mantén un conxunto de números asignados dispoñibles públicamente nos números asignados Bluetooth SIG websitio [7]. Estes números asignados agrúpanse en varios espazos numéricos (un conxunto de números relacionados sen duplicados). Os números asignados poden superpoñerse a outros números asignados en diferentes espazos numéricos, pero non se pode reutilizar ningún número dentro dun espazo numérico. Os distintos espazos numéricos están definidos na especificación que define o uso dos números asignados.

Despois de que BARB aprobe o informe de proba IOP, o GT enviará unha solicitude a BARB para a asignación de novos números dentro dos espazos de número requiridos pola especificación final. BARB volveráview a solicitude e traballar con BSTS para determinar os números asignados. Tras a aprobación da BARB, BSTS programará a publicación dos números asignados para que estean dispoñibles públicamente nos números asignados por Bluetooth SIG websitio [7] dentro dunha semana despois da adopción da especificación.

Unha vez feita a publicación dos números asignados nos números asignados por Bluetooth SIG webno lugar ou dentro dunha especificación adoptada, preténdese que os números asignados sexan inmutables (para non cambiar nin o valor nin o significado). Se por algún motivo quedan inutilizables, convértense en valores reservados e non se lles permite reutilizar.

6.3 Requisitos de saída da fase de aprobación / aprobación

A fase de aprobación / adopción finaliza cando o consello de administración adoptou a especificación e completáronse as seguintes actividades postadopción:

BSTS fixo públicos os números finais asignados no Bluetooth SIG websitio.
BSTS fixo pública a especificación adoptada no Bluetooth SIG websitio
BSTS fixo públicos todos os documentos xustificativos (por exemplo, CSS, GSS, MDP) necesarios para a especificación correspondente no Bluetooth SIG websitio.
BSTS puxo os documentos de proba asociados dispoñibles para todos os membros no Bluetooth SIG websitio.
Para melloras de especificación, BSTS realizou unha versión informativa con seguimento de cambios da versión de especificación adoptada anteriormente con todos os cambios realizados pola versión recentemente adoptada e puxo a disposición de todos os membros no Bluetooth SIG websitio.
BSTS habilitou o sistema de cualificación.
BSTS notificou a todos os membros a dispoñibilidade da especificación adoptada e de todos os documentos xustificativos.

O Bluetooth SIG ten previsto completar estas actividades postadopción dentro dunha semana despois da adopción da especificación.

7. Fase de mantemento de especificación

A fase de mantemento das especificacións comeza despois de finalizada a fase de adopción / aprobación. Se se atopan problemas (por exemplo, ambigüidades de redacción ou erros técnicos) coa especificación ou os documentos de proba asociados, deben documentarse creando propostas de erratas mediante a ferramenta Bluetooth SIG Errata. As propostas de erratas de especificación serán procesadas, clasificadas e aprobadas segundo o EPD [3]. As erratas de Test Suite son procesadas e clasificadas segundo o TSTO [5]. Se hai conflitos entre o SMPD e o EPD ou o TSTO, prevalece o SMPD.

A errata de especificación só se debe empregar para corrixir erros técnicos ou editoriais nas especificacións Bluetooth adoptadas finais. A adición, os cambios e a eliminación de funcionalidades só se poden facer mediante o proceso de mellora das especificacións definido anteriormente neste documento.

7.1 Proceso de errata acelerado

Cando se aprobe unha errata seguindo o proceso definido no EPD [3], o WG, BARB ou BSTS poden recomendar que se considere urxente e que se axilice. Cando isto ocorre, BSTS xunto co WG ou BARB presentarán a recomendación ao BoD. O consello de administración decidirá se acepta ou rexeita a recomendación. Se a recomendación é aceptada, BSTS incorporará inmediatamente a errata aprobada ao modelo de errata [8] e traballará co GT responsable para finalizar unha corrección de erratas acelerada que se presentará ao GT para a súa review e aprobación.

Un máisview do proceso de errata acelerado está ilustrado na figura 7.1.

Os seguintes documentos deben completarse e poñerse a disposición do Consello de Administración antes da data de adopción:

O borrador aprobado por BARB corrección de erratas aceleradas.
Unha descrición do GT de calquera requisito de compatibilidade con versións anteriores (como se describe na sección 3.3.2) que non se cumpriron e a xustificación de calquera exención.
Unha lista de cuestións xurídicas pendentes da resolución legalview (se hai).
A suite de probas, ICS e IXIT aprobados pola ITV (se o requiriu a errata).
O TCRL aprobado por BTI e BQRB (se a errata o esixe).
Un informe completado por BSTS xunto con BTI sobre o estado da preparación das ferramentas (por exemplo, PTS e outras ferramentas de proba, Bluetooth Launch Studio), incluído se algún caso de proba no TCRL non está soportado por ferramentas de proba e unha explicación (se o errata o esixe) ).
Unha lista de verificación de adopcións completada por BSTS e o GT que mostra que os entregables desta sección completáronse.
Toda a outra información solicitada polo Consello de Administración.

BSTS traballará co GT responsable para finalizar o borrador de corrección de erratas aceleradas e creará unha versión para enviar ao GT responsableview e aprobación.

O GT debe enviar a corrección de erras acelerada a BSTS para solicitude legalview. Ao finalizar a re legalview, o GT e BSTS acordarán os comentarios que se incorporarán á corrección de erratas acelerada. Se hai comentarios legais non resoltos de re legalview na corrección de erratas acelerada, o presidente do grupo de traballo pode solicitar tempo na axenda do BoD para solicitar a entrada do BoD na resolución.

En paralelo coa re legalview, o grupo de traballo debe enviar a corrección de erratas acelerada a BARB para a súa review. Unha vez que a corrección de erratas aceleradas se envíe a BARB, BSTS fará que sexa accesible para todos os membrosview e notificar a todos os membros a súa dispoñibilidade. Ao rematar BARB review, o WG e BARB acordarán os comentarios que se incorporarán á corrección de erratas acelerada.

Se algún documento de proba require actualización, BSTS axudará ao GT na actualización dos documentos de proba. Tras a aprobación de BTI dos documentos de proba, BTI axudará a finalizar o TCRL e entregará o documento a BQRB xunto cos ICS, IXIT e Test Suite asociados segundo corresponda. BSTS estimará a data de adopción e proporcionaraa a BTI para o seu uso no TCRL. A aprobación BARB da corrección de erratas acelerada, a aprobación BTI de todos os documentos de proba (incluídos Test Suite, TCRL, ICS e IXIT segundo corresponda) e a aprobación BQRB da TCRL deben producirse na data de adopción ou antes dela.

BSTS informará a todos os membros da finalización e dispoñibilidade da corrección de erratas aceleradas e da data de adopción proposta. A data de adopción establecerase e notificarase a todos os membros de conformidade cos estatutos [2] e a data de adopción será polo menos 14 días despois da notificación aos membros. Despois de que se lle comunique aos membros a data de adopción proposta, o consello de administración pode aprobar correccións de erros tipográficos na corrección de erratas aceleradas sen proporcionar un aviso adicional da data de adopción proposta e agardando os 14 días requiridos.

Bluetooth SIG fará que a corrección de erratas acelerada adoptada estea dispoñible publicamente e planea facelo dentro dunha semana despois da súa adopción. BSTS emitirá unha notificación da súa dispoñibilidade a todos os membros.

O proceso de errata acelerado está rematado cando o BoD adoptou a corrección de errata acelerada e completáronse as seguintes actividades postadopción:

BSTS fixo que a corrección de erratas aceleradas adoptada e os documentos de proba asociados (se o requiren a errata) estean dispoñibles publicamente no Bluetooth SIG websitio.
BSTS habilitou o sistema de cualificación (se o requiriu a errata).
BSTS notificou a todos os membros a dispoñibilidade da corrección de erratas acelerada adoptada.

Ao remate destas actividades, a corrección de erratas programarase para a integración nas especificacións afectadas como parte dunha mellora das especificacións planificadas ou nunha próxima versión de mantemento como se describe na sección 7.2.

7.2 Proceso de lanzamento do mantemento (especificacións .Z)

Aproximadamente anualmente, BSTS determinará se hai erratas aprobadas (denominadas Correccións de erratas) que se clasifican como Técnicas / Altas ou Técnicas / Críticas e que aínda non se incorporaron ao texto de ningunha especificación activa (é dicir, unha especificación adoptada que non foi obsoleta nin retirada). Vexa o Apéndice A para obter definicións de clasificación de erratas. Un propietario de especificación (ou o GT contratado para manter a especificación ou BARB se non hai un GT contratado para manter a especificación) tamén pode solicitar unha versión anterior de mantemento dunha especificación activa na que incorporar calquera errata aprobada. Tras a determinación de BSTS ou a petición do propietario da especificación, comezará o proceso de liberación de mantemento.

Un máisview do proceso de lanzamento do mantemento está ilustrado en Erro. Non se atopou a fonte de referencia.

Ao comezo do proceso de lanzamento do mantemento, BSTS xunto co propietario da especificación, BARB e BTI desenvolverán e presentarán un plan ao BoD para incorporar as correccións de erratas á versión de especificación publicada. O plan proposto debe indicar se as correccións de erratas se incorporarán a unha versión de mantemento da especificación (é dicir, unha versión .Z) ou a unha mellora da especificación que xa está en curso (é dicir, unha versión XY). O plan proposto debería ter en conta se se engadiron novas características obrigatorias entre as versións das especificacións adoptadas, o tempo estimado no que se planea a adopción da seguinte mellora das especificacións e outros factores.

Tras a aprobación dun plan polo BoD, BSTS xunto co propietario da especificación procederán a incorporar todas as correccións de erratas técnicas / medianas, técnicas / altas e técnicas / críticas nun borrador de especificación denominado "Borrador de lanzamento de mantemento". Para correccións editoriais ou técnicas / de errata baixa, se a corrección de errata se aplica a máis dunha versión da especificación, BSTS, a non ser que o BoD indique o contrario, integrará esas erratas só na versión de especificación superior máis recente na próxima actualización desa versión. . Non se pode incluír ningún cambio nun borrador de versión de mantemento que non sexa a incorporación de correccións de erratas. Cada borrador de lanzamento de mantemento debe identificar todas as correccións de erratas incorporadas mediante o seguimento de cambios para mostrar os cambios propostos á versión adoptada previamente da especificación publicada.

O momento da incorporación proposta para cada corrección de erratas nun borrador de lanzamento de mantemento dependerá do impacto da proba de proba: todas as correccións de erratas que non teñan impacto da proba de proba poden incorporarse de inmediato, pero as correccións de erratas que afectan á proba de proba serán procesouse de xeito que o tempo coincida cunha actualización do TCRL.

BTI e BSTS establecerán un prazo para a inclusión de correccións de erratas con impacto de Test Suite nun borrador de lanzamento de mantemento. Este prazo adoita ser de 3 a 6 meses antes da data de aprobación prevista para a próxima versión TCRL importante. As correccións de erratas con impacto de Test Suite que perdan o prazo para a inclusión procesaranse como parte da próxima versión anual de TCRL. Polo tanto, a non ser que se solicite unha versión anterior, o tempo máximo para que as correccións de erratas técnicas / altas ou técnicas / críticas se inclúan nunha actualización de especificación é de aproximadamente 15 a 18 meses.

O propietario da especificación deberá presentar o borrador de lanzamento de mantemento que aprobou como definitivo para re-legalview. A re legalview centrarase principalmente nas partes modificadas da especificación. Ao finalizar a re legalview, o propietario da especificación e BSTS acordarán os comentarios que se incorporarán ao borrador da versión de mantemento. Se hai comentarios legais non resoltos de re legalview no borrador de lanzamento de mantemento, o propietario da especificación pode solicitar tempo na axenda de BoD para buscar a entrada de BoD na resolución.

En paralelo coa re legalview, o propietario da especificación debe enviar o borrador de lanzamento de mantemento a BARB para que o reintegreview. Unha vez que o borrador de lanzamento de mantemento se envíe a BARB, BSTS fará que sexa accesible para todos os membrosview e notificar a todos os membros a súa dispoñibilidade. Ao rematar BARB review, o propietario da especificación e BARB acordarán os comentarios que se incorporarán ao borrador de especificación.

Para as correccións de erradas que impactan nos documentos de proba e cando as erratas de proba correspondentes serán procesadas a tempo para a próxima versión de TCRL, BSTS traballará co propietario da especificación e BTI para actualizar os documentos de proba. Tras a aprobación dos documentos da proba pola ITV, o BSTS estimará a data de adopción e proporcionará a ITTI a data de adopción proposta para o seu uso no TCRL. BTI entregará o TCRL a BQRB xunto cos ICS asociados, IXIT e Test Suite segundo corresponda. A aprobación BARB da especificación, a aprobación BTI de todos os documentos de proba (incluídos Test Suite, TCRL, ICS e IXIT segundo corresponda) e a aprobación BQRB do TCRL deben producirse na data de adopción ou antes dela.

BSTS informará a todos os membros da finalización e dispoñibilidade do borrador de votación e da data de adopción proposta. A data de adopción establecerase e notificarase a todos os membros de acordo cos estatutos e a data de adopción será polo menos 14 días despois da notificación dos membros. Despois de que se lle comunique aos membros a data de adopción proposta, o consello de administración pode aprobar correccións de erros tipográficos no borrador de votación sen proporcionar un aviso adicional sobre a data de adopción proposta e esperando os 14 días requiridos.

Os seguintes documentos deben completarse e poñerse a disposición do Consello de Administración antes da data de adopción:

O borrador da votación
Unha versión con seguimento de cambios do borrador de votación que amosa todos os cambios na versión adoptada da especificación que ten o mesmo valor XY (por exemplo, se o borrador de votación se propón como versión 1.4.2, os cambios seguiranse contra o 1.4.1 versión da especificación)
Unha recomendación do propietario da especificación para a desvalorización ou retirada de calquera versión (s) anterior (s) da especificación adoptada xunto cunha xustificación
Unha lista de cuestións xurídicas pendentes da resolución legalview (se hai)
Test Suite, ICS e IXIT aprobados pola ITV (se o require a versión de mantemento)
O TCRL aprobado por BTI e BQRB (se o require a versión de mantemento)
Un informe completado por BSTS xunto con BTI sobre o estado da preparación das ferramentas (por exemplo, PTS e outras ferramentas de proba, Bluetooth Launch Studio), incluíndo calquera caso de proba no TCRL que non estea soportado polas ferramentas de proba e explicación (se o requiren o mantemento liberación)
Unha lista de verificación de adopción completada por BSTS e o propietario da especificación que demostra que os entregables desta sección completáronse
Toda a outra información solicitada polo Consello de Administración

O proceso de liberación de mantemento rematou cando o Consello de Administración adoptou o borrador de votación e completáronse as seguintes actividades postadopción:

BSTS fixo pública a especificación adoptada e os documentos de proba asociados (se o require a versión de mantemento) no Bluetooth SIG websitio.
BSTS fixo unha versión informativa con seguimento de cambios da versión de especificación adoptada anteriormente con todos os cambios incorporados á versión recentemente adoptada dispoñibles para todos os membros no Bluetooth SIG websitio.
BSTS habilitou o sistema de cualificación.
BSTS notificou a todos os membros a dispoñibilidade da especificación e dos documentos xustificativos adoptados.

O Bluetooth SIG ten previsto completar estas actividades postadopción dentro dunha semana despois da adopción da especificación.

Ao finalizar estas actividades, a especificación permanece na fase de mantemento de especificación ata que a especificación é obsoleta ou retirada, segundo se define na sección 8.

8. Especificación Fase de fin de vida

As especificacións poden quedar obsoletas ou retiradas cando se substitúan por versións máis recentes, que se consideren tecnicamente insuficientes ou por outras razóns. As especificacións obsoletas e retiradas arquívanse e xa non se actualizan. As especificacións obsoletas e retiradas trátanse de xeito diferente no Programa de cualificación Bluetooth.

Calquera membro, grupo ou comité pode enviar recomendacións para desbotar ou retirar unha especificación xunto cunha liña de tempo asociada a BSTS (por correo electrónico a

specification.manager@bluetooth.com) en calquera momento. BSTS tamén pode recomendar a desaprobación ou a retirada dunha especificación e un cronograma asociado. BSTS remitirá a recomendación a BARB e ao grupo ou comité responsable de manter a especificación para review e comentarios.

BARB e o grupo ou comisión responsable avaliarán as recomendacións para desfasar ou retirar unha especificación e terán en conta os seguintes criterios (non exhaustivos):

Existe unha funcionalidade nunha versión anterior da especificación que está obsoleta ou non debería usarse?
Engadiuse unha nova funcionalidade obrigatoria ás versións posteriores?
¿Hai deficiencias nas versións anteriores que prexudican o funcionamento ou a interoperabilidade que se corrixiron en versións posteriores e son necesarias para avanzar nos escenarios de usuario existentes?
¿É necesaria funcionalidade adicional en versións posteriores para avanzar en novos escenarios de usuario?
Hai melloras de usabilidade e interoperabilidade nas versións posteriores?
Hai melloras de seguridade nas versións posteriores?

BARB e o grupo ou comisión responsable poden propor unha recomendación alternativa.

Despois de recibir comentarios de BARB ou do grupo ou comité responsable do mantemento da especificación, BSTS enviará as recomendacións e comentarios ao Consello de Administración para que os considere. O consello de administración pode invitar ao grupo ou comité responsable de manter as especificacións afectadas a reunirse e debater as recomendacións. O Consello de Administración considerará recomendacións e comentarios e pode acordar ou modificar a proposta. O Consello de Administración solicitará que BSTS notifique a todos os membros as propostas de desaprobación ou retirada de especificación (s) e cronoloxía (s) asociada (s) durante 30 díasview período para permitir a todos os membros proporcionar comentarios adicionais antes de tomar a súa decisión final.

O Consello de Administración considerará os comentarios recibidos dos membros. Unha vez que o consello de administración aproba a desvalorización ou retirada dunha especificación, BSTS notificará a todos os membros a decisión e o calendario asociado.

8.1 Deprecación

Unha vez que unha especificación está obsoleta, ocorrerá o seguinte:

A especificación xa non se actualizará.
O GT responsable volveráview todas as erratas pendentes escritas contra a especificación obsoleta para determinar se se aplican a outras especificacións. As erratas poden ser rexeitadas no sistema de erratas e reescribirse contra as especificacións aplicables.
O WG ou BSTS crearán erratas para actualizar as referencias necesarias a especificacións obsoletas noutras especificacións.
BTI actualizará os documentos de proba aplicables para indicar a desvalorización da especificación.
BSTS actualizará o Bluetooth SIG websitio con orientacións sobre especificación (s) alternativa (s) para usar.
Xa non se poden enviar novas erratas contra unha especificación obsoleta.
Non se fará referencia á especificación en ningunha futura especificación.
BSTS arquivará unha versión da especificación marcada como obsoleta para que os membros poidan acceder con fins históricos.

8.2 Retirada

Unha vez que se retira unha especificación, ademais dos pasos que se aplican á desvalorización, producirase o seguinte:

BTI actualizará os documentos de proba aplicables para indicar a retirada da especificación.
BSTS actualizará o Bluetooth SIG websitio con orientacións sobre especificación (s) alternativa (s) para usar.
BSTS arquivará unha versión da especificación marcada como retirada para que os membros poidan acceder con fins históricos.

O consello de administración pode optar por retirar unha especificación inmediatamente sen desestimar antes a especificación.

9. Proceso do libro branco

Os libros brancos créanse só con fins informativos. O seguinte proceso do Libro Branco aplícase a todos os WGs, EGs, SGs e comités de Bluetooth. Esta sección non se aplica aos documentos informativos para o seu uso só dentro do Bluetooth SIG.

Este proceso está ilustrado na figura 9.1 a continuación.

Antes de que ningún grupo ou comité comece a traballar nun libro branco que pretendan ser publicados por Bluetooth SIG, o grupo ou comité preparará unha proposta de actualización de carta que defina claramente o contido proposto do libro branco e unha presentación da proposta dun libro branco.

A presentación da proposta do libro branco debe incluír como mínimo:

A necesidade do libro branco
Un resumo dos contidos propostos do libro branco
Unha explicación de por que non se recomenda incluír o contido como parte dunha especificación
O público previsto
Calquera plan de mantemento (é dicir, pode ser necesario o tempo estimado antes do seguinte lanzamento deste libro branco)
Recomendacións para manexar versións anteriores do libro branco, se as hai (por exemplo, arquivar)

A actualización da carta e a presentación da proposta do libro branco deben enviarse para BARB review. Despois de review e aprobación da actualización de carta por BARB, BSTS enviará a actualización de carta ao Consello de Administración para a súa aprobación xunto coa presentación da proposta de soporte do libro branco.

Se o consello de administración aproba a actualización da carta, o grupo ou comité poderá continuar co desenvolvemento do libro branco.

Cando o grupo ou comité remate o desenvolvemento do libro branco, BSTS realizará unha redacción editorialview por coherencia coas Directrices de redacción de Bluetooth.

Despois da resolución dos comentarios de BSTS, o grupo deberá enviar o libro branco a BSTS para que poida recibir unha notificación legalview. Ao finalizar a re legalview, o grupo e BSTS acordarán os comentarios que se incorporarán ao libro branco. Se hai comentarios legais non resoltos de re legalview no libro branco, o presidente do grupo pode solicitar tempo na axenda do BoD para solicitar a entrada do BoD na resolución.

En paralelo coa re legalview, o grupo debe enviar o libro branco a BARB para a súa review. Como parte da súa review, BARB pode recomendar se algunha parte do libro branco debe eliminarse do libro branco e incorporarse a unha especificación despois do proceso na sección 3. BARB tamén pode decidir enviar o libro branco a outros grupos ou comités paraview. Ao rematar BARB review, o grupo e BARB acordarán os comentarios que se incorporarán ao libro branco.

Despois de que BARB aprobe o libro branco, o grupo ou comité de autoridade presentará o documento branco para a súa aprobación ao Consello de Administración.

O proceso do libro branco rematou cando o BoD aprobou o libro branco e completáronse as seguintes actividades posteriores á aprobación:

BSTS fixo público o libro branco aprobado no Bluetooth SIG websitio.
BSTS notifica a todos os membros o libro branco aprobado.
Se o libro branco é unha mellora dun libro branco existente, BSTS arquivará unha versión do libro branco para que os membros poidan acceder con fins históricos.

Bluetooth SIG ten previsto completar as actividades posteriores á aprobación dentro dunha semana despois da aprobación do libro branco.

10. Referencias

Os documentos referenciados de Bluetooth están dispoñibles desde Bluetooth websitio http://www.bluetooth.com.

Directrices de redacción por Bluetooth (dispoñibles na páxina Modelos e documentos do grupo de traballo en https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Estatutos de Bluetooth SIG, Inc. (dispoñible na páxina Documentos de goberno, en https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Especificación Bluetooth Documento de proceso de erratas (dispoñible na páxina Modelos e documentos do grupo de traballo en https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Documento de proceso do grupo de traballo (dispoñible na páxina Modelos e documentos do grupo de traballo, en https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Terminou a estratexia de proba e a terminoloxíaview documento (dispoñible na páxina Requisitos da proba de cualificación, en https://www.bluetooth.com/specifications/qualification-test-requirements)
Especificación BTI Review Lista de verificación de procesos (dispoñible na páxina Modelos e documentos do grupo de traballo en https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Números asignados por Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Modelos e documentos de grupos de traballo (dispoñibles na páxina Modelos e documentos de grupos de traballo en https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Suplemento de especificación GATT (GSS) (dispoñible na páxina de especificacións GATT, en https://www.bluetooth.com/specifications/gatt)
Envíe unha idea para unha nova especificación https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Siglas e abreviaturas

Táboa A: Siglas e abreviaturas

Anexo A - Clasificación da gravidade do Erratum

Este apéndice resume as pautas de clasificación da gravidade para unha errata de especificación. Esta táboa engadirase a unha futura revisión do EPD e, a continuación, eliminarase esta sección.

Ler máis sobre este manual e descargar PDF:

Documento de proceso de xestión de especificación (SMPD) - PDF optimizado
Documento de proceso de xestión de especificación (SMPD) - PDF orixinal

Preguntas sobre o teu manual? Publica nos comentarios!

Referencias

Manual de usuario