Spesifikasiebestuursprosesdokument (SMPD)

Hierdie dokument, ongeag die titel of inhoud, is nie 'n Bluetooth-spesifikasie nie, onderhewig aan die lisensies wat deur Bluetooth SIG Inc. ("Bluetooth SIG") en sy lede ingevolge die Bluetooth Patent / Copyright License Agreement en Bluetooth Trademark License Agreement toegeken word.

HIERDIE DOKUMENT WORD "AS IS" EN BLUETOOTH SIG VERSKAF, SY LEDE EN HULLE GEMEENSKAPPE MAAK GEEN VERTEENWOORDIGINGE OF WAARBORGE NIE EN ONTSLAG ALLE WAARBORGE, UITDRUKKELIK OF IMPLIKAAT, INSLUITEND GARANTIE, VERANTWOORDELIKHEID, WAARHEID, VERGOEDING, NIKSGOEDHEID, WAARHEIDSGELDIGHEID, WAARHEID, VERGOEDING, NIKSGEERHEID, WAARHEID, VERGOEDING, VERGOEDING, NIKSGOED, NIE DAT DIE INHOUD VAN HIERDIE DOKUMENT VRYLOOS IS.

TENLIKE WET VERBOD, BLUETOOTH SIG, SY LEDE EN HULLE AFSLUITERS ONTWERP ALLE AANSPREEKLIKHEDE VOORAF OF BETREFFENDE DIE GEBRUIK VAN HIERDIE DOKUMENT EN ENIGE INLIGTING VERVAT IN HIERDIE DOKUMENT, INSLUITEND PROVINS, PROSUS OF PROVUS, ONDERBREKING, OF VIR SPESIALE, INDIREKTE, GEVOLGENDE, GEVOLGE OF GEMEENSKAPLIKE SKADE, ALGEMEEN VEROORSAAKLIK EN ONGEVOEGD AAN DIE AANSPREEKLIKHEIDSTEORIE, EN AL IS BLUETOOTH SIG, SY LEDE, OF HULLE BETROKKE VIR DIE GESINDHEID.

Hierdie dokument is eie aan Bluetooth SIG. Hierdie dokument kan onderwerpe bevat wat intellektuele eiendom is van Bluetooth SIG en sy lede. Die verskaffing van hierdie dokument verleen geen lisensie vir enige intellektuele eiendom van Bluetooth SIG of sy lede nie.

Hierdie dokument is onderhewig aan verandering sonder kennisgewing.

Kopiereg © 2004–2019 deur Bluetooth SIG, Inc. Die Bluetooth-woordmerk en logo's is die eienaar van Bluetooth SIG, Inc. Ander handelsmerke en name van derdepartye is die eiendom van hul onderskeie eienaars.

1. Inleiding

Die Specification Management Process Document (SMPD) beskryf die prosesse wat die spesifikasie -outeurs en t.o.v.viewers moet volg om nuwe spesifikasies te ontwikkel en bestaande spesifikasies te verbeter (dws om funksionaliteit by te voeg of te verwyder of om spesifieke funksies in 'n goedgekeurde spesifikasie te verander), om goedgekeurde spesifikasies te handhaaf en om die einde van die lewe van goedgekeurde spesifikasies te bestuur. Boonop beskryf hierdie dokument die proses om te skep, t.o.v.viewen goedkeuring van witskrifte.

Daar is verskille in die spesifikasie-ontwikkelingsproses tussen die ontwikkeling van nuwe spesifikasies en die verbetering van bestaande spesifikasies as gevolg van die inherente verskille in die omvang van daardie take; hierdie verskille word in hierdie dokument belig.

Die spesifikasie-ontwikkelingsproses sluit in:

'N Vereistesfase (beskryf in Afdeling 3) om funksionele vereistes te definieer
'N Ontwikkelingsfase (beskryf in afdeling 4) om te ontwikkel en herview spesifikasies

'N Valideringsfase (beskryf in Afdeling 5) om die spesifikasies te valideer deur middel van Interoperable Prototype (IOP) toetsing
'N Aannemings- / goedkeuringsfase (beskryf in Afdeling 6) om die spesifikasies voor te lê aan die Bluetooth SIG Raad van Direkteure (BoD) vir goedkeuring / goedkeuring

Die Specification Errata Process -dokument (EPD) [3] beskryf die proses om voor te stel en herviewing specification errata, en goedkeuring daarvan as Errata Corrections (soos omskryf in die Statute [2]) volgens aangenomen spesifikasies. Tensy anders vermeld, beteken alle verwysings na errata in hierdie SMPD spesifikasie errata.

1.1 Voorrang

Die statute van Bluetooth SIG, Inc. (Bylaws) en lidmaatskapsooreenkomste [2] geniet voorkeur bo enige teenstrydige inhoud in daardie dokumente en die SMPD. Nieteenstaande enigiets in hierdie dokument, behou die BoD die uiteindelike diskresie en die gesag om tot aksie oor te gaan en besluite te neem, selfs al volg hierdie aksies en besluite niks in hierdie dokument nie, of strydig met dit, en niks in hierdie dokument beperk of beperk die BoD se onafhanklike gesag nie. en diskresie.

As daar konflik is tussen die teks in die SMPD en die figure, het die teks voorrang.

1.2 Groepe en komitees waarna verwys word

Die volgende tipes groepe word in hierdie dokument genoem: Studiegroepe (SG), Deskundige groepe (EG) en Werkgroepe (WG). 'N WG kan ook 'n subgroep hê wat aan die WG rapporteer. Net so word daar in hierdie dokument na die volgende tipes komitees verwys: Bluetooth Architectural Review Board (BARB), Bluetooth -toets en interoperabiliteit (BTI), en Bluetooth -kwalifikasie Review Raad (BQRB). Hierdie dokument verwys ook na Bluetooth SIG Technical Staff (BSTS) en die BoD.

1.3 Komitee t.o.v.views en goedkeurings

'N Komitee t.o.v.view is, isview wat deur lede van 'n komitee (gewoonlik 3 lede) uitgevoer word om binne 'n bepaalde tyd (gewoonlik 2-3 weke) terugvoer te gee, maarview Die tyd kan wissel afhangende van die lengte en kompleksiteit van die materiaal en ander prioriteite in die komitee. Die groep wat die herview en die komitee wat die review elkeen stem saam oor die duur van die review. Die groep- en komiteelede gebruik die Bluetooth SIG -gereedskap om die begin en einde van die re in kennis te stel en aan te tekenview. Die groep sal oor die algemeen komitee -terugvoer verwerk wanneer dit ontvang word. Wanneer die komitee t.o.v.view as die tyd verstryk, voltooi die groep die terugvoer van die komitee, en moet dit ook oorweeg om laat te komview terugvoer in gedagte dat die materiaal onderhewig is aan latere goedkeuring deur die komitee.

'N Komitee-goedkeuring word verkry deur 'n stemming deur die komiteelede in ooreenstemming met die werkgroepprosesdokument [4].

1.4 Kennisgewings aan lede en die toeganklikheid van materiaal

Alle kennisgewings wat ingevolge hierdie dokument aan lede verskaf word, kan per e-pos verskaf word, soos 'n periodieke tegniese opdatering. Kennisgewings wat aan alle lede verskaf moet word, sal aan alle aktiewe lede gestuur word (dws waar lidmaatskap nie opgeskort, beëindig of ingetrek is nie). Wanneer kennisgewings per e-pos gestuur word, word dit gestuur na die laaste e-posadres (soos weerspieël in Bluetooth SIG se destydse rekords) van elke persoon wat onder die lidmaatskaprekening van die lidmaatskappy geregistreer het en wat nie gekies het om e-poskennisgewings te ontvang nie. Niks in hierdie dokument verander Bluetooth SIG-verpligtinge of -vereistes met betrekking tot die verskaffing van kennisgewing ingevolge die Verordeninge of enige ander ooreenkoms tussen Bluetooth SIG en enige lid nie.

Waar hierdie dokument ook verwys na a webwebwerf wat vir alle lede toeganklik is, verwys dit na toeganklikheid vir individue wat 'n aktiewe Bluetooth SIG -rekening het. Lede wat nie 'n aktiewe rekening het nie, kan 'n rekening skep via die Bluetooth SIG webwebwerf.

1.5 Sjablone

Bluetooth SIG bied 'n sjabloon vir elke tipe dokument (bv. Spesifikasies, witskrifte, toetsdokumente) waarna in hierdie SMPD verwys word. Die sjabloon moet as basis gebruik word vir elke dokument wat volgens hierdie SMPD vervaardig word. As die korrekte sjabloon nie gebruik word nie, kan die dokument nie goedgekeur word nie. Sjablone is beskikbaar op die Bluetooth SIG webwebwerf [8].

1.6 Spesifikasiesoorte

Daar is verskillende tipes Bluetooth SIG -spesifikasies. Hierargies is alle spesifikasies afhanklik van die Bluetooth -kernspesifikasie. Spesifikasies soos tradisionele profiles; tradisionele protokolle; en GATT-gebaseerde profiles, GATT-gebaseerde dienste en GATT-gebaseerde protokolle hang alles af van die funksies in die kernspesifikasie. Ander spesifikasies, soos Mesh Model -spesifikasies, is afhanklik van die Mesh Profile spesifikasie wat weer afhang van die kernspesifikasie.

Die Core Specification Supplement (CSS) spesifikasie definieer datatipes, dataformate en algemene pro'sfile en diensfoutkodes wat deur die kernspesifikasie en ander spesifikasies gebruik word en self geen gedrag bepaal nie.

Die GATT Specification Supplement (GSS) spesifikasie definieer kenmerkende en beskrywende formate wat deur Pro gebruik wordfiles en dienste en definieer nie self enige gedrag nie.
Die Mesh Device Properties (MDP) spesifikasie definieer maas eienskappe wat deur die Mesh Pro gebruik wordfile en Mesh Model spesifikasies en definieer nie self enige gedrag nie.

2. oorview

Hierdie afdeling bied 'n oorview van die prosesse en is nie bedoel om alle besonderhede in te sluit nie.

Figuur 2.1 toon die ses hooffases waaruit die spesifikasiebestuursproses bestaan.

Die eerste vier fases vind plaas tydens die spesifikasie-ontwikkelingsproses en bestaan uit die Vereistesfase (Afdeling 3), die Ontwikkelingsfase (Afdeling 4), die Valideringsfase (Afdeling 5) en die Aannemings- / Goedkeuringsfase (Afdeling 6). Dit word gevolg deur twee fases na aanneming: die spesifikasie-instandhoudingsfase (afdeling 7) en die spesifikasie-einde-van-lewe-fase (afdeling 8).

Figuur 2.2 illustreer besonderhede van die vier fases in die spesifikasie-ontwikkelingsproses. Die grys blokkies dui die belangrikste aflewerings vir elke fase aan. Die oranje blokkies som die mylpale op.

In die vereiste-fase (beskryf in Afdeling 3) begin 'n voorstel om nuwe werk te begin ('n nuwe werkvoorstel (NWP)) die ontwikkelingsproses van spesifikasies deur die gebruikerscenario's te definieer wat geaktiveer moet word as die nuwe werk voortgaan. As die NWP goedgekeur word, skep 'n toegewysde groep 'n dokument vir funksionele vereistes (FRD). Sodra die FRD goedgekeur en aan 'n groep toegewys is, begin die ontwikkelingsfase.

Tydens die ontwikkelingsfase (beskryf in afdeling 4), vorder spesifikasie -ontwikkeling deur 'n reeks stages (0.5/DIPD tot 0.9/CR) wat uitloop op 'n volledige konsep van die spesifikasie. Die 0.9/CR -spesifikasie word aan alle lede beskikbaar gestel en dan aan die BoD voorgelê wat die spesifikasie vir goedkeuring oorweeg. Sodra dit goedgekeur is, begin die bekragtigingsfase.

Tydens die bekragtigingsfase van spesifikasie-ontwikkeling (beskryf in afdeling 5), word die BoD-goedgekeurde 0.9/CR-spesifikasie aan alle lede beskikbaar gestel omview en bekragtig, en Lid Review begin word. Validasie word uitgevoer deur interoperabiliteitstoetsing (IOP) tussen prototipes wat deur lede gebou is. Sodra die IOP -toets voltooi is (indien nodig vir die spesifikasie) en BARB die IOP -toetsverslag goedkeur, begin die aanvaardings-/goedkeuringsfase.

Gedurende die aannemings- / goedkeuringsfase (beskryf in Afdeling 6) word die spesifikasie en verwante toetsdokumente gefinaliseer; Goedkeuring van BARB, BQRB en BTI word ontvang; en die finale spesifikasiepakket word aan die BoD voorgelê wat die spesifikasie vir goedkeuring oorweeg (dws finale goedkeuring).

'N Spesifikasie moet moontlik terugkeer na 'n vorige fasetage as beduidende veranderinge aangebring word. In sommige gevalle kan dit ook moontlik wees om afstand te doen van 'n deel van 'n fase soos beskryf in Afdeling 4.4.

Die spesifikasie-instandhoudingsfase (beskryf in Afdeling 7) begin nadat 'n spesifikasie deur die BoD aanvaar is. Gedurende hierdie fase word potensiële foute in 'n aangenome spesifikasie gerapporteer en geëvalueer, en (indien nodig) word Errata-regstellings aan die spesifikasie aangebring. Die spesifikasie-instandhoudingsfase duur voort totdat die spesifikasie verouderd is of ingetrek word (sien die einde van die lewensfase van spesifikasie in die volgende paragraaf).

Die spesifikasie-einde-van-die-lewe-fase (beskryf in Afdeling 8) beskryf die proses om aangenome spesifikasies te verswak en terug te trek.

3. Vereistesfase

Die vereiste-fase begin óf met 'n NWP (wat die begeerte om werk aan een of meer gebruikerscenario's in te stel), óf na 'n vasstelling dat die gewenste nuwe werk reeds deur hul WG-handves gedek word. As 'n WG wil begin met nuwe werk wat volgens haar reeds binne die bestek van sy WG-handves is, moet die WG die proses volg wat in Afdeling 3.1 omskryf word om direk voort te gaan met die ontwikkeling van 'n FRD. Vir alle ander werkitems moet die WG die proses volg wat in Afdeling 3.2 omskryf word. Die FRD definieer die omvang van die funksionele vereistes wat gebruik word om spesifikasies in die ontwikkelingsfase te bou. Die vereistesfase word in Figuur 3.1 geïllustreer.

3.1 Nuwe werk wat deur 'n WG-handves gedek word

Wanneer 'n WG met nuwe werk wil begin en redelikerwys glo dat die funksionaliteit wat hy wil byvoeg reeds binne die bestek van sy WG-handves is, kan die WG aan die FRD begin, mits hulle BARB dadelik in kennis stel. Die WG sal in sy kennisgewing aan BARB 'n beskrywing van die voorgestelde nuwe werk en 'n eksemplaar van die WG-handves met taal bevat, wat hulle magtig om met die nuwe werk te begin, insluit.

As BARB die WG se ontleding verwerp, moet die WG die werk aan die FRD staak en voortgaan met die NWP-proses soos uiteengesit in Afdeling 3.2. As BARB die ontleding van die WG goedkeur, sal die WG BSTS onmiddellik in kennis stel (per e-pos na specification.manager@bluetooth.com) en BSTS sal die item by die volgende BoD-agenda voeg.

Die WG sal in sy kennisgewing aan BSTS dieselfde inligting insluit wat dit aan BARB verskaf het. As die BoD die WG se ontleding verwerp, moet die WG die werk aan die FRD staak en voortgaan met die NWP-proses soos uiteengesit in Afdeling 3.2. As die BoD die WG se ontleding goedkeur, kan die WG voortgaan om aan die FRD te werk soos uiteengesit in Afdeling 3.3.

3.2 Nuwe werkvoorstel (NWP)

Elke lid, WG, SG of EG mag 'n NWP skep en indien (via die Bluetooth SIG webwebwerf [10]). 'N NWP moet ten minste inligting bevat oor die volgende met behulp van die amptelike sjabloon in [8]:

Gebruikerscenario's
Lid se verbintenis om die FRD te ontwikkel en op watter gebied (e) (bv. Bydraer, Skrywer, Reviewprototipering)

Voorgestelde leierskap van die FRD-werk
Voorgestelde groepopdrag vir die FRD-werk
E-posadres van primêre outeur (s)

Let wel: Begeleiding oor die NWP -proses is beskikbaar op die Bluetooth SIG webwebwerf [10].

BSTS sal die volgende take verrig tydens die ontwikkeling van die NWP:

Gee die outeur (s) 'n ontvangsbewys (gewoonlik binne sewe kalenderdae na ontvangs) en gee 'n uiteensetting van die volgende stappe.

Werk indien nodig saam met die outeur (s) sodat die NWP duidelik en volledig is. Dit kan verskillende herhalings van die NWP vereis.
As die NWP verklarings bevat oor foute in aangenome Bluetooth -spesifikasies, werk saam met die outeur (s) aan file inskrywings in die errata -stelsel.
As opgemerk word dat die NWP werk wat reeds aan die gang is of reeds voltooi is, dupliseer, moet u die outeur (s) van die ander werk in kennis stel vir hul evaluering.

Pos die NWP na die NWP webwebwerf toeganklik vir alle lede.
Stel alle lede in kennis dat die NWP beskikbaar is vir herview en of addisionele lidverbintenis tot die ontwikkeling van die FRD nodig is.

Lede kan die outeur (s) kontak om vrae te stel of om terugvoer oor die NWP te gee.

Ten minste drie lidmaatskappye moet daartoe verbind om deel te neem aan die voltooiing van die gevolglike FRD, sodat die NWP kandidaat kan word vir BoD-goedkeuring, en ten minste een lidmaatskappy moet 'n geassosieerde of promotor-lid wees. Na goedkeuring van BoD van die NWP, sal die BoD die NWP aan 'n bestaande WG-subgroep of SG toewys om aan die FRD te werk (beskryf in Afdeling 3.3). As daar nie 'n toepaslike WG-subgroep of SG bestaan nie, kan een geskep word.

Vir NWP's wat voldoende lidverbintenis het, sal BSTS die volgende addisionele take verrig:

Stel BARB, en die groep waaraan die NWP aanbeveel word, ten minste 13 dae voor dat die BoD voorstel dat dit goedgekeur word, van die hangende NWP-goedkeuring. Dit word gedoen om 'n geleentheid te bied vir terugvoer op gebiede soos die voorgestelde groep, of die NWP reeds deur bestaande werk gedek word, ens.

Dien die voltooide NWP by die BoD in.

Indien die NWP ingedien word deur lede wat nie aan 'n groep verbonde is nie, moet een van die lede die NWP aan die BoD voorlê.
As die NWP deur 'n groep ingedien word, moet die groepvoorsitter die NWP aan die BoD voorlê.

Nooi die BARB-voorsitter en die voorsitters van die groep, waaraan die NWP vir opdrag aanbeveel word, na die BoD-vergadering.
As die NWP deur die BoD goedgekeur en toegewys is, stel die groep in kennis waaraan dit toegewys is; die outeur (s); die lede wat in die NWP geïdentifiseer is as verbind tot die ontwikkeling van ooreenstemmende FRD; en as die NWP deur 'n groep voorgestel word, die groep van die uitslag en die volgende stappe.

Dateer die status op die NWP op nadat 'n NWP deur die BoD goedgekeur is webwebwerf.

Enige NWP kan na goeddunke deur die BoD verwerp word, bvampAs gevolg van hulpbronbeperkings, as die werk reeds volledig voltooi is, is die werk buite die omvang van die beheersdokumente van Bluetooth SIG (bv. die Application Programming Interface (API)) [2], of moet die voorgestelde werk filed as 'n erratum. As die NWP verwerp word, sal BSTS die outeur (s), die lede wat in die NWP geïdentifiseer is, in kennis stel om die ooreenstemmende FRD te ontwikkel, en, indien die NWP deur 'n groep voorgestel word, die groep. Die kennisgewing bevat enige redes vir die verwerping. Die outeur (s), toegewyde lede of groep kan tyd op die BoD -agenda versoek om appèl teen die verwerping aan te teken.

As 'n lid of groep wil voorstel om 'n funksie uit 'n aangenome spesifikasie te verwyder, moet die groep of lid 'n NWP voorberei. Die NWP moet 'n ontleding insluit van die impak wat die verwydering op agteruitversoenbaarheid en interoperabiliteit sal hê, insluitend 'n ontleding van die impak op toetsgevalle.

NWP's is nie nodig vir die verbetering van die CSS-, GSS- of MDP-spesifikasies nie: gewoonlik is opdaterings aan die CSS-, GSS- of MDP-spesifikasies die gevolg van opdaterings na ander spesifikasies wat hul eie NWP's het.

3.3 Funksionele vereistes dokument (FRD)

FRD's definieer die funksionele vereistes om gebruikerscenario's moontlik te maak. 'N FRD moet ten minste inligting oor die volgende insluit met behulp van die amptelike sjabloon in [8]:

Gebruikerscenario's
Funksionele vereistes gebaseer op die gebruikerscenario's

Verbintenis van die lid om die resultate te ontwikkel
Opsionele prototipe-ondersteuning deur lede vir die verwagte rolle
Aanbeveel WG om die resulterende spesifikasie (s) te ontwikkel

FRD ontwikkeling

FRD's word geskep deur die toegewysde WG-subgroep of SG-lede met redaksionele ondersteuning van BSTS. Enige lid wat belangstel om aan die FRD-ontwikkeling deel te neem, kan by die groep aansluit.

FRD's moet 'n verbintenis van minstens twee (hoewel drie word aangemoedig) aangeslote lidmaatskappye of promotorsvlak-lidmaatskappye aandui om deel te neem aan die ontwikkeling van die resulterende spesifikasie. WG's of SG's wat 'n FRD indien, moet poog om breë steun te verkry van groeplidmaatskappye wat die beoogde teikenbedryfsegment verteenwoordig wat in die FRD geïdentifiseer is.

Nuwe funksies wat in 'n FRD voorgestel word, moet ondersteun word op soveel vervoer en bestaande toestelle as moontlik. Dit sluit byvoorbeeld inample, ondersteun GATT-gebaseerde profiles en dienste op sowel die Basic Rate/Extended Data Rate (BR/EDR) vervoer as die Bluetooth Low Energy (LE) vervoer. As nuwe funksies nie voldoende lidondersteuning vir 'n vervoer ontbreek nie, bvampAs gevolg van 'n gebrek aan lidverbintenis om die gebruik van die vervoer te definieer of 'n potensieel onvoldoende aantal IOP -toetsplatforms vir een of meer rolle, kan ondersteuning vir die vervoer van die FRD uitgesluit word.

Tensy andersins geregverdig, nuwe funksies, profiles en dienste moet voldoen aan die vereistes vir terugwaartse verenigbaarheid wat in afdeling 3.3.2 beskryf word.

Die WG of SG moet die FRD by BARB indien vir herverklaringview en goedkeuring. BARB moet die FRD goedkeur of verwerp op grond van sy ingenieursoordeel. As dit deur BARB goedgekeur word, sal die FRD aan alle lede beskikbaar gestel word en kennisgewing van die beskikbaarheid daarvan sal deur BSTS uitgereik word.

FRD's is nie nodig vir die verbetering van die CSS-, GSS- of MDP-spesifikasies nie: gewoonlik is opdaterings aan die CSS-, GSS- of MDP-spesifikasies die gevolg van opdaterings na ander spesifikasies wat hul eie FRD's het.

Vereistes vir agteruitversoenbaarheid

Terugwaartse versoenbaarheid vir BR / EDR

Vir BR / EDR-werking word die vereiste agtertoe-versoenbaarheid gedefinieer as interoperasie met die BR / EDR-gedeelte van die Bluetooth Core Specification v1.1 en later.

Terugwaartse versoenbaarheid vir Bluetooth Low Energy

Vir LE-werking word die vereiste agtertoe-versoenbaarheid gedefinieer as interoperasie met die LE-gedeelte van die Bluetooth Core Specification v4.0 en later.

Agterversoenbaarheid vir ander spesifikasies as die kernspesifikasie

Vir ander spesifikasies as die Bluetooth -kernspesifikasie, moet 'n terugwaartse verenigbaarheid van 'n gegewe weergawe gehandhaaf word met alle vorige weergawes met dieselfde groot weergawenommer. Vir eksampweergawe 1.3 moet versoenbaar wees met weergawes 1.2, 1.1 en 1.0, maar weergawe 2.0 is moontlik nie versoenbaar met weergawes 1.0, 1.1, 1.2 en 1.3 nie. Let daarop dat 'n toename in die hoofversieningsnommer van die kernspesifikasie nie 'n gebrek aan agteruitkompatibiliteit met vorige weergawes impliseer nie.

Vrystelling van die vereistes vir agteruitversoenbaarheid

Die WG of SG kan voorstel om spesifieke funksionaliteit van die agterwaartse verenigbaarheidsvereiste vry te stel indien dit regverdig word. Vir eksampAs dit blyk dat die funksionaliteit lae markaanvaardingskoerse het, of as gevolg van interoperabiliteitsprobleme, is dit beter om funksionaliteit te verwyder of te vervang as om funksionaliteit aan te pas. Die WG of SG moet enige vrystellings van agterwaartse verenigbaarheid in die FRD insluit, wat deur BARB goedgekeur is na goedkeuring van die FRD. Enige BARB-goedgekeurde vrystellings sal aan die BoD voorgelê word vir goedkeuring by die 0.9/CR Stage.

3.4 Werkgroephandves

Wanneer BARB 'n FRD goedkeur wat voorgestel word om aan 'n bestaande WG toegewys te word, moet WG 'n konsep-opdatering opstel vir sy handves om die nuwe funksies tot die bestek toe te voeg (tensy die BoD voorheen die WG se analise goedkeur dat 'n WG-handves-opdatering is nie benodig nie). Wanneer BARB egter 'n FRD goedkeur wat voorgestel word om aan 'n nuwe WG toegeken te word, moet BARB en lede wat belangstel om die funksionaliteit wat in die FRD uiteengesit is, te ontwikkel 'n konsephandves opstel vir 'n nuwe WG met die nuwe funksies wat in die handvesomvang opgeneem word. .

Sodra die nuwe of bygewerkte WG -handves voorberei is, moet dit by BARB ingedien word vir herverklaringview en goedkeuring. Sodra BARB die handves goedgekeur het, sal die konsep van die nuwe of bygewerkte WG -handves aan die BoD voorgelê word vir goedkeuring.

Sodra die BoD die handves goedkeur, moet die WG waaraan die spesifikasie-ontwikkelingswerk deur die BoD toegeken is, nou saamwerk met die groep wat die FRD voorberei het indien enige nodige opdaterings of toeligtings aan die FRD benodig word. Indien 'n FRD-opdatering tydens die ontwikkelingsfase benodig word, moet die prosesse soos uiteengesit in Afdeling 3.3 en hierdie afdeling gevolg word; spesifikasie-ontwikkeling kan egter plaasvind parallel met die FRD- en WG-handvesopdaterings.

3.5 Vereistes Fase-uitgangsvereistes

Die vereistesfase is voltooi en die ontwikkelingsfase begin wanneer 'n WG-handves met die nodige ruimte vir die FRD deur die BoD bevestig of goedgekeur word en daar is aan die volgende vereistes voldoen:

Die NWP is óf deur die BoD goedgekeur, óf die BoD het ingestem dat 'n NWP onnodig is.

Die FRD en ooreenstemmende WG-handves is deur BARB goedgekeur.

4. Ontwikkelingsfase

Gedurende die ontwikkelingsfase skep die toegekende WG (s) die nuwe spesifikasie en / of verbeter dit 'n bestaande spesifikasie. Die FRD definieer die vereistes van die nuwe of verbeterde Bluetooth-spesifikasie. Geen funksionaliteit word toegelaat in die spesifikasie wat nie redelikerwys verband hou met die vereistes in die FRD nie. Die doel is om 'n 0.9 / CR-spesifikasie op te stel wat gereed is vir die Valideringsfase (beskryf in Afdeling 5) aan die einde van die Ontwikkelingsfase.
Gedurende die ontwikkelingsfase vorder 'n spesifikasie (of spesifikasieverbetering) deur drie stages.

Vir 'n nuwe spesifikasie, die drie stage is:

0.5 Stage
0.7 Stage

0.9 Stage

Vir 'n spesifikasieverbetering, die drie stage is:

Konsepverbeteringsvoorsteldokument (DIPD) S.tage

Finale verbeteringsvoorstel dokument (FIPD) S.tage
Veranderingsversoek (CR) Stage

Elke stage word verder beskryf in die onderafdelings wat volg. Figuur 4.1 hieronder illustreer die verskillende dokumente wat die WG by elke s sal voorbereitage.

Figuur 4.1: oorview van die spesifikasie stagwat tydens die ontwikkelingsfase plaasvind

Die rol van BARB gedurende die hele spesifikasie-ontwikkelingsproses is om WG's met advies en tegniese hulp te verleen. WG's kan te eniger tyd 'n versoek aan BARB rig vir tegniese advies rakende spesifikasie-ontwikkeling en argitektoniese konsepte om in 'n spesifikasie gebruik te word. WG's word veral aangemoedig om vroeë terugvoer van BARB in te win vir funksies wat ingewikkelder argitektoniese oorwegings het.

4.1 0.5/DIPD Stage

Tydens die 0.5/DIPD Stage, sal die WG die volgende ontwikkel met behulp van die amptelike sjablone in [8]:

Vir 'n nuwe spesifikasie, 'n konsep van die 0.5-spesifikasie, wat ten minste inligting oor die volgende moet bevat:

Argitektuur om die vereistes soos uiteengesit in die FRD te dek

Dienstoegangspunte is vir protokolle gedefinieer
Vir dienste, blootgestelde data en gedrag
Vir profiles, protokolle geïdentifiseer en funksionaliteit gespesifiseer

2. Vir 'n spesifikasieverbetering, 'n konsep van die DIPD, wat ten minste inligting oor die volgende moet bevat:

Agtergrond: Die omvang van die werk, die doelstellings wat die werk rig en hoe hierdie spesifieke voorstel in die omvang pas
verbyview van voorstel: 'N Opsomming van die uitgebreide funksionaliteit (toegevoegde buigsaamheid, verbeterde werkverrigting, ens.) Wat deur die DIPD aangebied word, met 'n duidelike beskrywing van hoe die nuwe funksionaliteit in die huidige weergawe pas. As die WG verskeie voorstelle geëvalueer het, moet hierdie voorstelle ingesluit word om BARB die geleentheid te gee om vas te stel of daar voldoende sorgvuldigheid gedoen is by die keuse van die voorkeurvoorstel.

Dekking van vereistes: 'N Opsomming van die dekking van funksionele vereistes wat deur die voorstel gegee word, met verwysing na die toepaslike stelselvereistes en gebruiksscenario's in die gepaardgaande FRD
Probleemomskrywing: Probleemstelling opgelos deur die voorstel (s)
Seleksiekriteria: 'N Verklaring rakende die seleksie / prestasiekriteria uit gepaardgaande evalueringsmetrieke wat die keuringsproses gelei het

Regverdiging van keuse: 'N Ondersoek van die evalueringsmaatstawwe wat die keuse tussen voorstelle regverdig en die kompromieë toon
Beskrywing: 'N Beskrywing van die funksionaliteit en uitgebreide protokolle. Hierdie afdeling kan aanpas by verskillende behoeftes deur toepaslike onderafdelings by te voeg.

3. Toetsstrategie: 'N Beskrywing van die funksionaliteit wat voorgestel word om getoets te word (of nie getoets word nie) as deel van die Bluetooth -kwalifikasieprogram en hoe die funksionaliteit voorgestel word om getoets te word (bv. as die toetse toegeskryf word aan ooreenstemming- of interoperabiliteitstoetse of 'n kombinasie van albei). Dit kan in 'n aparte dokument of 'n aparte afdeling binne die 0.5/DIPD -spesifikasie wees. Die konvensies wat in 'n toetsstrategie gebruik moet word, word beskryf in die toetsstrategie en terminologie oorview dokument (TSTO) [5].

Die primêre gehoor van die dokumente by hierdie atage is die WG -lede en BARB wat t.o.v.view die argitektoniese voorstelle en vereiste dekking, en BTI watviews die toetsstrategie. In die meeste gevalle word die dokumente by hierdie atage is nie bedoel om teks te bevat wat beplan word om in die finale spesifikasie ingesluit te word nie.

BSTS moet t.o.v.view alle dokumente in ooreenstemming met die Bluetooth -riglyne [1] en identifiseer probleme waarmee die WG aandag moet gee. BARB moet t.o.v.view die 0.5/DIPD spesifikasie. Vir 'n spesifikasieverbetering, moet BARB ook review die DIPD vir voldoening aan die vereistes vir agterwaartse verenigbaarheid wat in afdeling 3.3.2 beskryf word. BTI moet review die toetsstrategie.

BARB moet die 0.5/DIPD -spesifikasie goedkeur of verwerp op grond van sy ingenieursoordeel. As dit deur BARB goedgekeur word, sal die 0.5/DIPD -spesifikasie op die Bluetooth SIG beskikbaar gestel word webwebwerf aan alle geassosieerde en promotor -lede en kennisgewing van die beskikbaarheid daarvan sal deur BSTS uitgereik word. By die 0.5/DIPD Stage, goedkeuring van die toetsstrategie is nie nodig nie.
Die 0.5/DIPD Stage is nie nodig vir verbeterings aan die CSS-, GSS- of MDP -spesifikasies nie

0.5/DIPD Stage uitgangsvereistes

Die 0.5/DIPD Stage is voltooi en die 0.7/FIPD Stage begin wanneer aan die volgende uitgangsvereistes voldoen word:

BSTS het reviewvolgens die 0.5/DIPD spesifikasie en toetsstrategie.

BARB het die 0.5 / DIPD-spesifikasie goedgekeur.
BTI het sy review van die toetsstrategie.
BSTS het die goedgekeurde 0.5 / DIPD-spesifikasie aan alle geassosieerde en promotorlede beskikbaar gestel.

4.2 0.7/FIPD Stage

Tydens die 0.7/FIPD Stage, sal die WG die volgende ontwikkel met behulp van die amptelike sjablone in [8]:

Vir 'n nuwe spesifikasie, 'n konsep van die 0.7-spesifikasie, wat ten minste inligting oor die volgende moet bevat:

'N Beskrywing van alle veranderinge wat aangebring is sedert die BARB-goedgekeurde 0.5, insluitend nuwe of gewysigde voorstelle, keuringskriteria en regverdiging van keuse. Veranderinge moet op dieselfde detailvlak beskryf word as wat in die 0.5 S vereis wordtage.

Alle funksionele vereistes van die FRD aangespreek.

2. Vir 'n spesifikasieverbetering, 'n konsep van die FIPD, wat ten minste inligting oor die volgende moet bevat:

'N Beskrywing van alle veranderinge wat sedert die BARB-goedgekeurde DIPD aangebring is, insluitend nuwe of gewysigde voorstelle, keuringskriteria en regverdiging van keuse. Veranderinge moet op dieselfde detailvlak beskryf word as wat in die DIPD S vereis wordtage.

Soos nodig, verder ontwikkelde gebiede wat in Afdeling 4.1 met betrekking tot die DIPD beskryf is.
'N Volledige beskrywing van die verbetering.
'N Opgedateerde argitektoniese beskrywing.
Alle funksionele vereistes van die FRD aangespreek.

3. 0.7 / FIPD-toetsdokumente, wat ten minste inligting oor die volgende moet bevat:

'N Toetsuite, bestaande uit 'n lys toetsdoeleindes soos beskryf in die TSTO [5].
'N Implementeringsverklaring (ICS), soos beskryf in die TSTO [5].

Vir die verbetering van spesifikasies kan die Test Suite en ICS as afsonderlike dokumente of as addisionele afdelings in die FIPD verskaf word.

Die primêre gehoor van die dokumente wat op hierdie atage is die WG -lede en BARB wat t.o.v.view die volledige beskrywing van die funksie of verbetering, insluitend teks wat beplan word om in die finale spesifikasie ingesluit te word. BTI is die gehoor vir review van die toetsdokumente.

BSTS sal review die nuwe of gewysigde dele van die 0.7/FIPD -spesifikasie en toetsdokumente vir ooreenstemming met die Bluetooth -riglyne, insluitend taalkonvensies wat deur Bluetooth SIG vasgestel is. BARB sal review die 0.7/FIPD spesifikasie.

BSTS sal die WG help om die 0.7 / FIPD-toetsdokumente op te stel in ooreenstemming met die TSTO [5].

BTI moet review die 0.7/FIPD -toetsdokumente. Die WG moet die 0.7/FIPD -spesifikasie aan BTI verskaf as 'n verwysing wanneer reviewingevolge die 0.7/FIPD -toetsdokumente, wat BTI heroorweegview in ooreenstemming met die BTI Specification Review Verwerk Kontrolelys [6].

Nadat BARB sy review van die 0.7/FIPD -spesifikasie en BTI het sy re voltooiview van die 0.7/FIPD -toetsdokumente, sal BSTS die reviewed 0.7/FIPD -spesifikasie beskikbaar vir alle Associate- en Promotor -lede.

Die 0.7/FIPD Stage is nie nodig vir verbeterings aan CSS-, GSS- of MDP -spesifikasies nie.

0.7/FIPD Stage uitgangsvereistes

Die 0.7/FIPD Stage is voltooi en die 0.9/CR Stage begin wanneer aan die volgende uitgangsvereistes voldoen word:

BSTS het reviewvolgens die 0.7/FIPD -spesifikasie en toetsdokumente.
BARB het reviewvolgens die 0.7/FIPD spesifikasie.
BTI het reviewin die 0.7/FIPD Test Suite (toetsdoeleindes) en 0.7/FIPD ICS.
BSTS het die reviewed 0.7/FIPD -spesifikasie beskikbaar vir alle Associate- en Promotor -lede.

4.3 0.9/CR Stage

Daar is twee soorte CR's: 'n Geïntegreerde CR, wat 'n dokument is wat verander word en 'n volledige spesifikasie wat aangeneem word, wat alle veranderinge sedert die vorige weergawe toon, en 'n verkorte CR, wat 'n dokument is wat instruksies gee om slegs die geaffekteerde gedeeltes van die die spesifikasie weergawe waarop die CR gebaseer is.

Tydens die 0.9/CR Stage, sal die WG die volgende ontwikkel met behulp van die amptelike sjablone in [8]:

Vir 'n nuwe spesifikasie, 'n volledige volledige konsep van die 0.9-spesifikasie, wat ten minste inligting oor die volgende moet bevat:

'N Beskrywing van alle veranderinge wat sedert die BARB-re aangebring isviewed 0.7 spesifikasie (of sedert die 0.5 spesifikasie as die produksie van die 0.7 spesifikasie geweier is), insluitend nuwe of
gewysigde voorstelle, keuringskriteria en regverdiging van keuse. Veranderinge moet op dieselfde detailvlak beskryf word as wat in die 0.5 S vereis wordtage en 0.7 S.tage.

2. Vir 'n spesifikasieverbetering:

'N Geïntegreerde CR, wat ten minste inligting oor die volgende moet bevat:
'N Beskrywing van alle veranderinge wat sedert die BARB-re aangebring isviewed FIPD (of sedert die DIPD as daar van die FIPD afstand gedoen is) insluitend nuwe of gewysigde voorstelle, keuringskriteria en regverdiging van keuse. Veranderinge moet op dieselfde detailvlak beskryf word as wat in die DIPD S vereis wordtage en FIPD Stage.
Alle wysigings word voorgestel aan die spesifikasie wat voorheen aangeneem is deur gebruik te maak van veranderingsopsporing.
Alle goedgekeurde tegniese foute (met elke erratum waarna 'n erratum-nommer verwys word), getoon met behulp van verandering-opsporing, wat nog nie opgeneem moet word in die voorheen aangenome spesifikasie-weergawe nie, en die impakteks wat verband hou met die verbetering van die spesifikasie; of wat andersins IOP-toetsing beïnvloed.

3. Of 'n verkorte CR, wat ten minste inligting oor die volgende moet bevat:

'N Beskrywing van alle veranderinge wat sedert die BARB-re aangebring isviewed FIPD (of sedert die DIPD as daar van die FIPD afstand gedoen is) insluitend nuwe of gewysigde voorstelle, keuringskriteria en regverdiging van keuse. Veranderinge moet op dieselfde detailvlak beskryf word as wat in die DIPD S vereis wordtage en FIPD Stage.
Alle veranderinge wat voorgestel word in elke betrokke afdeling en paragraaf van die spesifikasie wat die CR voorstel om te verander.
Alle goedgekeurde tegniese errata (met elke erratum waarna 'n erratum-nommer verwys word), getoon met behulp van opmaak, wat nog nie opgeneem is in die weergawe wat voorheen aangeneem is nie, en die impaksteks wat verband hou met die verbetering van die spesifikasie; of wat andersins IOP-toetsing beïnvloed.

4. 'n CSS CR (indien nuwe inskrywings deur die spesifikasie vereis word), wat in 'n verkorte CR van die spesifikasie ingebed kan wees.
5. 'n GSS-CR (indien nuwe inskrywings deur die spesifikasie vereis word), wat in 'n verkorte CR van die spesifikasie ingebed kan wees.
6. 'n MDP-CR (indien nuwe inskrywings deur die spesifikasie vereis word), wat in 'n verkorte CR van die spesifikasie ingebed kan wees.
7. 0.9 / CR-toetsdokumente, wat ten minste inligting oor die volgende moet bevat met behulp van die amptelike sjabloon in [8]:

Die 0.9 / CR Test Suite, wat volledige inhoudsake bevat en die gepaardgaande Toetsgeval Mapping Table (TCMT), soos beskryf in die TSTO [5].
Die 0.9 / CR ICS, soos beskryf in die TSTO [5].
As die konfigurasie van die toetse spesifieke parameters benodig vir die Implementation Under Test (IUT), is die 0.9 / CR Implementation eXtra Information for Testing (IXIT).
Die 0.9 / CR Test Case Reference List (TCRL) (opsioneel vir kernspesifikasie-opdaterings).

8. 'n Toetsdekking-analise wat aandui watter spesifikasievereistes binne die 0.9 / CR Test Suite getoets word of nie getoets word nie (vir die verbetering van die spesifikasie, moet die toetsdekking-analise slegs nuut toegevoegde en geaffekteerde funksies insluit, en nie die onaangeraakte areas van die oorspronklike spesifikasie).
9. 'n IOP-toetsplan.

Vir spesifikasieverbeterings kan die Test Suite, ICS en IXIT óf as afsonderlike dokumente óf as addisionele afdelings in die verkorte CR verskaf word.

In die meeste gevalle moet 'n geïntegreerde of afgekorte CR gebaseer wees op die weergawe van die spesifikasie wat voorheen aangeneem is, maar dit kan ook gebaseer wees op die nuutste tussentydse konsep. Die nuutste weergawenommer van die konsepspesifikasie moet die weergawenommer wees wat verband hou met 'n weergawe van die dokument wat gevries is en wat nie mettertyd sal verander nie. Andersins, addisionele identifiserende inligting (soos die dokumentdatum en a URL na 'n permanente plek) moet voorsien word om die spesifieke "basislyn" weergawe te identifiseer. As 'n tussentydse konsep gebruik word, moet enige veranderinge wat nie direk verband hou met die CR binne 'n gegewe afdeling wat die CR aanpas nie, ingesluit word, maar dit is nie nodig om met behulp van opmaak te wys nie. As die relevante gedeeltes van die tussentydse konsep later bygewerk word, moet die CR opgedateer word om die opdaterings van die tussentydse konsep te weerspieël.

Die ideaal is dat verkorte CR-materiaal onderskeidelik voor die Validasie-fase in 'n konsep van die volledige spesifikasie en die volledige toetsdokumente geïntegreer word, maar dit kan ook aan die begin van die Validation-fase geïntegreer word. As daar verskeie funksies ontwikkel word vir 'n spesifikasie (bv. Die kernspesifikasie), kan dit wenslik wees om die funksies in 'n enkele konsep te integreer nadat die IOP-toets voltooi is.

BSTS sal review die 0.9/CR -spesifikasie en toetsdokumente vir ooreenstemming met die Bluetooth -riglyne vir opstel. Dan sal BARB weerview die 0.9/CR -spesifikasie wat later deur die IOP -toetsplan gevolg word (soos beskryf in afdeling 4.3.1). Sodra die 0.9/CR -spesifikasie deur die WG by BARB ingedien is vir herverklaringview, BSTS sal dit vir alle lede toeganklik maak om te herview en stel alle lede in kennis van die beskikbaarheid daarvan. Vanaf hierdie punt in die spesifikasie -ontwikkelingsproses, sal BSTS konsepte van die spesifikasie wat aan BARB voorgelê is, beskikbaar stel aan alle lede met periodieke kennisgewings wat aan alle lede gestuur word.

Vir 'n spesifikasieverbetering, sal die WG die BoD aanbeveel of vorige weergawes van die spesifikasie afgekeur of teruggetrek moet word, met inbegrip van die tegniese redes vir die aanbeveling (s).

BARB sal review die WG se ontleding van die nakoming van die 0.9/CR -spesifikasie aan die vereistes in die FRD, moontlike veiligheidskwessies, regulatoriese kwessies, die nakoming van die Bluetooth -argitektuur, en, vir 'n verbetering van die spesifikasie, die nakoming van die vereistes vir agterwaartse verenigbaarheid wat in afdeling 3.3.2 beskryf word .XNUMX. As BARB moontlike veiligheidskwessies identifiseer, sal BARB BSTS in kennis stel vir herverklaringview en koördinering met die Security Expert Group; en as BARB enige regulatoriese implikasies identifiseer, sal BARB BSTS in kennis stel om herview en koördineer met die regulerende komitee en Bluetooth SIG se regsadviseur. BARB moet die 0.9/CR spesifikasie goedkeur of verwerp op grond van sy ingenieursoordeel en die inagneming van die faktore wat in hierdie paragraaf beskryf word.

BTI sal review die 0.9/CR -toetsdokumente met inagneming van die toetsdekking -analise. BTI moet die 0.9/CR -toetsdokumente goedkeur of verwerp.

Nadat BARB die 0.9/CR -spesifikasie goedgekeur het, dien die WG die IOP -toetsplan by BARB in virview.

Die BARB-goedgekeurde 0.9 / CR-spesifikasie word aan die BoD voorgelê om die aanvang van IOP-toetsing en die publikasie van die 0.9 / CR-spesifikasie aan alle lede goed te keur.

Om moontlike regskwessies uit te lig, kan WG's 'n spesifikasie aanvraview deur die regsadviseur van Bluetooth SIG (legal review) voor die verpligte wetlike review vind plaas tydens die aannemings-/goedkeuringsfase. Vir die verbetering van spesifikasies is die wetlike t.o.v.view moet op 'n geïntegreerde CR (in teenstelling met 'n verkorte CR) gedoen word, en dit moet so vooraf as moontlik vooraf beplan word, sodat hulpbronne beskikbaar is.

IOP-toetsplan

Die WG sal 'n geskrewe IOP -toetsplan ontwikkel wat aan al die vereistes wat hieronder gedefinieer word, moet voldoen vir gebruik tydens die validasiefase by die IOP -toetsgeleenthede. WG's moet die IOP -toetsplan by BARB indien vir heroorwegingview voordat die IOP -toetsgebeurtenis (s) begin. Vir eenvoudige spesifikasieverbeterings (veral dié wat nie nodig is om enige toetsgevalle in die Test Suite te wysig of by te voeg nie), is IOP -toetsing dalk nie nodig nie, en kan die WG 'n versoek aan BARB indien om 'n afstanddoening van IOP -toetsing deur die gedefinieerde proses te gebruik in Afdeling 4.4.

Die IOP-toetsplan moet die volgende insluit:

Toets sake om alle nuwe verpligte, opsionele en voorwaardelike funksies te verifieer
Ten minste een toetsgeval vir elke op-kode
Ten minste een toetsgeval vir elke parameter
Ten minste een toetssaak vir elke pakkietipe
Agterwaartse verenigbaarheidstoetsgevalle vir die verbetering van spesifikasies, sodat die vereistes in Afdeling 3.3.2 vir alle verbeterde funksies nagekom word (sien ook Afdeling 4.3.1.1).
Toetsgevalle waar die IUT blootgestel word aan waardes buite gedefinieerde reekse of aan gedragsaspekte wat as ongeldig of onverwags beskou word (Ongeldige gedragstoetsgevalle). Let daarop dat daar verwag word dat 'n toetser soos PTS of 'n ander toetsinstrument die inisieerder van ongeldige gedrag sal wees.
Enige tydelike toegewysde nommers (gekies in samewerking met BSTS om oorvleueling by komende IOP-toetsgebeurtenisse te voorkom) om by die IOP-toetsgeleentheid gebruik te word, soos beskryf in Afdeling 4.3.1.2.
Identifisering van die vereiste aantal onafhanklike implementerings wat in elke toetsgeval moet slaag, met inagneming van die dekkingvereistes soos beskryf in Afdeling 4.3.1.3
Identifisering van enige toetsgevalle in die Test Suite wat volgens die WG uitgesluit moet word, en die regverdiging vir die uitsluiting daarvan. Dit sluit gewoonlik in: • Toetsgevalle vir toekomstige toetsing (bv. Algemene toetse sodat moontlike toevoegings in die toekoms toegepas kan word, soos addisionele eienskappe, uitbreidingseienskappe, of die gebruik van Reserved for Future Use (RFU) stukkies of velde)
• Toetsgevalle wat 'n subversameling van ander ingeslote toetse is
• Generiese toetsgevalle wat feitlik identies is aan toetse wat volgens verskeie ander spesifikasies uitgevoer word (bv. Die aanleiding van algemene foutkodes)
• Toetsgevalle met dieselfde toetsdoel as toetsgevalle wat oor 'n ander vervoer loop (bv. 'N BR / EDR-toetsgeval wat soortgelyk is aan 'n LE-toetsgeval)
• Robuustheid of strestoetsing van die implementering

Die IOP-toetsplan kan ook toetse insluit wat uniek is aan IOP-toetsing, soos end-to-end-toetsgevalle wat meer komplekse rye saamvoeg wat soos 'n tipiese gebruikerscenario kan lyk.

Alhoewel BARB-goedkeuring van die IOP-toetsplan nie nodig is nie (met dien verstande dat die IOP-toetsplan steeds sal verander en verbeter met elke IOP-toetsgebeurtenis), is BARB se goedkeuring van die IOP-toetsverslag nodig (sien Afdeling 5.1.1) . As 'n IOP-toetsplan nie aan al die vereistes in Afdeling 4.3.1 voldoen nie, moet die WG 'n opsomming van die bekende afwykings en die rasionaal vir elke afwyking aan BARB voorlê voordat die IOP-toetsgebeurtenis (s) begin.

Die IOP-toetsplan en toetsgevalle moet hoofsaaklik gebaseer wees op die inhoud in die toetsdokumente van die betrokke spesifikasie.

Om die IOP-toetsgebeurtenisse doeltreffend te maak, moet die WG die IOP-toetsplan en alle gepaardgaande toetsgevalle laat voltooi en beskikbaar hê vir implementeerders, ideaal ten minste een maand voor die eerste IOP-toetsgebeurtenis.

Beplanning vir agteruitversoenbaarheidstoetse
Vir die verbetering van spesifikasies, moet IOP -toets van agterwaartse verenigbaarheid die verifikasie oorweeg teen alle aktiewe en verouderde weergawes van die spesifikasie, omdat die spesifikasies en funksies wat algemeen in Bluetooth -produkte voorkom, 'n baie lang lewensduur kan hê (bv. Voertuie). Die WG moet die toepaslike toets van die terugwaartse verenigbaarheidstoets (indien enige) ontleed, insluitend watter weergawes om te toets en die toetse wat uitgevoer moet word, en hierdie analise aan BARB verskaf. BARB moet t.o.v.view die ontleding en beveel veranderinge aan (indien enige) om die WG in die IOP -toetsplan op te neem.

Lede wat aan agteruitversoenbaarheidstoetse deelneem, word aangemoedig om verouderde toestelle wat gekwalifiseer is teenoor vorige weergawe (s) te bring. Die WG moet foute in die IOP-toetsverslag rapporteer. Lidmaatskappye word ook aangemoedig om agtertoe-verenigbaarheidstoetse in hul eie laboratoriums uit te voer buite die ligging van die IOP-toetsgebeurtenis en om enige spesifikasieverwante kwessies aan die WG te rapporteer.

Tydelike toegewysde getalle wat in IOP-toetsing gebruik word
BSTS en BARB moet geraadpleeg word om tydelike toekenning van toegekende nommers wat tydens die IOP-toetsgeleentheid gebruik sal word, te koördineer, sodat daar geen oorvleueling of botsing met ander spesifikasies is nie. Hierdie tydelike waardes moet in die IOP-toetsplan opgeneem word en sal nie deur enige aangenome spesifikasies toegeken word nie.

Vir IOP-toetsing waar een of meer nuwe 16-bit UUID-waardes voorgestel word, word die waardes binne die reeks van 0x7F00 tot 0x7FFF gereserveer vir IOP-toetsing.

Vir IOP-toetsing waar een of meer nuwe PSM-waardes (Fixed Protocol Service Multiplexer) voorgestel word, sal waardes vanaf die einde van die geldige reeks van 0x0000 tot 0x007F, soos gespesifiseer in die kernspesifikasie, gebruik word.

Dekkingvereistes
Die WG moet aan BARB bewys lewer dat die vereiste aantal onafhanklike implementerings (soos beskryf in die volgende afdelings) in elke toetsgeval geslaag het. Enige WG-versoek om uitsonderings op die vereiste aantal onafhanklike implementerings, moet aangedui word in die IOP-toetsplan wat aan BARB voorgelê word.

Implementasies word as onafhanklik van mekaar beskou, solank alle onderdele wat relevant is vir die validering onafhanklik ontwikkel is, dws deur verskillende spanne (wat nie noodwendig van verskillende ondernemings afkomstig is nie). BSTS kan help om te bepaal of die prototipes onafhanklik van mekaar beskou kan word om anonimiteit en vertroulikheid van die implementeringsbesonderhede te behou.

Let daarop dat toetsinstrumente, insluitend PTS, nie as onafhanklike implementerings beskou word nie.

Kernspesifikasie IOP dekking vereistes
'N Kernspesifikasie-kenmerk definieer gewoonlik een of meer rolle waar elke rol ontwerp is om saam te werk met een of meer ander rolle of moontlik met homself.

Vir elke paar rolle wat ontwerp is om met mekaar te werk, moet getoon word dat ten minste drie onafhanklike implementerings van elke rol saamwerk met drie onafhanklike implementerings van die aanvullende rol.

Vir elke rol wat in dieselfde rol met 'n ander toestel kan saamwerk, moet ten minste drie onafhanklike implementerings van die rol aantoon dat hulle in daardie rol met mekaar kan kommunikeer.

Diensspesifikasie-vereistes vir IOP-dekking
Ten minste drie onafhanklike diensimplementasies moet demonstreer dat dit saamwerk met ten minste een kliëntimplementering, wat PTS kan wees.

Profile en protokol spesifikasie IOP dekking vereistes
Profile en protokolspesifikasies definieer gewoonlik een of meer rolle waar elke rol ontwerp is om met een of meer ander rolle, of moontlik met homself, saam te werk.

Vir elke paar rolle wat ontwerp is om met mekaar te werk, moet ten minste twee onafhanklike implementerings van elke rol demonstreer dat hulle saamwerk met twee onafhanklike implementerings van die aanvullende rol.

Vir elke rol wat in dieselfde rol met 'n ander toestel kan saamwerk, moet ten minste drie onafhanklike implementerings van die rol demonstreer dat hulle in daardie rol met mekaar kommunikeer.

Model spesifikasie IOP dekking vereistes
Ten minste drie onafhanklike bedienermodelle of beheermodelimplementasies moet demonstreer dat hulle met ten minste een kliëntimplementering saamwerk (wat PTS kan wees), en ten minste een kliëntmodelimplementering moet demonstreer dat dit saamwerk met ten minste een implementering van die bedienermodel en PTS.

Spesifikasie weergawe nommer

Tydens die 0.9/CR Stage, moet die WG 'n aanbeveling opstel om aan die BoD voor te lê rakende die weergawenommer wat op die spesifikasie toegepas moet word wanneer dit aangeneem word.

Weergawes van die spesifikasies kan in twee soorte verdeel word: weergawes vir volledige weergawes, wat nuwe of opgedateerde funksies bevat, en weergawes vir instandhoudingsvrystellings (ook bekend as 'dot-Z-weergawes'), wat tegniese en redaksionele foute integreer, maar nie nuwe of bygewerkte weergawes bevat nie kenmerke. Volledige weergawes het tweedelige nommers in die vorm van XY, soos 2.1 of 5.0, terwyl die weergawes van onderhoudsversies drie-delige nommers in die vorm van XYZ het, soos 2.1.2. Die waarde van Z kan nie 0 wees nie.

Vir enige twee weergawes word die een die "hoër weergawe" genoem en die ander die "onderste weergawe". Dit word volgens die volgende reëls bepaal:

As die X-komponente verskil, is die een met die hoër X-waarde die 'hoër weergawe'.
As die X-komponente dieselfde is, maar die Y-komponente verskil, is die een met die hoër Y-waarde die "hoër weergawe".
As die XY-komponente dieselfde is, maar die Z-komponente verskil, is die een met die hoër Z-waarde die "hoër weergawe". 'N Tweedelige getal XY word vir hierdie doel as 'n driedelige nommer XY0 behandel.

Byvoorbeeldample, sou die volgende weergawenommers in volgorde wees van die laagste tot die hoogste weergawe: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Vir CSS verhoog elke opdatering slegs die X -komponent van die weergawenommer.

Voorvereistes vir BoD-goedkeuring
Aan die einde van die spesifikasie-ontwikkelingsfase moet aan die volgende vereistes voldoen word voordat 'n 0.9 / CR-spesifikasie aan die BoD voorgelê word vir goedkeuring:

Die WG het die toetsdekking-analise voltooi.
BSTS het reviewvolgens die 0.9/CR -spesifikasie en toetsdokumente.
BARB het die 0.9 / CR-spesifikasie goedgekeur.
BARB het die CSS CR goedgekeur (indien nuwe inskrywings deur die spesifikasie vereis word) wat in 'n verkorte CR van die spesifikasie ingebed kan word.
BARB het die GSS CR en MDP CR goedgekeur (indien nuwe spesifikasies vereis word).
BTI het die 0.9/CR Test Suite, ICS en TCRL goedgekeur, tesame met 'n IXIT (mits die IXIT nodig is om die toetse in die Test Suite uit te voer). Die TCRL is opsioneel in hierdie artikeltage vir opdaterings van die kernspesifikasie.
Die WG het die IOP -toetsplan by BARB ingedien vir herview (as die toets nie deur BARB afgestaan word nie).

Die dokumente wat aan die BoD voorgelê word, moet die BARB-goedgekeurde 0.9 / CR-spesifikasie bevat, en 'n voorlegging aan die BoD wat moet insluit:

Enige bekende versoeke om afstand te doen van IOP-toetse of enige van die vereistes omskryf in Afdeling 4.3.1
'N Lys van vervoer wat die spesifikasie ondersteun (bv. BR / EDR, LE, ens.)
Vir 'n spesifikasieverbetering word enige vrystellings van die vereiste agteruitversoenbaarheid (beskryf in Afdeling 3.3.2) wat deur die WG aangevra word
Vir 'n verbetering van die spesifikasie, word 'n aanbeveling van die WG vir die weergawenommer toegepas op die aangenome spesifikasie
Vir 'n verbetering van die spesifikasie, word die WG se aanbeveling aan die einde van die lewe vir die vorige weergawe (s) van die aangenome spesifikasie, insluitend enige tegniese redes waarom die verswakking of intrekking van enige vorige weergawe van die spesifikasie wel of nie aanbeveel word nie, en die regverdiging ingesluit. vir die aanbeveling
Enige onopgeloste ernstige kommer van BARB- of BTI -lede (bv. Redes vir geen stemme tydens goedkeurings, kommer wat voortspruit uitview van toetsdokumente of kommer dat die 0.9/CR -spesifikasie buite die omvang van die FRD of handves val)
Die voorbereidingstatus van die Profile Tuning Suite (PTS) of ander nodige gereedskap wat verband hou met aanneming wat deur BSTS voorberei word

Die BoD kan kies om die 0.9 / CR-spesifikasie vir IOP-toetsing goed te keur soos vereis deur die Bylaws [2], voordat BTI die 0.9 / CR-toetsdokumente goedkeur en voordat die WG bevestig dat die IOP-toetsplan voldoen aan die vereistes gedefinieer in Afdeling 4.3.1. 0.9. Die BoD kan ook die goedkeuring van die 0.9 / CR-spesifikasie vir IOP-toetsing vereis op BTI se goedkeuring van die XNUMX / CR-toetsdokumente.

0.9/CR Stage uitgangsvereistes
Die 0.9/CR Stage is voltooi en die bekragtigingsfase begin wanneer die BoD die begin van IOP -toetsing goedkeur.

4.4 Afwykings vir prosesontwikkelingspesifikasies

'N WG kan versoek om afstand te doen van een of meer van die volgende prosesstappe:

Die 0.5/DIPD Stage
Die 0.7/FIPD Stage
IOP-toetsing binne die Valideringsfase

Om 'n kwytskelding te versoek, moet die WG die prosesvrystellingssjabloon gebruik deur Bluetooth SIG [8] en 'n kwytskeldingversoek indien by elke komitee (dws BARB of BTI) wat nodig is omview of die konsepspesifikasie of gepaardgaande toetsdokumente by die stage dat die WG voorstel om afstand te doen, en elkeen van die komitees moet die kwytskelding versoek goedkeur.

'N Kwytskeldingsversoek moet die volgende insluit:

'N Identifikasie van die stage (s) waarop die WG afstand wil doen
'N Regverdiging waarom die stage (s) moet van die hand gewys word
'N Identifikasie van elke komitee (dws BTI en/of BARB) wat vereis wordview en keur die kwytskelding versoek goed

Die komitee wat die kwytskelding oorweeg, kan vereis dat 'n verteenwoordiger van die WG 'n voorlegging doen om die kwytskelding van die SMPD-proses te regverdig voordat hy besluit oor die kwytskeldingsversoek.

As 'n kwytskelding versoek om van verskeie stappe afstand te doen en 'n gedeelte van die kwytskelding van die hand gewys word en 'n gedeelte goedgekeur word, moet die komitee se antwoord aandui watter stappe in die kwytskeldingsversoek goedgekeur is en watter van die hand gewys is. As 'n kwytskeldingsversoek van die hand gewys word, moet die verwerpingskennisgewing die redes vir verwerping bevat.

5. Valideringsfase

Tydens die bekragtigingsfase sal die WG IOP -toetsing op die 0.9/CR -spesifikasie uitvoer met die doel om 'n IOP -toetsverslag vir BARB review en goedkeuring. Waar moontlik moet IOP -toetsing van spesifikasieverbeterings uitgevoer word teen die geïntegreerde konsepspesifikasie. Daarbenewens het die lid Review, soos vereis deur die statute [2], begin gedurende hierdie fase.

As die spesifikasie (of verbetering) nie IOP-toetsing vereis nie, kan IOP-toetsing binne die Validasie-fase afgesien word deur gebruik te maak van die proses wat in Afdeling 4.4 beskryf word.

Gedurende die loop van IOP -toetsing (wat een of meer gebeurtenisse kan wees), moet die WG probleme opspoor met behulp van Bluetooth SIG se probleemopsporingstelsel en herhaal om opdaterings in die konsepspesifikasie, toetsdokumente en IOP -toetsplan op te neem. Nadat die IOP -toets voltooi is, moet die WG opdaterings van die konsepspesifikasie en toetsdokumente voltooi om alle probleme op te los, en 'n IOP -toetsverslag voor te berei en by BARB in te dienview en goedkeuring. Dit word geïllustreer in Figuur 5.1.

Gedurende die bekragtigingsfase kan daar verskeie aktiwiteite begin. Hierdie aktiwiteite kan parallel plaasvind en sluit die volgende in:

Die BoD-goedgekeurde 0.9/CR-spesifikasie word deur BSTS aan alle lede beskikbaar gestel met kennisgewing van die aanvang van die Member Review tydperk vereis deur die statute.
Enige vereiste opdaterings word opgeneem in CSS (wat in 'n verkorte CR van die spesifikasie ingebed kan wees).
Kenmerkende of beskrywende definisies is opgeneem in die GSS-spesifikasie sowel as PTS vir IOP-toetsing.
Definisies van maas-eienskappe is opgeneem in die MDP-spesifikasie sowel as PTS vir IOP-toetsing.
BSTS maak 'n IOP-platformregistrasie- en resultate-invoerinstrument moontlik om voor te berei vir IOP-toetsing.
IOP-toetsing, indien nodig (sien Afdeling 5.1).
Review kommentaar en kwessies, insluitend die wat ingedien is as gevolg van IOP -toetsing, word verwerk en veranderings word in die konsepspesifikasie opgeneem.

5.1 IOP-toetsing

Die primêre doel van IOP -toetsing is om die spesifikasie te bekragtig deur bvample, kyk na die akkuraatheid en onduidelikheid in die teks, herviewvir enige fundamentele ontwerpfoute en weglatings, en om validering te lewer teen voorheen vasgestelde vereistes wat vroeër in die spesifikasie -ontwikkelingsproses ontwikkel is. IOP -toetse kan verander in die konsepspesifikasie en verskeie IOP -toetsgebeurtenisse kan nodig wees om alle vereiste toetse te voltooi.

Dit is belangrik om lede buite die WG die geleentheid te gee om aan IOP -toetse deel te neem, omdat hulle 'n onafhanklike bied view van die spesifikasie en kan gebiede van onduidelikheid in die spesifikasie ontbloot wat moontlik nie duidelik is vir die lede van die WG wat die konsep ontwikkel het nie. Voor elke IOP -toetsgeleentheid sal BSTS die gebeurtenisbesonderhede, die nuutste konsepspesifikasie, die Test Suite en IOP -toetsplan beskikbaar stel en sal dit alle lede ideaal in kennis stel een maand voor elke geleentheid. Die bygewerkte konsepspesifikasie, Test Suite en IOP -toetsplan wat by 'n IOP -toetsgeleentheid gebruik word, moet minstens een week voor elke geleentheid beskikbaar wees.

Tydens IOP-toetsing sal kombinasies van platforms met 'n paar uur probeer om die toetse uit te voer, en deelnemers aan die IOP-toets sal die slaag / druipresultate van elke toets en kommentaar opneem. Tydens die IOP-toetsgeleenthede sal 'n anonieme opsomming van hierdie resultate (verwys na bv. "Platform A", "Platform B", ens.) En enige kommentaar versamel word en tydens en na die IOP aan die lede van die WG beskikbaar gestel word. toetsgeleentheid. As addisionele inligting benodig word om 'n beter begrip te kry van opmerkings of mislukkings wat tydens IOP-toetsing plaasgevind het, kan BSTS as tussenganger optree om verdere inligting van die indienende lid in te samel.

Indien moontlik, moet PTS opgedateer word om IOP-toetsing met platforms by alle lae bo die Host Controller Interface (HCI) te ondersteun, en teenwoordig wees by IOP-toetsgeleenthede vir daardie lae. Ander toetsinstrumente kan ook by IOP-toetsgeleenthede teenwoordig wees. 'N Opsomming van die resultate van toetsing met PTS of ander toetsinstrumente (indien enige) moet in die IOP-toetsverslag ingesluit word.

IOP-toetsing sal oop wees vir alle lede wat 'n prototipe-implementering wil bied, maar Bluetooth SIG kan deelname voorwaardes maak op aanvaarding van ooreenkomste met Bluetooth SIG (insluitend deelname- en vertroulikheidsooreenkomste). Die WG is verantwoordelik vir die verwerking en oplos van probleme wat tydens IOP-toetsing ontdek is, en die opdatering van die betrokke dokumente; WG-goedgekeurde veranderinge moet opgeneem word as opdatering van die konsepspesifikasie en toetsdokumente vir gebruik by elke IOP-toetsgebeurtenis.

Voor die bekragtigingsfase mag WG's voorlopige IOP-toetse doen by geleenthede wat slegs vir lede van die WG beskikbaar is, maar die resultate van informele toetse is moontlik nie by die IOP-toetsuitslae ingesluit nie.

Dit kan gebeur dat alle stappe wat lei tot die eerste IOP-toetsgebeurtenis gevolg word, insluitend 'n aangekondigde IOP-datum en -lokasie met die bedoeling om met IOP-toetsing te begin, maar BoD-goedkeuring is nog nie verseker voordat die toetsgebeurtenis begin het nie. In hierdie geval mag die BoD toestemming gee vir die insluiting van toetsresultate wat voor die goedkeuring van die BoD versamel is om met IOP-toetsing te begin, mits die versamelde resultate gebaseer is op dieselfde spesifikasie en dat Test Suite deur die BoD goedgekeur is.

IOP-toetsing is nie nodig vir verbeterings aan CSS-, GSS- of MDP-spesifikasies nie.

IOP-toetsverslag
Nadat die IOP -toets voltooi is, moet die WG die IOP -toetsverslag aan BARB voorlê met die doel om aan te toon dat die vereiste aantal onafhanklike platforms die vereiste toetse geslaag het. BARB moet t.o.v.view en die IOP -toetsverslag goedkeur of verwerp, en sal die WG in kennis stel indien addisionele IOP -toetsing nodig is voordat die stembus -konsepspesifikasiepakket by die BoD ingedien word. BSTS en die WG moet verseker dat geen lididentifiserende inligting in die IOP-toetsverslag verskyn voordat die verslag aan BARB voorgelê word nie.

Die IOP-toetsverslag moet die volgende insluit:

'N Lys van al die IOP-toetsgebeurtenisse wat tydens die Valideringsfase plaasgevind het, insluitend hul datums en plekke.
Die aantal lidmaatskappye en onafhanklike platforms wat aan elke IOP-geleentheid deelgeneem het, insluitend of PTS gebruik is.
'N Lys van die spesifikasie-, Test Suite- en IOP-toetsplanweergawes wat by elke geleentheid gebruik word.
'N Samevattende opsomming wat aandui of alle toetsgevalle aan die minimum slaagvereistes voldoen, al dan nie.
'N Opsomming van enige afwykings van die IOP-toetsplanvereistes wat in Afdeling 4.3.1 gedefinieer word en die rasionaal vir elke afwyking.
'N Opsomming van PTS-dekking vir toetsgevalle in die Test Suite.
'N Lys van alle toetsgevalle (insluitend agteruitversoenbaarheidstoetse) uit die IOP-toetsplan, die aantal slaagslae, die aantal mislukkings en of die minimum kriteria per toetsgeval nagekom is, insluitend 'n uiteensetting waarom geen vereistes voldoen word nie ontmoet het.
'N Opsomming van kwessies, kommentaar en vrae by elke geleentheid (insluitend die filed teen die spesifikasie tydens IOP -toetsing) en die impak op die spesifikasie- en toetsdokumente.

5.2 Valideringsfase-uitgangsvereistes

Die bekragtigingsfase is voltooi en die goedkeurings- / aannemingsfase begin wanneer BARB die IOP-toetsverslag goedgekeur het (tensy BARB afstand gedoen het van die toets) en daar is aan al die volgende vereistes voldoen:

BSTS het die goedgekeurde 0.9/CR -spesifikasie beskikbaar gestel aan alle lede vir Member Review soos vereis deur die statute en alle lede in kennis gestel van die beskikbaarheid daarvan.
Alle kwessies wat tydens IOP-toetse geïdentifiseer is, en wat 'n toetsimpak het, is opgeneem en getoets.
WG het IOP-toetse voltooi (tensy BARB afstand doen van toetsing).

6. Aannemings- / goedkeuringsfase

Tydens die aannemings-/goedkeuringsfase word die spesifikasie en verwante toetsdokumente afgehandel, goedkeuring deur BARB, BQRB en BTI ontvang, kennisgewing van die voorgestelde aannemingsdatum word uitgereik, tesame met die finale weergawe van die konsepspesifikasie wat aan die BoD voorgelê word vir aanneming ( Stemmingskonsep), en die finale spesifikasiepakket word by die BoD ingedien. Na die minimum duur van lid Review voldoen aan die statute [2]) is nagekom, sal die BoD die spesifikasie vir aanneming op die aannemingsdatum oorweeg. Na aanneming word die spesifikasie gepubliseer en die kwalifikasiestelsel geaktiveer. Die aannemings-/goedkeuringsfase word in figuur 6.1 geïllustreer.

6.1 Stemontwerp

Die Stemkonsep word geskep deur opdaterings (verskaf in die Valideringsfase) in die vereiste spesifikasiedokumente op te neem en 'n finale konsep van die nuwe spesifikasie op te stel. Vir spesifikasieverbeterings sal BSTS die geïntegreerde spesifikasie skep deur een of meer CR (s) in die voorheen aangenome hoër weergawe van die spesifikasie te integreer (sien Afdeling 4.3.2) as dit nog nie voor die Validasiefase voltooi is nie.

As daar gedurende hierdie fase veranderinge aan die spesifikasie aangebring word en die WG, BARB of BTI bepaal dat enige verandering addisionele IOP-toetse benodig, sal die spesifikasie terugkeer na die IOP-toetsgedeelte van die Valideringsfase vir die WG om die addisionele toetse uit te voer. Gedurende die aannemings- / goedkeuringsfase word die volgende dokumente voltooi en aan die BoD beskikbaar gestel voor die aannemingsdatum:

Die stemkonsep
Alle ondersteunende spesifikasies (dws CSS, GSS, MDP) soos benodig vir die betrokke spesifikasie (of verbetering) tipe, indien dit nie voorheen aanvaar is nie
Vir die verbetering van spesifikasies, 'n weergawe van 'n veranderingspoor van die aangeneemde spesifikasie-weergawe wat die wysigings in die Stemkonsep voorstel
'N Beskrywing van die WG van enige vereistes vir agteruitversoenbaarheid (soos beskryf in Afdeling 3.3.2) waaraan nie voldoen is nie en die regverdiging vir enige vrystellings
'N Beskrywing van die WG van enige IOP -toetsplanvereistes (soos beskryf in afdeling 4.3.1) waaraan nie voldoen is nie en die regverdiging vir enige afwykings saam met die IOP -toetsverslag (wat verskaf kan word deur 'n skakel na 'n afskrif op die Bluetooth SIG webwerf)
'N Aanbeveling van die WG vir die afskrywing of onttrekking van enige vorige weergawe (s) van die aangeneem spesifikasie, saam met 'n regverdiging, wat veranderinge sedert die 0.9/CR S beklemtoontage-einde-van-leeftyd-aanbeveling
'N Samevatting, opgestel deur die WG, van veranderings aan funksies of funksionaliteit sedert die 0.9 / CR-spesifikasie (indien enige)
'N Opsomming, opgestel deur BARB, van kommer wat deur BARB-lede geopper word dat die spesifikasie wat deur die WG opgestel word buite die bestek van die handves wat deur die BoD goedgekeur is (indien enige)
'N Lys met die oorblywende onopgeloste regskwessies uit die regsadviesview (indien enige)
Die BTI-goedgekeurde toetspakket, tesame met die WG-goedgekeurde opsomming van die toetsdekking van die spesifikasie vir die stemkonsep. In die geval van nuut toegevoegde of gewysigde funksies sonder toetsdekking, is 'n skriftelike regverdiging vir die weglating nodig
Die BTI-goedgekeurde ICS en IXIT (indien die spesifikasie dit vereis)
Die TCRL goedgekeur deur beide BTI en BQRB
'N Verslag opgestel deur BSTS tesame met BTI rakende die status van gereedheid vir gereedskap (bv. PTS en ander toetshulpmiddels, Bluetooth Launch Studio), insluitend indien enige toetsgevalle in die TCRL nie deur toetshulpmiddels ondersteun word nie
'N Opsomming, opgestel deur die WG, van alle nodige toegewysde nommers
'N Aannemings kontrolelys opgestel deur BSTS en die WG wat toon dat al die aflewerings in hierdie afdeling voltooi is
Alle ander inligting wat deur die BoD aangevra word

Tydens die aannemings- / goedkeuringsfase moet die WG die Bluetooth-SIG se probleemopsporingstelsel gebruik om kwessies en opmerkings teenoor die konsepspesifikasie en toetsdokumente vas te lê, sodat daar rekening gehou word met die finalisering van die Spesifikasie vir die Stemkonsep. Vir 'n spesifikasieverbetering moet alle toepaslike goedgekeurde errata (dit wil sê die goedgekeurde errata wat nog nie geïntegreer is nie) opgeneem word en moet geïdentifiseer word met behulp van opgespoorde veranderinge.

Die WG moet die finale konsepspesifikasie aan BSTS voorlê vir wettige hersieningview. Vir nuwe spesifikasies, die wetlike t.o.v.view sal die volledige spesifikasie bevat. Vir spesifikasieverbeterings, die review sal hoofsaaklik fokus op die veranderde dele van die spesifikasie. Die doel van wetlike t.o.v.view Dit is hoofsaaklik om regsrisiko's te identifiseer wat die WG moet oorweeg en probeer oplos. Die wetlike terugvoer sal volgens die erns ingedeel word. As 'n opsionele wettige review is uitgevoer op die 0.9/CR Stage, die weergawe wat ingedien word vir wettige herview moet alle veranderings wat sedert die weergawe aangebring is (as óf deur die WG óf die BSTS) as gevolgde veranderinge toon. Na voltooiing van die wettige review, sal die WG en BSTS ooreenkom oor die terugvoer wat by die konsepspesifikasie opgeneem moet word. As daar onopgeloste regskommentaar van regsadvies isview oor die konsepspesifikasie, kan die WG -voorsitter tyd op die BoD -agenda versoek om saam te stem oor resolusie.

In parallel met wetlike t.o.v.view, moet die WG die konsepspesifikasie by BARB indien vir heroorwegingview. By die aanvanklike voorlegging aan BARB, sal BSTS alle lede in kennis stel dat die konsepspesifikasie by BARB ingedien is vir herview en dat dit ook beskikbaar is vir Lid Review. As die WG opdaterings aan die konsepspesifikasie vir BARB-herbediening indienview, Sal BSTS periodiek addisionele kennisgewings aan alle lede stuur.

Na voltooiing van BARB t.o.v.view, sal die WG en BARB ooreenkom oor die terugvoer wat by die konsepspesifikasie opgeneem moet word.

As die wettige t.o.v.view lei tot enige wesenlike veranderinge, bykomende t.o.v.view deur BARB nodig mag wees. Net so, as die BARB weerview wesenlike veranderinge tot gevolg het, sal BSTS bepaal of 'n bykomende wetlikeview van hierdie veranderings is nodig. Na voltooiing van die wettige review en BARB t.o.v.view, BARB moet die stemvoorstel goedkeur of verwerp.

As enige toetsdokumente opgedateer moet word, sal BSTS die WG help om die toetsdokumente op te dateer. BTI moet die toetsdokumente goedkeur of verwerp. As dit deur BTI goedgekeur word, sal BTI help om die TCRL te finaliseer en hierdie dokument saam met die gepaardgaande ICS, IXIT en Test Suite aan BQRB te lewer. BSTS sal die datum van die BoD-vergadering skat wanneer die BoD van voorneme is om te stem oor die goedkeuring van die Stemkonsep (Aannemingsdatum) en dit BTI te voorsien vir gebruik in die TCRL. BARB-goedkeuring van die spesifikasie, BTI-goedkeuring van alle toetsdokumente (insluitend die Test Suite, TCRL, ICS en IXIT), en BQRB-goedkeuring van die TCRL moet voor of op die aannemingsdatum plaasvind.

BSTS sal alle lede in kennis stel van die finalisering en beskikbaarheid van die stemopstel en die aannemingsdatum. Die aannemingsdatum word nie vroeër as 60 dae bepaal nadat lede in kennis gestel is van die BoD-goedgekeurde 0.9/CR-spesifikasie nie, tensy die lid Review die tydperk word ingekort deur die BoD in ooreenstemming met die statute, en ten minste 14 dae nadat kennisgewing van die aannemingsdatum aan lede gegee is in ooreenstemming met die statute. Vir gevalle waar verskeie CR's in 'n stemopgawe geïntegreer is, begin lid Review is die datum waarop lede in kennis gestel is van die mees onlangse BoD-goedgekeurde CR.

Nadat kennisgewing van die Aannemingsdatum aan lede verskaf is, is die deur BoD goedgekeurde regstellings vir tipografiese foute in die Stemkonsep toegelaat. Die tydlyn vir die aanneming van spesifikasies word in figuur 6.2 geïllustreer.

6.2 Toegekende getalle

Bluetooth SIG handhaaf 'n publiek beskikbare stel toegewysde nommers op die Bluetooth SIG -toegewysde nommers webwebwerf [7]. Hierdie toegewysde nommers word gegroepeer in verskillende getalruimtes ('n verwante stel getalle sonder duplikate). Getalle wat toegeken word, kan oorvleuel met ander toegewysde nommers in verskillende getalruimtes, maar geen nommer binne 'n getalruimte mag hergebruik word nie. Die verskillende getalruimtes word gedefinieer in die spesifikasie wat die gebruik van die toegewysde getalle definieer.

Nadat BARB die IOP -toetsverslag goedgekeur het, sal die WG 'n versoek aan BARB indien vir die toewysing van nuwe nommers binne die nommerruimte (s) wat deur die finale spesifikasie vereis word. BARB sal review die versoek en werk saam met BSTS om die toegewysde nommers te bepaal. Na goedkeuring deur BARB, sal BSTS die publikasie van die toegewysde nommers beplan om in die openbaar beskikbaar te word op die Bluetooth SIG -toegewysde nommers webwebwerf [7] binne een week na die aanneming van die spesifikasie.

Sodra die publikasie van toegewysde nommers op die Bluetooth SIG -toegewysde nommers gepubliseer is webop die webwerf of binne 'n aangeneemde spesifikasie, is die toegewysde getalle bedoel om onveranderlik te wees (om nie in waarde of betekenis te verander nie). As dit om een of ander rede onbruikbaar word, word dit voorbehoude en word dit nie hergebruik nie.

6.3 Aannemings- / goedkeuringsfase-uitgangsvereistes

Die goedkeurings- / aannemingsfase is voltooi wanneer die BoD die spesifikasie aanvaar het en die volgende na-aannemingsaktiwiteite voltooi is:

BSTS het die finale toegewysde nommers openbaar gemaak op die Bluetooth SIG webwebwerf.
BSTS het die goedgekeurde spesifikasie openbaar gemaak op die Bluetooth SIG webwebwerf
BSTS het alle stawende dokumente (bv. CSS, GSS, MDP) wat vir die relevante spesifikasie benodig word, openbaar gemaak op die Bluetooth SIG webwebwerf.
BSTS het die gepaardgaande toetsdokumente op die Bluetooth SIG aan alle lede beskikbaar gestel webwebwerf.
Vir die verbetering van spesifikasies het BSTS 'n insiggewende weergawe van die voorafgaande goedgekeurde spesifikasie-weergawe gemaak met alle veranderings wat deur die nuut aangeneemde weergawe aangebring is, en dit aan alle lede op die Bluetooth SIG beskikbaar gestel webwebwerf.
BSTS het die kwalifikasiestelsel geaktiveer.
BSTS het alle lede in kennis gestel van die beskikbaarheid van die aangenome spesifikasie en alle ondersteunende dokumente.

Die Bluetooth SIG beplan om hierdie na-aannemingsaktiwiteite binne een week na aanvaarding van die spesifikasie te voltooi.

7. Spesifikasie Onderhoudsfase

Die spesifikasie-instandhoudingsfase begin nadat die aannemings- / goedkeuringsfase voltooi is. As probleme met die spesifikasie of gepaardgaande toetsdokumente (bv. Onduidelikhede van die bewoording of tegniese foute) gevind word, moet dit gedokumenteer word deur errata-voorstelle te skep met behulp van die Bluetooth SIG Errata-instrument. Spesifieke erratum-voorstelle sal volgens die EPD [3] verwerk, gekategoriseer en goedgekeur word. Test Suite erratum word verwerk en gekategoriseer volgens die TSTO [5]. As daar konflik tussen die SMPD en die EPD of TSTO is, het die SMPD voorrang.

Spesifikasies erratum moet slegs gebruik word om tegniese of redaksionele foute in die goedgekeurde Bluetooth-spesifikasies reg te stel. Toevoeging van, veranderinge aan en verwydering van funksionaliteit kan slegs gedoen word deur middel van die spesifikasieverbeteringsproses wat vroeër in hierdie dokument omskryf is.

7.1 Versnelde erratumproses

As 'n erratum goedgekeur word volgens die proses omskryf in die EPD [3], kan die WG, BARB of BSTS aanbeveel dat dit as dringend beskou word en moet bespoedig word. As dit gebeur, sal BSTS saam met die WG of BARB die aanbeveling aan die BoD voorlê. Die BoD sal besluit of die aanbeveling aanvaar of verwerp word. As die aanbeveling aanvaar word, sal BSTS die goedgekeurde erratum onmiddellik in die erratum -sjabloon [8] opneem en saam met die verantwoordelike WG werk om 'n Versnelde Errata -regstelling af te handel wat aan die WG voorgelê moet word vir herview en goedkeuring.

'n verbyview van die versnelde erratumproses word in Figuur 7.1 geïllustreer.

Die volgende dokumente moet voor die Aannemingsdatum voltooi en aan die BoD beskikbaar gestel word:

Die konsep-goedgekeurde konsep Versnelde Errata-regstelling.
'N Beskrywing van die WG van die vereiste agteruitversoenbaarheid (soos beskryf in Afdeling 3.3.2) waaraan nie voldoen is nie, en die regverdiging vir enige vrystellings.
'N Lys met die oorblywende onopgeloste regskwessies uit die regsadviesview (indien enige).
Die BTI-goedgekeurde toetspakket, ICS en IXIT (indien die erratum dit benodig).
Die BTI- en BQRB-goedgekeurde TCRL (indien vereis deur die erratum).
'N Verslag voltooi deur BSTS tesame met BTI rakende die status van gereedheid vir gereedskap (bv. PTS en ander toetsinstrumente, Bluetooth Launch Studio), insluitend indien enige toetsgevalle in die TCRL nie ondersteun word deur toetsinstrumente nie en 'n verduideliking (indien die erratum dit benodig) ).
'N Kontrolelys vir aanneming wat deur BSTS en die WG voltooi is, wat toon dat die aflewerings in hierdie afdeling alles voltooi is.
Alle ander inligting wat deur die BoD aangevra word.

BSTS sal saam met die verantwoordelike WG werk om die konsep Expedited Errata Correction af te handel en 'n weergawe te skep om by die verantwoordelike WG in te dien vir herview en goedkeuring.

Die WG moet die Expedited Errata -regstelling aan die BSTS voorlê vir wettige hersieningview. Na voltooiing van die wettige review, sal die WG en BSTS ooreenkom oor die terugvoer wat by die versnelde Errata -regstelling opgeneem moet word. As daar onopgeloste regskommentaar van regsadvies isview op die Versnelde Errata -regstelling, kan die WG -voorsitter tyd op die BoD -agenda versoek om insette van die BOD oor resolusie te verkry.

In parallel met wetlike t.o.v.view, moet die WG die Expedited Errata -regstelling by BARB indien vir herview. Sodra die versnelde Errata -regstelling by BARB ingedien is, sal BSTS dit vir alle lede toeganklik maak omview en stel alle lede in kennis van die beskikbaarheid daarvan. Na voltooiing van BARB t.o.v.view, sal die WG en BARB ooreenkom oor die terugvoer wat by die versnelde Errata -regstelling opgeneem moet word.

As enige toetsdokumente opgedateer moet word, sal BSTS die WG help om die toetsdokumente op te dateer. Na BTI-goedkeuring van die toetsdokumente, sal BTI help met die finalisering van die TCRL en die dokument by BQRB aflewer, tesame met die gepaardgaande ICS, IXIT en Test Suite, soos van toepassing. BSTS sal die aannemingsdatum beraam en aan BTI verskaf vir gebruik in die TCRL. BARB-goedkeuring van die Versnelde Errata-regstelling, BTI-goedkeuring van alle toetsdokumente (insluitend die Test Suite, TCRL, ICS en IXIT soos van toepassing), en BQRB-goedkeuring van die TCRL moet voor of op die Aannemingsdatum plaasvind.

BSTS sal alle lede in kennis stel van die afhandeling en beskikbaarheid van die versnelde Errata-regstelling en die voorgestelde aannemingsdatum. Die Aannemingsdatum sal vasgestel word en aan alle lede in kennis gestel word ooreenkomstig die Verordeninge [2] en die Aannemingsdatum sal minstens 14 dae wees nadat die kennisgewing aan lede gegee is. Nadat kennisgewing van die voorgestelde Aannemingsdatum aan lede verskaf is, kan die BoD regstellings van tipografiese foute in die Versnelde Errata-regstelling goedkeur sonder om 'n bykomende kennisgewing van die voorgestelde Aannemingsdatum in te dien en die vereiste 14 dae te wag.

Bluetooth SIG sal die aangenome Versnelde Errata-regstelling publiek beskikbaar stel en beplan om dit binne een week na aanneming te doen. Kennisgewing oor die beskikbaarheid daarvan word deur BSTS aan alle lede uitgereik.

Die bespoedigde erratum-proses is voltooi wanneer die BoD die Versnelde Errata-regstelling aanvaar het en die volgende aktiwiteite na aanneming voltooi is:

BSTS het die aangeneemde Expedited Errata -regstelling en gepaardgaande toetsdokumente (indien vereis deur die erratum) vir die publiek beskikbaar op die Bluetooth SIG webwebwerf.
BSTS het die kwalifikasiestelsel geaktiveer (indien die erratum dit vereis).
BSTS het alle lede in kennis gestel van die beskikbaarheid van die aangenome Versnelde Errata-regstelling.

Na voltooiing van hierdie aktiwiteite, sal die Errata-regstelling geskeduleer word vir integrasie in die betrokke spesifikasies, hetsy as deel van 'n beplande spesifikasieverbetering of in 'n komende onderhoudsvrystelling soos beskryf in Afdeling 7.2.

7.2 Onderhoudsproses (.Z spesifikasies)

Op 'n ongeveer jaarlikse basis sal BSTS bepaal of daar goedgekeurde errata (waarna verwys word as Errata-regstellings) wat as tegnies / hoog of tegnies / kritiek geklassifiseer word en wat nog in die teks van enige aktiewe spesifikasie opgeneem moet word (dws 'n aangenome spesifikasie wat nie afgekeur of teruggetrek is nie). Sien aanhangsel A vir definisies van errata-klassifikasies. 'N Spesifikasie-eienaar (óf die WG wat geoktrooieer word om die spesifikasie te handhaaf, óf BARB as geen WG gehuur is om die spesifikasie te handhaaf nie) kan ook 'n vroeëre instandhoudingsvrystelling van 'n aktiewe spesifikasie versoek waarin enige goedgekeurde errata opgeneem word. Met BSTS-bepaling of op versoek van die spesifikasie-eienaar, sal die proses vir instandhouding van die onderhoud begin.

'n verbyview van die onderhoudsvrystellingsproses word geïllustreer in Fout! Verwysingsbron nie gevind nie.

Aan die begin van die onderhoudsvrystellingsproses sal BSTS saam met die spesifikasie-eienaar, BARB en BTI 'n plan ontwikkel en aan die BoD voorlê om die Errata-regstellings in die gepubliseerde spesifikasieweergawe op te neem. Die voorgestelde plan moet aandui of Errata-regstellings opgeneem sal word in die instandhoudingsvrystelling van die spesifikasie (dws 'n .Z-weergawe) of 'n spesifikasieverbetering wat reeds aan die gang is (dws 'n XY-weergawe). Die voorgestelde plan moet in ag neem of daar nuwe verpligte kenmerke bygevoeg is tussen weergawes van aangenome spesifikasies, die geskatte tyd wanneer die volgende spesifikasieverbetering beplan word vir aanvaarding, en ander faktore.

Na goedkeuring van 'n plan deur die BoD, sal BSTS tesame met die spesifikasie-eienaar voortgaan om alle tegniese / medium, tegniese / hoë en tegniese / kritieke foutiewe regstellings in 'n konsepspesifikasie op te neem wat 'n 'Onderhoudvrystelling' genoem word. Vir redaksionele of tegniese / lae errata-regstellings, as die errata-regstelling op meer as een weergawe van die spesifikasie van toepassing is, sal BSTS, tensy die BoD anders aandui, daardie foute in die mees onlangse weergawe met hoër spesifikasies integreer tydens die volgende opdatering van die weergawe . Geen veranderinge mag in 'n konsep vir onderhoudsvrystelling ingesluit word nie, behalwe om Errata-regstellings in te sluit. Elke konsep vir onderhoudsvrystelling moet alle ingeslote Errata-regstellings identifiseer met behulp van veranderingsopsporing om die voorgestelde veranderinge aan die voorheen aangenome weergawe van die gepubliseerde spesifikasie aan te toon.

Die tydsberekening van die voorgestelde inwerkingstelling vir elke Errata-regstelling in 'n konsep vir onderhoudsvrystelling, sal afhang van die impak van die Test Suite: alle Errata-regstellings wat nie die impak van die Test Suite het nie, kan dadelik opgeneem word, maar Errata-regstellings wat 'n uitwerking op die Test Suite het, sal wel wees verwerk sodat die tydsberekening saamval met 'n opdatering van die TCRL.

BTI en BSTS sal 'n sperdatum opstel vir die insluiting van Errata-regstellings met die toets Suite-impak in 'n konsep vir onderhoudsvrystelling. Hierdie sperdatum is gewoonlik 3 tot 6 maande voor die beplande goedkeuringsdatum van die volgende groot TCRL-vrystelling. Errata-regstellings met Test Suite-impak wat die sperdatum vir insluiting misloop, sal verwerk word as deel van die volgende jaarlikse TCRL-vrystelling. Daarom, tensy 'n vroeëre vrystelling versoek word, is die maksimum tyd vir Tegniese / Hoë of Tegniese / Kritieke Errata-regstellings om by 'n spesifikasie-opdatering ingesluit te word ongeveer 15 tot 18 maande.

Die eienaar van die spesifikasie moet die konsep van onderhoudsverklaring, wat dit as finaal goedgekeur het, indien vir juridiese voorleggingview. Die wetlike t.o.v.view sal hoofsaaklik fokus op die veranderde dele van die spesifikasie. Na voltooiing van die wettige review, sal die eienaar van die spesifikasie en die BSTS ooreenkom oor die terugvoer wat by die konsep vir onderhoudsverklaring ingesluit moet word. As daar onopgeloste regskommentaar van regsadvies isview In die konsep van die onderhoudsverklaring kan die eienaar van die spesifikasie tyd op die BoD -agenda versoek om insette van die BD oor resolusie te verkry.

In parallel met wetlike t.o.v.view, moet die eienaar van die spesifikasie die konsep vir onderhoudsverklaring by BARB indien vir herverklaringview. Sodra die konsep vir onderhoudsverklaring by BARB ingedien is, sal BSTS dit vir alle lede toeganklik maak om te heroorweegview en stel alle lede in kennis van die beskikbaarheid daarvan. Na voltooiing van BARB t.o.v.view, sal die eienaar van die spesifikasie en die BARB ooreenkom oor die terugvoer wat in die konsepspesifikasie opgeneem moet word.

Vir Errata-regstellings wat 'n impak op toetsdokumente het, en waar die ooreenstemmende toetsfoute betyds vir die komende TCRL-vrystelling verwerk sal word, sal BSTS saam met die spesifikasie-eienaar en BTI werk om die toetsdokumente op te dateer. Na BTI-goedkeuring van die toetsdokumente sal BSTS die aannemingsdatum beraam en die voorgestelde aannemingsdatum aan BTI verskaf vir gebruik in die TCRL. BTI sal die TCRL aan BQRB aflewer, tesame met die gepaardgaande ICS, IXIT en Test Suite, soos van toepassing. BARB-goedkeuring van die spesifikasie, BTI-goedkeuring van alle toetsdokumente (insluitend die Test Suite, TCRL, ICS en IXIT soos van toepassing), en BQRB-goedkeuring van die TCRL moet voor of op die aannemingsdatum plaasvind.

BSTS sal alle lede in kennis stel van die finalisering en beskikbaarheid van die Stemkonsep en die voorgestelde Aannemingsdatum. Die aannemingsdatum sal opgestel word en in kennis gestel word aan alle lede in ooreenstemming met die verordeninge en die aannemingsdatum sal minstens 14 dae wees nadat die kennisgewing aan die lede gegee is. Nadat kennisgewing van die voorgestelde Aannemingsdatum aan lede verskaf is, kan die BoD regstellings van tipografiese foute in die Stemontwerp goedkeur sonder om 'n bykomende kennisgewing van die voorgestelde Aannemingsdatum in te dien en die vereiste 14 dae te wag.

Die volgende dokumente moet voor die Aannemingsdatum voltooi en aan die BoD beskikbaar gestel word:

Die stemkonsep
'N Weergawe-weergawe van die Stemkonsep wat alle wysigings aan die aangenome weergawe van die spesifikasie toon wat dieselfde XY-waarde het (bv. As die Stemkonsep as weergawe 1.4.2 voorgestel word, sal die veranderinge teenoor die 1.4.1 gevolg word. weergawe van die spesifikasie)
'N Aanbeveling van die spesifikasie-eienaar vir die afskaffing of terugtrekking van enige vorige weergawe (s) van die aangenome spesifikasie, tesame met 'n regverdiging
'N Lys met die oorblywende onopgeloste regskwessies uit die regsadviesview (indien enige)
Die BTI-goedgekeurde toetspakket, ICS en IXIT (indien die onderhoudvrystelling vereis)
Die BTI- en BQRB-goedgekeurde TCRL (indien die onderhoudvrystelling vereis)
'N Verslag voltooi deur BSTS tesame met BTI rakende die status van gereedheid vir gereedskap (bv. PTS en ander toetsgereedskap, Bluetooth Launch Studio), insluitend enige toetsgevalle in die TCRL wat nie deur toetsgereedskap ondersteun word nie, en 'n verduideliking (indien nodig deur die onderhoud vrylating)
'N Aannemings-kontrolelys wat deur BSTS en die spesifikasie-eienaar voltooi is, wat toon dat die aflewerings in hierdie afdeling alles voltooi is
Alle ander inligting wat deur die BoD aangevra word

Die instandhoudingsvrystellingsproses is afgehandel wanneer die BoD die Stemontwerp aanvaar het en die volgende aktiwiteite na die aanneming voltooi is:

BSTS het die goedgekeurde spesifikasie en gepaardgaande toetsdokumente (indien vereis deur die onderhoudsverklaring) openbaar gemaak op die Bluetooth SIG webwebwerf.
BSTS het 'n insiggewende weergawe van verandering van die voorheen goedgekeurde spesifikasieweergawe beskikbaar gestel met alle veranderings wat in die nuut aangeneem weergawe ingesluit is, beskikbaar vir alle lede op die Bluetooth SIG webwebwerf.
BSTS het die kwalifikasiestelsel geaktiveer.
BSTS het alle lede in kennis gestel van die beskikbaarheid van die aangenome spesifikasie en ondersteunende dokumente.

Die Bluetooth SIG beplan om hierdie na-aannemingsaktiwiteite binne een week na aanvaarding van die spesifikasie te voltooi.

Na voltooiing van hierdie aktiwiteite bly die spesifikasie in die spesifikasie-instandhoudingsfase totdat die spesifikasie verouderd of ingetrek word, soos omskryf in Afdeling 8.

8. Spesifikasie Einde van die lewensfase

Spesifikasies kan afgekeur of ingetrek word as dit vervang word deur nuwer weergawes, wat tegnies onvoldoende is, of om ander redes. Uitgediende en teruggetrokke spesifikasies word geargiveer en nie meer opgedateer nie. Uitgediende en teruggetrokke spesifikasies word anders behandel in die Bluetooth-kwalifikasieprogram.

Enige lid, groep of komitee kan aanbevelings indien om 'n spesifikasie te verswak of terug te trek saam met 'n gepaardgaande tydlyn aan BSTS (per e-pos aan

specification.manager@bluetooth.com) te eniger tyd. BSTS kan ook afskaffing of onttrekking van 'n spesifikasie en gepaardgaande tydlyn aanbeveel. BSTS sal die aanbeveling verwys na BARB en die groep of komitee wat verantwoordelik is vir die instandhouding van die spesifikasie vir t.o.vview en terugvoer.

BARB en die verantwoordelike groep of komitee sal aanbevelings om 'n spesifikasie te verswak of terugtrek evalueer en die volgende (nie-volledige) kriteria oorweeg:

Is daar funksionaliteit in 'n vorige weergawe van die spesifikasie wat verouderd is of nie gebruik moet word nie?
Is nuwe verpligte funksies by latere weergawes gevoeg?
Is daar tekortkominge in vroeëre weergawes wat die werking of interoperabiliteit benadeel, wat in latere weergawes reggestel is en wat nodig is om bestaande gebruikerscenario's te bevorder?
Is daar addisionele funksies in latere weergawes nodig om nuwe gebruikerscenario's te bevorder?
Is daar verbeterde bruikbaarheid en interoperabiliteit in latere weergawes?
Is daar veiligheidsverbeterings in latere weergawes?

BARB en die verantwoordelike groep of komitee kan 'n alternatiewe aanbeveling voorstel.

Nadat terugvoer ontvang is van BARB of die groep of komitee wat verantwoordelik is vir die handhawing van die spesifikasie, sal BSTS die aanbeveling (s) en terugvoer aan die BoD voorlê vir oorweging. Die BoD kan die groep of komitee wat verantwoordelik is vir die handhawing van die betrokke spesifikasies nooi om die aanbevelings te ontmoet en te bespreek. Die BoD sal aanbevelings en terugvoer oorweeg en kan met die voorstel saamstem of dit wysig. Die BoD sal versoek dat BSTS alle lede in kennis stel van die voorstelle om spesifikasie (s) en gepaardgaande tydlyn (s) vir 'n tydperk van 30 dae af te skaf of terug te trekview tydperk sodat alle lede addisionele terugvoer kan gee voordat hulle die finale besluit neem.

Die BoD sal die terugvoer van lede oorweeg. Sodra die BoD die verval of intrekking van 'n spesifikasie goedkeur, sal BSTS alle lede in kennis stel van die besluit en die gepaardgaande tydlyn.

8.1 Afwyking

Sodra 'n spesifikasie verouderd is, sal die volgende plaasvind:

Die spesifikasie sal nie meer opgedateer word nie.
Die verantwoordelike WG sal t.o.v.view alle uitstaande foute wat teen die verouderde spesifikasie geskryf is om te bepaal of dit van toepassing is op ander spesifikasies. Errata kan in die errata -stelsel verwerp word en teen die toepaslike spesifikasie (s) herskryf word.
Die WG of BSTS sal foute skep om die nodige verwysings na verouderde spesifikasies in ander spesifikasies by te werk.
BTI sal die toepaslike toetsdokumente opdateer om die verswakking van die spesifikasie aan te dui.
BSTS sal die Bluetooth SIG opdateer webwebwerf met leiding oor alternatiewe spesifikasie (s) om te gebruik.
Nuwe errata kan nie meer teen 'n verouderde spesifikasie ingedien word nie.
Daar sal nie in die toekomstige spesifikasies na die spesifikasie verwys word nie.
BSTS sal 'n weergawe van die spesifikasie wat as verouderd gemerk is, argiveer vir toegang tot historiese doeleindes.

8.2 Onttrekking

Sodra 'n spesifikasie ingetrek is, sal die volgende, benewens die stappe wat van toepassing is op afskrywing, plaasvind:

BTI sal die toepaslike toetsdokumente opdateer om aan te dui dat die spesifikasie teruggetrek is.
BSTS sal die Bluetooth SIG opdateer webwebwerf met leiding oor alternatiewe spesifikasie (s) om te gebruik.
BSTS argiveer 'n weergawe van die spesifikasie wat gemerk is as onttrek vir lede om toegang tot historiese doeleindes te kry.

Die BoD kan kies om 'n spesifikasie onmiddellik te onttrek sonder om eers die spesifikasie te verswak.

9. Witskrifproses

Witskrifte word slegs vir inligting gemaak. Die volgende witboekproses is van toepassing op alle Bluetooth-WG's, EG's, SG's en komitees. Hierdie afdeling is nie van toepassing op inligtingstukke wat slegs binne die Bluetooth SIG gebruik kan word nie.

Hierdie proses word in Figuur 9.1 hieronder geïllustreer.

Voordat enige groep of komitee begin werk aan 'n witskrif wat hulle van plan is om deur Bluetooth SIG gepubliseer te word, sal die groep of komitee 'n voorgestelde handvesopdatering opstel wat die voorgestelde inhoud van die witskrif duidelik definieer en 'n aanbieding van die witskrifvoorstel.

Die aanbieding van die witskrif moet ten minste die volgende insluit:

Die behoefte aan die witskrif
'N Opsomming van die voorgestelde inhoud van die witskrif
'N Verduideliking waarom die inhoud nie aanbeveel word as deel van 'n spesifikasie nie
Die beoogde gehoor
Enige instandhoudingsplanne (dws die geskatte tyd voor die volgende vrystelling van hierdie witskrif mag nodig wees)
Aanbevelings vir die hantering van vorige weergawes van die witskrif, indien van toepassing (bv. Argivering)

Die handves -opdatering en voorlegging van die witskrifvoorstel moet ingedien word vir BARB review. By review en goedkeuring van die opdatering van die handves deur BARB, sal BSTS die opdatering van die handves aan die BoD voorlê vir goedkeuring saam met die ondersteunende voorlegging van die witskrifvoorstel.

As die BoD die handvesopdatering goedkeur, kan die groep of komitee voortgaan met die ontwikkeling van die witskrif.

As die groep of komitee die ontwikkeling van die witskrif voltooi het, sal BSTS 'n redaksionele bespreking doenview in ooreenstemming met die Bluetooth -riglyne vir opstel.

Na beslegting van BSTS -kommentaar, moet die groep die witskrif aan BSTS voorlê vir regsreëlingsview. Na voltooiing van die wettige review, sal die groep en BSTS ooreenkom oor die terugvoer wat in die witskrif opgeneem moet word. As daar onopgeloste regskommentaar van regsadvies isview op die witskrif kan die groepvoorsitter tyd op die BoD -agenda versoek om insette van die BOD oor resolusie te kry.

In parallel met wetlike t.o.v.view, moet die groep die witskrif by BARB indien vir herverklaringview. As deel van hul review, Kan BARB aanbeveel of enige deel van die witskrif uit die witskrif verwyder moet word en in die spesifikasie opgeneem moet word na aanleiding van die proses in afdeling 3. BARB kan ook besluit om die witskrif aan ander groepe of komitees voor te lêview. Na voltooiing van BARB t.o.v.view, sal die groep en BARB ooreenkom oor die terugvoer wat in die witskrif opgeneem moet word.

Nadat die BARB die witskrif goedkeur, sal die BARB-goedgekeurde witskrif deur die outeursgroep of komitee aan die BoD voorgelê word vir goedkeuring.

Die witboekproses is voltooi wanneer die BoD die witskrif goedkeur en die volgende goedkeuringsaktiwiteite voltooi is:

BSTS het die goedgekeurde witskrif openbaar gemaak op die Bluetooth SIG webwebwerf.
BSTS stel alle lede van die goedgekeurde witskrif in kennis.
As die witskrif 'n verbetering van 'n bestaande witskrif is, sal BSTS 'n weergawe van die witskrif argiveer waarvoor lede toegang het vir historiese doeleindes.

Die Bluetooth SIG beplan om die aktiwiteite na goedkeuring binne een week na goedkeuring van die witskrif te voltooi.

10. Verwysings

Bluetooth -dokumente waarna verwys word, is beskikbaar by die Bluetooth webwebwerf http://www.bluetooth.com.

Riglyne vir die opstel van Bluetooth (beskikbaar op die blad Werkgroepsjablone en -dokumente, by https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Reglement van die Bluetooth SIG, Inc. (beskikbaar op die bladsy Besturende dokumente, by https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Bluetooth-spesifikasie Errata-prosesdokument (beskikbaar op die bladsy Werkgroep Sjablone en dokumente, by https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Werkgroep-prosesdokument (beskikbaar op die bladsy Werkgroepsjablone en -dokumente, by https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Toetsstrategie en terminologie verbyview dokument (beskikbaar op die bladsy met vereistes vir kwalifiseringstoets, by https://www.bluetooth.com/specifications/qualification-test-requirements)
BTI Spesifikasie Review Verwerk kontrolelys (beskikbaar op die werkgroep sjablone en dokumente bladsy, by https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Bluetooth SIG-toegekende nommers (https://www.bluetooth.com/specifications/assigned-numbers)
Werkgroepsjablone en -dokumente (beskikbaar op die blad Werkgroepsjablone en -dokumente, by https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
GATT Specification Supplement (GSS) (beskikbaar op die GATT Spesifikasies bladsy, by https://www.bluetooth.com/specifications/gatt)
Dien 'n idee in vir 'n nuwe spesifikasie https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Akronieme en afkortings

Tabel A: akronieme en afkortings

Aanhangsel A - Erratum-ernsklassifikasie

Hierdie bylaag gee 'n opsomming van riglyne vir die klassifikasie van erns vir 'n spesifikasie erratum. Hierdie tabel sal bygevoeg word by 'n toekomstige hersiening van die EPD, en dan sal hierdie afdeling verwyder word.

Lees meer oor hierdie handleiding en laai PDF af:

Spesifikasiebestuursprosesdokument (SMPD) - Geoptimaliseerde PDF
Spesifikasiebestuursprosesdokument (SMPD) - Oorspronklike PDF

Vrae oor jou handleiding? Plaas in die kommentaar!

Verwysings

Gebruikershandleiding