Sérhæfingarskjal um vinnslustjórnun
Bluetooth® ferli skjal
- Endurskoðun: V27
- Endurskoðunardagur: 2019-05-17
- Tölvupóstur við álit: BARB-feedback@bluetooth.org
Ágrip:
Þetta skjal skilgreinir þróunarferla til að búa til og auka Bluetooth forskriftir og hvítbækur.
Endurskoðunarsaga
Framlag af nýjustu útgáfunni
Þetta skjal, án tillits til titils eða innihalds, er ekki Bluetooth-forskrift háð leyfum sem veitt eru af Bluetooth SIG Inc. („Bluetooth SIG“) og meðlimum þess samkvæmt Bluetooth einkaleyfis- / höfundarréttarleyfissamningi og Bluetooth vörumerkjaleyfissamningi.
ÞETTA skjal er afgreitt eins og það er og BLUETOOTH SIG, ÞÁTTIR, OG FÉLAGSMENN ÞEIRIR EKKI FYRIRSKYNDIR OG ÁBYRGÐIR OG FRÁVARA ÖLLAR ÁBYRGÐIR, SKÝRT EÐA UNDANFARIÐ, ÞÁTT Á ÖRYGI ÓVIÐSKYLDU, ÓVIÐSKYRÐI, ÓVÆÐI, ÓVÆÐI, ÓVÆÐI, ÓVÆÐI AÐ INNIHALD ÞETTA SKJÁLS ER ÓKEYPIS.
Í því marki sem ekki er bannað samkvæmt lögum, BLUETOOTH SIG, ÞÁTTIR, OG FÉLAGAR FYRIRVARA ALLT ÁBYRGÐ sem stafar af eða tengist notkun þessa skjals og allar upplýsingar sem eru geymdar í þessu skjali, að meðtöldu miklu magni, réttu magni, Truflun, eða vegna sérstakra, óbeinna, afleiðinga, tilfallandi eða fjárhagslegra tjóna, þó sem orsakast og án tillits til kenningar um ábyrgð, og jafnvel þó að BLUETOOTH SIG, meðlimir hennar, eða starfsmenn þeirra hafi verið ráðnir af þeim sem hafa verið fulltrúar þeirra.
Þetta skjal er í eigu Bluetooth SIG. Þetta skjal getur innihaldið eða fjallað um efni sem er hugverk Bluetooth SIG og meðlima þess. Veiting þessa skjals veitir ekki leyfi fyrir hugverkum Bluetooth SIG eða meðlimum þess.
Þetta skjal getur breyst án fyrirvara.
Höfundarréttur © 2004–2019 af Bluetooth SIG, Inc. Bluetooth orðmerkið og lógó eru í eigu Bluetooth SIG, Inc. Önnur vörumerki þriðja aðila og nöfn eru eign viðkomandi eigenda.
1. Inngangur
The Specification Management Process Document (SMPD) lýsir ferlunum sem forskriftarhöfundar og umviewaðilar verða að fylgja eftir til að þróa nýjar forskriftir og til að bæta núverandi forskriftir (þ.e. að bæta við eða fjarlægja virkni eða breyta tiltekinni virkni í samþykktri forskrift), til að viðhalda samþykktum forskriftum og stjórna lok líftíma samþykktra forskrifta. Að auki lýsir þetta skjal ferlinu við að búa til, umviewing, og samþykkja hvítbækur.
Það er munur á þróunarferli forskriftar á milli þess að þróa nýjar forskriftir og auka núverandi forskriftir vegna eðlislægs munur á umfangi þessara verkefna; sá munur er dreginn fram í þessu skjali.
Sértæktarþróunarferlið felur í sér:
- A Kröfufasa (lýst í kafla 3) til að skilgreina kröfur um virkni
- Þróunaráfangi (lýst í kafla 4) til að þróa og endurnýjaview forskriftir
- Löggildingarfasa (lýst í kafla 5) til að staðfesta forskriftirnar með prófun á samvirkri frumgerð (IOP)
- Ættleiðingar / samþykkisáfangi (lýst í kafla 6) til að kynna upplýsingarnar fyrir stjórn Bluetooth SIG (BoD) til samþykktar / samþykktar
Specification Errata Process skjalið (EPD) [3] lýsir ferlinu við að leggja til og endurskoðaviewing forskriftir og samþykkja þær sem villuleiðréttingar (eins og skilgreint er í samþykktum [2]) við samþykktar forskriftir. Nema annað sé tekið fram, þýða allar tilvísanir í frávik í þessum SMPD forskriftarvillur.
1.1 Forgangur
Samþykkt Bluetooth SIG, Inc. (samþykkt) og aðildarsamningar [2] ganga framar öllu andstæðu efni í þessum skjölum og SMPD. Þrátt fyrir nokkuð í þessu skjali heldur BoD fullkomnu valdi og valdi til að grípa til aðgerða og taka ákvarðanir, jafnvel þótt þessar aðgerðir og ákvarðanir fylgja ekki, eða stangast á við neitt í þessu skjali, og ekkert í þessu skjali takmarkar eða takmarkar sjálfstætt vald BoD og geðþótta.
Ef einhver árekstur er á milli textans í SMPD og tölunum hefur textinn forgang.
1.2 Hópar og nefndir sem vísað er til
Í þessu skjali er vísað til eftirfarandi tegunda hópa: Námshópar (SG), Sérfræðihópar (EG) og Vinnuhópar (WG). WG getur líka haft undirhóp sem heyrir undir WG. Á sama hátt er vísað til eftirfarandi tegunda nefnda í þessu skjali: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI) og Bluetooth Qualification Review Stjórn (BQRB). Þetta skjal vísar einnig til Bluetooth SIG Technical Staff (BSTS) og BoD.
1.3 Nefnd umviews og samþykki
Nefnd umview er afturview sem er unnin af nefndarmönnum (venjulega 3 meðlimir) til að veita endurgjöf innan tiltekins tíma (venjulega 2-3 vikur), þóview tími getur verið breytilegur eftir lengd og flóknu efni og öðrum áherslum innan nefndarinnar. Hópurinn sem óskar eftir þvíview og nefndin sem fer með umrview hver og einn er sammála um lengd endurskoðunarinnarview. Hópurinn og nefndarmenn nota Bluetooth SIG verkfærin til að tilkynna og skrá upphaf og lok endurtekningarview. Hópurinn mun almennt vinna úr umsögnum nefnda þegar þær berast. Þegar nefndin umrview tíminn rennur út, lýkur hópurinn við að takast á við endurgjöf nefndarinnar og ætti einnig að íhuga hvers kyns endurkomu sem kemur seintview endurgjöf með það í huga að efnið getur verið háð síðari samþykki nefndarinnar.
Samþykki nefndar fæst með atkvæðagreiðslu nefndarmanna í samræmi við vinnuskjalið um vinnuhópinn [4].
1.4 Tilkynningar til félagsmanna og aðgengi efna
Allar tilkynningar sem félagsmenn fá samkvæmt þessu skjali geta verið sendar með tölvupósti, svo sem reglulega tæknilega uppfærslu. Tilkynningar sem allir félagsmenn eiga að senda verða sendir öllum virkum meðlimum (þ.e. þar sem aðild hefur ekki verið stöðvuð, hætt eða afturkölluð). Þegar tilkynningar eru sendar í tölvupósti verða þær sendar á síðast netþekkt netfang (eins og það birtist í þágildandi skrám Bluetooth SIG) um hvern einstakling sem hefur skráð sig undir félagsreikning aðildarfélagsins og hefur ekki afþakkað að fá tilkynningar í tölvupósti. Ekkert í þessu skjali breytir skuldbindingum eða kröfum Bluetooth SIG varðandi tilkynningu samkvæmt samþykktum eða öðrum samningi milli Bluetooth SIG og einhvers meðlims.
Hvar sem þetta skjal vísar til a websíðu sem er aðgengileg öllum meðlimum, þetta vísar til aðgengis fyrir einstaklinga sem eru með virkan Bluetooth SIG reikning. Meðlimir sem ekki eru með virkan reikning geta búið til reikning í gegnum Bluetooth SIG websíða.
1.5 Sniðmát
Fyrir hverja skjalategund (td forskriftir, hvítblöð, prófunarskjöl) sem vísað er til í þessu SMPD, veitir Bluetooth SIG sniðmát. Sniðmátið verður að nota sem grunn fyrir hvert skjal sem framleitt er í samræmi við þetta SMPD. Ef ekki er notað rétt sniðmát getur það leitt til þess að skjalið verði ekki samþykkt. Sniðmát eru fáanleg á Bluetooth SIG websíða [8].
1.6 Tegundargerðir
Það eru nokkrar gerðir af Bluetooth SIG forskriftum. Stigveldislega eru allar forskriftir háðar Bluetooth Core Specification. Tæknilýsing eins og hefðbundin profiles; hefðbundnar samskiptareglur; og GATT-undirstaða profiles, GATT-undirstaða þjónusta og GATT-undirstaða samskiptareglur eru öll háð eiginleikum kjarnaforskriftarinnar. Aðrar forskriftir, eins og upplýsingar um Mesh Model, eru háðar Mesh Profile forskrift sem aftur fer eftir kjarnaforskriftinni.
Core Specification Supplement (CSS) forskriftin skilgreinir gagnategundir, gagnasnið og algenga atvinnumennfile og þjónustuvillukóða sem eru notaðir af kjarnaforskriftinni og öðrum forskriftum og skilgreina ekki sjálft neina hegðun.
GATT Specification Supplement (GSS) forskriftin skilgreinir einkennis- og lýsingarsnið sem eru notuð af Profiles og þjónustu og skilgreinir ekki sjálft neina hegðun.
Mesh Device Properties (MDP) forskriftin skilgreinir möskvaeiginleika sem notuð eru af Mesh Profile og Mesh Model forskriftir og skilgreinir ekki sjálft neina hegðun.
2. Yfirview
Þessi hluti veitir yfirview af ferlunum og er ekki ætlað að innihalda allar upplýsingar.
Mynd 2.1 sýnir sex helstu áfangana sem mynda Stjórnunarferli fyrir lýsingu.
Fyrstu fjórir áfangarnir eiga sér stað meðan á þróunarferlinu stendur og samanstanda af kröfuáfanga (kafli 3), þróunarstigi (kafli 4), löggildingaráfanga (kafli 5) og ættleiðingar / samþykkisáfanga (kafli 6). Í kjölfarið fylgja tveir áfangar eftir ættleiðingu: Viðhaldsáfangi forskriftar (7. hluti) og Úrslitaáfangi forskriftar (8. hluti).
Mynd 2.2 sýnir smáatriði fjögurra áfanga innan þróunarferlisins. Gráu reitirnir gefa til kynna helstu afhendingar fyrir hvern áfanga. Appelsínugulu kassarnir draga saman tímamótin í ferlinu.
Í kröfuáfanganum (lýst í kafla 3) hefur tillaga um að hefja nýtt verk (Nýtt verkatillaga (NWP)) frumkvæði að þróunarferli forskriftar með því að skilgreina þær sviðsmyndir notenda sem gera skal kleift ef nýja verkið heldur áfram. Ef NWP er samþykkt skapar úthlutaður hópur Functional Requirements Document (FRD). Þegar FRD hefur verið samþykkt og úthlutað í hóp hefst þróunarstigið.
Á þróunarstiginu (lýst í kafla 4) þróast forskriftir í gegnum röð af stages (0.5/DIPD til 0.9/CR) sem lýkur með fullkomnu uppkasti að forskriftinni. 0.9/CR forskriftin er gerð aðgengileg öllum félagsmönnum, síðan send til BoD sem skoðar forskriftina til samþykktar. Þegar það hefur verið samþykkt hefst löggildingarfasinn.
Á fullgildingarfasa forskriftarþróunar (lýst í kafla 5) er BoD-samþykkt 0.9/CR forskrift gerð aðgengileg öllum meðlimum til að endurskoðaview og staðfesta, og Member Review er hafin. Staðfesting er framkvæmd með samvirkniprófun (IOP) milli frumgerða sem eru smíðaðar af meðlimum. Þegar IOP prófun er lokið (ef þess er krafist fyrir forskriftina) og BARB samþykkir IOP prófunarskýrsluna, þá hefst ættleiðingar-/samþykkisfasinn.
Í ættleiðingar / samþykkisáfanga (lýst í kafla 6) er gengið frá forskriftinni og tilheyrandi prófskjölum; BARB, BQRB og BTI samþykki berast; og endanlegi forskriftarpakkinn er lagður fyrir BoD sem íhugar forskriftina til ættleiðingar (þ.e. endanlegt samþykki).
Forskrift gæti þurft að fara aftur í fyrri áfanga eða stage ef verulegar breytingar verða gerðar. Í sumum tilfellum getur líka verið hægt að afsala sér hluta áfanga eins og lýst er í kafla 4.4.
Sérstakur viðhaldsáfangi (lýst í kafla 7) hefst eftir að forskrift er samþykkt af BoD. Í þessum áfanga er greint frá og metin mögulegar villur sem finnast í samþykktri forskrift og (ef þörf krefur) Errata leiðréttingar gerðar á forskriftinni. Viðhaldsáfangi forskriftar heldur áfram þar til forskriftin er úrelt eða dregin til baka (sjá Úrgangsfasa forskriftar í eftirfarandi málsgrein).
Útskriftarlokunarlýsingin (lýst í kafla 8) lýsir ferlinu við úreldingu og afturköllun samþykktra forskrifta.
3. Kröfuáfangi
Kröfuáfanginn hefst annaðhvort með NWP (þar sem fram kemur löngun til að hefja vinnu við eina eða fleiri notendaviðburði) eða eftir ákvörðun um að nýja verkið sem óskað er eftir sé þegar fallið undir skipulagsskrá WG þeirra. Ef WG vill hefja nýtt verk sem það telur að sé þegar innan gildissviðs WG verður WG að fylgja því ferli sem skilgreint er í kafla 3.1 til að halda áfram að þróa FRD. Fyrir alla aðra verkþætti verður WG að fylgja því ferli sem skilgreint er í kafla 3.2. FRD skilgreinir umfang starfskrafna sem notaðar eru til að byggja upp forskriftir í þróunarstiginu. Kröfuáfanginn er sýndur á mynd 3.1.
3.1 Ný verk sem falla undir WG skipulagsskrá
Þegar WG vill hefja nýtt verk og telur með sanngirni að virkni sem það vill bæta við sé þegar innan gildissviðs WG skipulagsins, getur WG hafið störf við FRD, að því tilskildu að þeir láti BARB strax vita. WG mun fela í tilkynningu til BARB lýsingu á fyrirhuguðu nýju verki og afrit af WG skipulagsskránni með tungumáli auðkennd sem heimilar þeim að hefja nýja verkið.
Ef BARB hafnar greiningu WG, verður WG að hætta vinnu við FRD og halda áfram með NWP ferlið sem lýst er í kafla 3.2. Ef BARB samþykkir greiningu WG mun WG strax tilkynna BSTS (með tölvupósti á specification.manager@bluetooth.com) og BSTS bætir atriðinu við næstu BoD dagskrá.
WG mun fela í sér tilkynningu til BSTS sömu upplýsingar og hún gaf BARB. Ef BoD hafnar greiningu WG verður WG að hætta að vinna við FRD og halda áfram með NWP ferlið sem lýst er í kafla 3.2. Ef BoD samþykkir greiningu WG getur WG haldið áfram að vinna að FRD eins og lýst er í kafla 3.3.
3.2 Ný vinnutillaga (NWP)
Sérhver meðlimur, WG, SG eða EG getur búið til og sent inn NWP (í gegnum Bluetooth SIG websíða [10]). NWP verður að innihalda, að lágmarki, upplýsingar um eftirfarandi með því að nota opinbera sniðmátið sem gefið er upp í [8]:
- Sviðsmyndir notenda
- Skuldbinding meðlima um að þróa FRD og á hvaða sviðum (td þátttakandi, höfundur, Revieweh, frumgerð)
- Fyrirhuguð forysta FRD starfsins
- Fyrirhugað hópverkefni fyrir FRD starfið
- Netfang aðalhöfundar
Athugið: Leiðbeiningar um NWP ferlið eru fáanlegar á Bluetooth SIG websíða [10].
BSTS mun sinna eftirfarandi verkefnum við þróun NWP:
- Veittu höfundi (s) viðurkenningu á móttöku (venjulega innan sjö almanaksdaga frá móttöku) og gerðu grein fyrir næstu skrefum.
- Ef nauðsyn krefur skaltu vinna með höfundinum / höfundunum svo að NWP sé skýrt og fullkomið. Þetta gæti þurft nokkrar endurtekningar á NWP.
- Ef NWP inniheldur yfirlýsingar um villur í samþykktum Bluetooth-forskriftum skaltu vinna með höfundinum/höfundunum file færslur í errata kerfið.
- Ef tekið er eftir því að NWP sé hugsanlega að fjölfalda verk sem þegar er í vinnslu eða þegar hefur verið lokið, láttu höfund (ar) vita um hitt verkið til mats.
- Sendu NWP til NWP websíða aðgengileg öllum félagsmönnum.
- Láttu alla meðlimi vita að NWP sé tiltækt til endurnýjunarview og hvort þörf sé á frekari skuldbindingu aðildarríkja til að þróa FRD.
Félagsmenn geta haft samband við höfund (a) til að spyrja spurninga eða til að veita álit varðandi NWP.
Að minnsta kosti þrjú aðildarfyrirtæki verða að skuldbinda sig til að taka þátt í að ljúka FRD sem myndast vegna þess að NWP verði frambjóðandi fyrir samþykki BoD og að minnsta kosti eitt aðildarfélag verður að vera meðeigandi eða verkefnisstjóri. Eftir samþykki BoD NWP mun BoD úthluta NWP til núverandi WG undirhóps eða SG til að vinna að FRD (lýst í kafla 3.3). Ef viðeigandi WG undirhópur eða SG er ekki til getur verið stofnaður einn.
Fyrir NWP sem hafa næga skuldbindingu meðlima mun BSTS framkvæma eftirfarandi viðbótarverkefni:
- Að minnsta kosti 13 dögum áður en lagt er til að NWP verði samþykkt af BoD, tilkynntu BARB og hópnum sem NWP er mælt með til úthlutunar um yfirvofandi NWP samþykki. Þetta er gert til að veita tækifæri fyrir endurgjöf á sviðum eins og fyrirhuguðum hópi, hvort sem NWP er þegar undir núverandi vinnu o.s.frv.
- Sendu lokið NWP til BoD.
- Ef NWP er lögð fram af meðlimum sem ekki eru í tengslum við hóp skaltu sjá til þess að einn meðlimanna kynni NWP fyrir BoD.
- Ef NWP er lögð fram af hópi, skipuleggðu hópformanninum að kynna NWP fyrir BoD.
- Bjóddu BARB formanninum og formönnum hópsins, sem mælt er með NWP til verkefnis, á BoD fundinn.
- Ef NWP er samþykkt og úthlutað af BoD, láttu þá hópinn vita sem honum var falið; höfundur (s); meðlimirnir sem tilgreindir eru í NWP sem skuldbinda sig til að þróa samsvarandi FRD; og ef hópurinn leggur til NWP, hópinn um niðurstöðuna og næstu skref.
Eftir að NWP hefur verið samþykkt af BoD, uppfærðu stöðuna á NWP websíða.
Sérhverjum NWP getur verið hafnað af BoD að eigin geðþótta, tdample, vegna takmarkana á tilföngum, ef verkinu er þegar að fullu lokið, er verkið utan gildissviðs stjórnarskjala Bluetooth SIG (td forritunarviðmótið (API)) [2], eða ef verkið sem lagt er til ætti að vera filed sem frávik. Ef NWP er hafnað mun BSTS láta höfundinn/höfundana vita, meðlimina sem tilgreindir eru í NWP sem skuldbinda sig til að þróa samsvarandi FRD og, ef NWP er lagt til af hópi, hópurinn. Tilkynningin mun innihalda hvers kyns ástæður fyrir höfnuninni. Höfundur(ar), skuldbundnir meðlimir eða hópur geta óskað eftir tíma á dagskrá BoD til að áfrýja höfnuninni.
Ef félagi eða hópur vill leggja til að fjarlægja eiginleika úr samþykktri forskrift, verður hópurinn eða meðlimurinn að undirbúa NWP. NWP verður að fela í sér greiningu á þeim áhrifum sem fjarlægingin mun hafa á samhæfni aftur á bak og samvirkni, þar með talin greining á áhrifum á próftilvik.
NWP er ekki krafist vegna endurbóta á CSS, GSS eða MDP forskriftum: venjulega eru uppfærslur á CSS, GSS eða MDP forskriftum vegna uppfærslna í öðrum forskriftum sem hafa eigin NWP.
3.3 Skjal um hagnýtar kröfur (FRD)
FRD skilgreina virkni kröfur til að gera atburðarás notenda kleift. FRD verður að innihalda, að lágmarki, upplýsingar um eftirfarandi með því að nota hið opinbera sniðmát sem gefið er upp í [8]:
- Sviðsmyndir notenda
- Hagnýtar kröfur byggðar á sviðsmyndum notenda
- Skuldbinding meðlima til að þróa forskriftina
- Valfrjáls stuðningur við frumgerð meðlima fyrir hlutverkin sem búist er við
- Mælt er með WG til að þróa forskriftina
FRD þróun
FRD eru búnar til af úthlutuðum WG undirhópi allra aðila eða SG meðlimum með ritstjórnarstuðningi frá BSTS. Sérhver meðlimur sem hefur áhuga á að taka þátt í þróun FRD getur gengið í hópinn.
FRD verða að gefa til kynna skuldbindingu frá að minnsta kosti tveimur (þó að þrír séu hvattir) hlutdeildar- eða verkefnisstjórar á aðildarstigi til að taka þátt í þróun forskriftarinnar sem af verður. WGs eða SGs sem leggja fram FRD ættu að reyna að ná víðtækum stuðningi frá fyrirtækjum í aðilum í hópnum sem eru fulltrúar fyrirhugaðs markmiðsgreina sem tilgreind er í FRD.
Ný virkni sem lögð er til í FRD ætti að vera studd á eins mörgum flutningum og núverandi tækjum og mögulegt er. Þetta felur í sér tdample, styður GATT-undirstaða atvinnumaðurfiles og þjónustu á bæði Basic Rate/Extended Data Rate (BR/EDR) flutning og Bluetooth Low Energy (LE) flutning. Ef nýja virkni skortir nægjanlegan stuðning meðlima fyrir flutning, tdampLe vegna skorts á skuldbindingu aðildarfélaga um að skilgreina notkun flutningsins eða hugsanlega ófullnægjandi fjölda IOP prófunarpalla fyrir eitt eða fleiri hlutverk, getur stuðningur við þann flutning verið útilokaður frá FRD.
Nema annað sé réttlætanlegt, ný virkni, profiles, og þjónusta verður að vera í samræmi við afturábak eindrægni kröfur sem lýst er í kafla 3.3.2.
WG eða SG verða að leggja fram FRD til BARB til endurbótaview og samþykki. BARB verður annað hvort að samþykkja eða hafna FRD á grundvelli verkfræðidóms þess. Ef BARB samþykkir, verður FRD aðgengilegt öllum meðlimum og tilkynning um framboð hans verður gefin út af BSTS.
FRD er ekki krafist vegna endurbóta á CSS, GSS eða MDP forskriftum: venjulega eru uppfærslur á CSS, GSS eða MDP forskriftum vegna uppfærslna í öðrum forskriftum sem hafa sínar eigin FRD.
Kröfur um afturvirkni eindrægni
Aftur samhæfni fyrir BR / EDR
Fyrir BR / EDR notkun er skilyrði fyrir afturvirkni skilgreind sem samvirkni við BR / EDR hluta Bluetooth Core Specification v1.1 og nýrri.
Aftur samhæfni fyrir Bluetooth Low Energy
Fyrir LE-notkun er kröfur um samhæfni afturábak skilgreindar sem samvirkni við LE-hluta Bluetooth-kjarnaforskriftar v4.0 og síðar.
Aftur samhæfni fyrir aðrar forskriftir en kjarnaforskriftina
Fyrir aðrar forskriftir en Bluetooth Core Specification verður að viðhalda afturábakssamhæfi tiltekinnar útgáfu með öllum eldri útgáfum sem hafa sama aðalútgáfunúmerið. Til dæmisample, útgáfa 1.3 verður að vera samhæf við útgáfur 1.2, 1.1 og 1.0, en útgáfa 2.0 gæti ekki verið samhæf við útgáfur 1.0, 1.1, 1.2 og 1.3. Athugaðu að hækkun á aðalútgáfunúmeri kjarnaforskriftarinnar þýðir ekki skort á afturábakssamhæfi við fyrri útgáfur.
Undanþága frá kröfum um afturvirkni eindrægni
WG eða SG geta lagt til að undanþiggja sérstaka virkni frá kröfunni um baksamhæfi ef rökstuðningur er veittur. Til dæmisample, ef sýnt er fram á að virknin hefur lágt markaðshlutfall eða, vegna rekstrarsamhæfisvandamála, er betra að fjarlægja eða skipta um virkni en að breyta virkni. WG eða SG verða að innihalda allar undanþágur um baksamhæfi í FRD, sem eru samþykktar af BARB að fengnu samþykki FRD. Allar BARB-samþykktar undanþágur verða lagðar fyrir BoD til samþykkis á 0.9/CR Stage.
3.4 Stofnskrá starfshóps
Þegar BARB samþykkir FRD sem lagt er til að úthlutað verði til núverandi WG, verður WG að undirbúa drög að uppfærslu á stofnskrá sinni til að bæta nýju virkni við gildissviðið (nema BoD hafi áður samþykkt greiningu WG um að WG skipulagsuppfærsla sé ekki krafist). Hins vegar, þegar BARB samþykkir FRD sem lagt er til að verði úthlutað til nýrrar WG, verða BARB og félagar sem hafa áhuga á að þróa virkni sem lýst er í FRD að útbúa drög að skipulagsskrá fyrir nýja WG með nýju virkni sem er innifalin í skipulagsskrá .
Þegar ný eða uppfærð skipulagsskrá WG hefur verið útbúin verður að senda hana til BARB til endurskoðunarview og samþykki. Þegar BARB hefur samþykkt skipulagsskrána verða drög að nýju eða uppfærðu WG skipulagsskránni lögð fyrir BoD til samþykktar.
Þegar BoD hefur samþykkt sáttmálann verður WG sem þróunarstarfinu var úthlutað af BoD að vinna náið með þeim hópi sem undirbjó FRD ef þörf er á nauðsynlegum uppfærslum eða skýringum á því FRD. Ef þörf er á FRD uppfærslu meðan á þróunarstigi stendur verður að fylgja þeim ferlum sem lýst er í kafla 3.3 og þessum kafla; þó, þróun þróunar getur átt sér stað samhliða FRD og WG skipulagsuppfærslum.
3.5 Kröfur Kröfur um útgönguleiðir
Kröfuáfanganum er lokið og þróunarstigið hefst þegar WG skipulagsskrá með nauðsynlegu svigrúmi fyrir FRD er annað hvort staðfest eða samþykkt af BoD og eftirfarandi kröfur hafa verið uppfylltar:
- NWP hefur annað hvort verið samþykkt af BoD, eða BoD hefur samþykkt að NWP sé óþarfi.
- FRD og samsvarandi WG skipulagsskrá hefur verið samþykkt af BARB.
4. Þróunaráfangi
Á þróunarstiganum búa úthlutaðir WG (s) nýju forskriftina og / eða auka núverandi forskrift. FRD skilgreinir kröfur nýrrar eða aukinnar Bluetooth forskriftar. Engin virkni er leyfð í forskriftinni sem tengist ekki með sanngjörnum hætti kröfur í FRD. Markmiðið er að búa til 0.9 / CR forskrift sem er tilbúin fyrir löggildingaráfanga (lýst í kafla 5) við lok þróunaráfanga.
Á þróunarstiginu fer forskrift (eða forskriftaaukning) fram í gegnum þrjár stages.
Fyrir nýja forskrift, þrjár stages eru:
- 0.5 Stage
- 0.7 Stage
- 0.9 Stage
Til að auka forskrift, þrjár stages eru:
- Drög að úrbótatillöguskjali (DIPD) Stage
- Final Improvement Proposal Document (FIPD) Stage
- Breytingarbeiðni (CR) Stage
Hver stage er lýst nánar í undirköflum sem fylgja. Mynd 4.1 hér að neðan sýnir hin ýmsu skjöl sem WG mun útbúa á hverjum stage.
Mynd 4.1: Yfirview í forskrift stagsem eiga sér stað á þróunarstigi
Hlutverk BARB í öllu forskriftarþróunarferlinu er að veita WGs ráðgjöf og tæknilega aðstoð. WGs geta hvenær sem er beðið BARB um tæknilega ráðgjöf varðandi þróun forskriftar og byggingarhugtök sem nota á í forskrift. WG eru sérstaklega hvattir til að óska eftir snemma endurgjöf frá BARB vegna aðgerða sem hafa flóknari arkitektúrsjónarmið.
4.1 0.5/DIPD Stage
Á meðan á 0.5/DIPD Stage, WG mun þróa eftirfarandi með því að nota opinberu sniðmátið sem er að finna í [8]:
- Fyrir nýja forskrift, drög að 0.5 forskriftinni, sem verða að lágmarki að innihalda upplýsingar um eftirfarandi:
- Arkitektúr til að ná yfir kröfurnar eins og fram kemur í FRD
- Fyrir samskiptareglur eru þjónustuaðgangsstaðir skilgreindir
- Fyrir þjónustu, útsett gögn og hegðun
- Fyrir atvinnumennfiles, samskiptareglur auðkenndar og virkni tilgreind
2. Til að auka forskriftina skulu drög að DIPD, sem verða að lágmarki að innihalda upplýsingar um eftirfarandi:
- Bakgrunnur: Umfang vinnu, markmið sem leiða starfið og hvernig þessi sérstaka tillaga fellur að sviðinu
- Yfirview tillögunnar: Yfirlit yfir aukna virkni (aukinn sveigjanleika, bættan árangur o.s.frv.) Sem DIPD hefur að geyma, þar á meðal skýra lýsingu um hvernig nýja virkni fellur að núverandi forskriftarútgáfu. Ef WG hefur metið margar tillögur ættu þessar tillögur að vera með til að leyfa BARB tækifæri til að ákvarða hvort fullnægjandi áreiðanleikakönnun hafi verið gerð við val á valinni tillögu.
- Umfjöllun um kröfur: Yfirlit yfir umfjöllun um virkni kröfur sem tillagan gefur með vísan til viðeigandi kerfisþarfa og notkunarmynda sem gefnar eru í tilheyrandi FRD
- Skilgreining á vandamáli: Yfirlýsing um vandamál leyst með tillögunni
- Valviðmið: Yfirlýsing varðandi val / frammistöðuviðmið frá tilheyrandi matsmælingum sem hafa haft leiðbeiningar um valferlið
- Réttlæting á vali: Athugun á matsmælum sem réttlæta valið á milli tillagna og leiða í ljós viðskiptamun
- Lýsing: Lýsing á virkni og framlengdum samskiptareglum. Þessi hluti getur aðlagast mismunandi þörfum með því að bæta við viðeigandi undirhlutum.
3. Prófunarstefna: Lýsing á virkni sem lagt er til að verði prófuð (eða ekki prófuð) sem hluti af Bluetooth hæfnisáætluninni og hvernig virknin er fyrirhuguð að hún verði prófuð (td væntingar til neðri prófunaraðila eða efri prófunaraðila, og ef prófanirnar verða kenndar við samræmis- eða rekstrarsamhæfispróf eða sambland af hvoru tveggja). Þetta getur verið í sérstöku skjali eða sérstökum hluta innan 0.5/DIPD forskriftarinnar. Samningunum sem nota á í prófunaráætlun er lýst í prófunarstefnunni og hugtökum yfirview skjal (TSTO) [5].
Aðaláhorfendur skjalanna á þessari stage eru WG meðlimir og BARB sem review byggingartillögur og kröfur umfang, og BTI hver umviews prófunarstefnan. Í flestum tilfellum eru skjöl þessa stage er ekki ætlað að innihalda texta sem fyrirhugað er að setja í endanlegri forskrift.
BSTS verður að endurskoðaview öll skjöl til að samræmast viðmiðunarreglum Bluetooth [1] og auðkenna vandamál sem WG á að taka á. BARB verður afturview 0.5/DIPD forskriftin. Til að auka forskrift, verður BARB einnig að endurskoðaview DIPD til að uppfylla kröfur um baksamhæfi sem lýst er í kafla 3.3.2. BTI verður að endurskoðaview prófunarstefnunni.
BARB verður annaðhvort að samþykkja eða hafna 0.5/DIPD forskriftinni byggt á verkfræðilegu mati þess. Ef BARB samþykkir, verður 0.5/DIPD forskriftin gerð aðgengileg á Bluetooth SIG websíðu til allra meðlima og verkefnisstjóra og tilkynning um að hún sé tiltæk verður gefin út af BSTS. Á 0.5/DIPD Stage, samþykki prófunarstefnunnar er ekki krafist.
0.5/DIPD Stage er ekki krafist fyrir endurbætur á CSS, GSS eða MDP forskriftum
0.5/DIPD Stage brottfararkröfur
0.5/DIPD Stage er lokið og 0.7/FIPD Stage hefst þegar eftirfarandi útgönguskilyrði eru uppfyllt:
- BSTS hefur lokið við umviewmeð 0.5/DIPD forskriftinni og prófunarstefnunni.
- BARB hefur samþykkt 0.5 / DIPD forskriftina.
- BTI hefur lokið endurview prófunarstefnunnar.
- BSTS hefur gert viðurkennda 0.5 / DIPD forskrift aðgengilega fyrir alla félaga og verkefnisstjóra.
4.2 0.7/FIPD Stage
Á 0.7/FIPD Stage, WG mun þróa eftirfarandi með því að nota opinberu sniðmátið sem er að finna í [8]:
- Fyrir nýja forskrift, drög að 0.7 forskriftinni, sem verða að lágmarki að innihalda upplýsingar um eftirfarandi:
- Lýsing á öllum breytingum sem gerðar voru síðan BARB samþykkti 0.5, þar á meðal nýjar eða breyttar tillögur, valforsendur og rökstuðningur fyrir vali. Breytingum verður að lýsa á sama nákvæmni og krafist er í 0.5 Stage.
- Allar virkni kröfur frá FRD fjallað.
2. Til að auka forskriftina, drög að FIPD, sem verða að lágmarki að innihalda upplýsingar um eftirfarandi:
- Lýsing á öllum breytingum sem gerðar hafa verið síðan BARB samþykkti DIPD, þar á meðal nýjar eða breyttar tillögur, valforsendur og rökstuðningur fyrir vali. Breytingum verður að lýsa á sama nákvæmni og krafist er í DIPD Stage.
- Eftir þörfum, þróað svæði sem lýst var í kafla 4.1 varðandi DIPD.
- Fullbúin lýsing á framförinni.
- Uppfærð byggingarlýsing.
- Allar virkni kröfur frá FRD fjallað.
3. 0.7 / FIPD prófskjöl, sem þurfa að lágmarki að innihalda upplýsingar um eftirfarandi:
- Prófsvíta, sem samanstendur af lista yfir tilgangi eins og lýst er í TSTO [5].
- Yfirlýsing um framkvæmd samræmis (ICS), eins og lýst er í TSTO [5].
Til að bæta tækniforskriftirnar er hægt að fá Test Suite og ICS annað hvort sem sérstök skjöl eða sem viðbótarhluta í FIPD.
Aðaláhorfendur skjalanna sem framleidd voru á þessari stage eru WG meðlimir og BARB sem review heildarlýsingin á eiginleikanum eða endurbótinni, þar á meðal texta sem ætlað er að setja í lokaforskriftina. BTI er áhorfendur fyrir review af prófunarskjölunum.
BSTS mun afturview nýju eða breyttu hluta 0.7/FIPD forskriftarinnar og prófunarskjöl til samræmis við Bluetooth drögunarleiðbeiningarnar, þar á meðal tungumálasamþykktir sem settar eru af Bluetooth SIG. BARB mun afturview 0.7/FIPD forskriftin.
BSTS mun aðstoða WG við að útbúa 0.7 / FIPD prófskjölin í samræmi við TSTO [5].
BTI verður að endurskoðaview 0.7/FIPD prófunarskjölin. WG verður að veita 0.7/FIPD forskriftina til BTI til viðmiðunar þegar endurtekið erview0.7/FIPD prófunarskjölin, sem BTI mun endurskoðaview í samræmi við BTI forskrift Review Gátlisti fyrir ferli [6].
Eftir að BARB hefur lokið endurgerð sinniview 0.7/FIPD forskriftarinnar og BTI hefur lokið við að endurskoðaview af 0.7/FIPD prófunarskjölunum mun BSTS gera endurviewed 0.7/FIPD forskrift í boði fyrir alla meðlimi og kynningaraðila.
0.7/FIPD Stage er ekki krafist fyrir endurbætur á CSS, GSS eða MDP forskriftum.
0.7/FIPD Stage brottfararkröfur
0.7/FIPD Stage er lokið og 0.9/CR Stage hefst þegar eftirfarandi útgönguskilyrði eru uppfyllt:
- BSTS hefur lokið við umview0.7/FIPD forskrift og prófunarskjöl.
- BARB hefur lokið við umviewmeð 0.7/FIPD forskriftinni.
- BTI hefur lokið við umviewing 0.7/FIPD Test Suite (Test Purposes) og 0.7/FIPD ICS.
- BSTS hefur gert endurviewed 0.7/FIPD forskrift í boði fyrir alla meðlimi og kynningaraðila.
4.3 0.9/CR Stage
Það eru tvær gerðir af CR: Innbyggt CR, sem er breytingaskráð skjal með allri samþykktri forskrift sem sýnir allar breytingar frá fyrri útgáfu, og stytt CR, sem er skjal sem veitir leiðbeiningar um að breyta aðeins hlutum viðkomandi forskriftarútgáfan sem CR byggir á.
Á 0.9/CR Stage, WG mun þróa eftirfarandi með því að nota opinberu sniðmátið sem er að finna í [8]:
- Fyrir nýja forskrift, innihaldsdrög að 0.9 forskriftinni, sem verða að lágmarki að innihalda upplýsingar um eftirfarandi:
- Lýsing á öllum breytingum sem gerðar voru frá BARB-reviewed 0.7 forskriftin (eða þar sem 0.5 forskriftin hefði verið fallin frá því að framleiða 0.7 forskriftina), þ.mt ný eða
- breyttar tillögur, valforsendur og rökstuðningur fyrir vali. Breytingum verður að lýsa á sama nákvæmni og krafist er í 0.5 Stage og 0.7 Stage.
2. Til að auka forskrift:
- Annaðhvort samþætt CR, sem verður að lágmarki að innihalda upplýsingar um eftirfarandi:
- Lýsing á öllum breytingum sem gerðar voru frá BARB-reviewed FIPD (eða frá DIPD ef FIPD hefur verið afsalað) þar með talið nýjar eða breyttar tillögur, valviðmið og rökstuðning fyrir vali. Breytingum verður að lýsa á sama nákvæmni og krafist er í DIPD Stage og FIPD Stage.
- Allar breytingar sem lagðar eru til á áður samþykktri forskrift með breytingarsporingi.
- Öll viðurkennd tæknileg errata (þar sem hvert erratum er vísað til með erratum númeri), sýnt með breytingarsporingi, sem enn á eftir að fella inn í áður samþykkta forskriftarútgáfu, og þann áhrifatexta sem er tengdur við tæknibreytinguna; eða sem annars hafa áhrif á IOP próf.
3. Eða skammstafað CR, sem verður að lágmarki að innihalda upplýsingar um eftirfarandi:
- Lýsing á öllum breytingum sem gerðar voru frá BARB-reviewed FIPD (eða frá DIPD ef FIPD hefur verið afsalað) þar með talið nýjar eða breyttar tillögur, valviðmið og rökstuðning fyrir vali. Breytingum verður að lýsa á sama nákvæmni og krafist er í DIPD Stage og FIPD Stage.
- Allar breytingar sem lagðar eru til á hverjum hlutum og málsgrein fyrir áhrifin af forskriftinni sem CR leggur til að verði breytt.
- Allar viðurkenndar tæknilegar villur (með hverju erratum sem vísað er til með erratum númeri), sýndar með merkingu, sem enn á eftir að fella inn í áður samþykkta forskriftarútgáfu, og þann áhrifatexta sem er tengdur við tæknibreytinguna; eða sem annars hafa áhrif á IOP próf.
4. CSS CR (ef kröfur eru gerðar um nýjar færslur í forskriftinni), sem getur verið fellt í styttri CR í forskriftinni.
5. GSS CR (ef nýjar færslur eru krafðar í forskriftinni), sem getur verið fellt í styttri CR í forskriftinni.
6. MDP CR (ef nýjar færslur eru krafðar í forskriftinni), sem getur verið fellt í styttri CR í forskriftinni.
7. 0.9 / CR prófunarskjöl, sem verða að lágmarki að innihalda upplýsingar um eftirfarandi með því að nota opinbera sniðmát sem lýst er í [8]:
- 0.9 / CR Test Suite, sem inniheldur innihaldslaus prófatilfelli og tilheyrandi kortagerðartöflu fyrir prófatilfelli (TCMT), eins og lýst er í TSTO [5].
- 0.9 / CR ICS, eins og lýst er í TSTO [5].
- Ef stillingar prófanna krefjast sérstakra breytna fyrir IUT-framkvæmdina (IUT), eru 0.9 / CR útfærslu eXtra upplýsingar fyrir prófanir (IXIT).
- Tilvísunarlisti 0.9 / CR próftilvika (TCRL) (valfrjálst fyrir uppfærslur á kjarnaforskrift).
8. Prófunarþekjugreining sem gefur til kynna hvaða kröfur um forskrift eru annað hvort prófaðar eða ekki prófaðar innan 0.9 / CR prófunarvígslunnar (til að auka forskrift þarf prófgreiningargreiningin aðeins að fela í sér nýlega bætta og áhrifa virkni, en ekki svæði sem ekki hafa áhrif á upprunalega forskriftin).
9. IOP prófunaráætlun.
Til að bæta tækniforskriftirnar má fá Test Suite, ICS og IXIT annað hvort sem sérstök skjöl eða sem viðbótarhluta í styttri CR.
Í flestum tilvikum ætti samþætt eða skammstafað CR að byggja á útgáfu forskriftarinnar sem áður var samþykkt, en hún gæti einnig verið byggð á nýjustu millidrögunum. Nýjasta millidrög drög útgáfu númer verður að vera útgáfu númer sem tengist útgáfu skjalsins sem er frosið og mun ekki breytast með tímanum. Annars, viðbótar auðkennandi upplýsingar (svo sem skjaladagsetning og a URL til fastrar staðsetningar) verður að leggja fram til að bera kennsl á tiltekna „grunnlínu“ útgáfu. Ef millidrög eru notuð verða að fylgja með allar breytingar sem ekki tengjast CR innan tiltekins hluta sem CR breytir, en ekki er krafist að þær séu sýndar með merkingu. Ef viðkomandi hlutar millidröganna eru seinna uppfærðir verður að uppfæra CR til að endurspegla uppfærslurnar á millidrögunum.
Helst er stytt CR-efni fellt inn í drög að fullri forskrift og fullu prófskjölunum fyrir gildistökuáfangann, en þau geta einnig verið samþætt í upphafi löggildingaráfangans. Ef verið er að þróa marga eiginleika fyrir forskrift (td Core Specification) getur verið æskilegt að samþætta aðgerðirnar í eitt drög eftir að IOP prófun er lokið.
BSTS mun afturview 0.9/CR forskriftina og prófunarskjölin til að samræmast við leiðbeiningum um uppkast Bluetooth. Þá mun BARB afturview 0.9/CR forskriftin og síðar með IOP prófunaráætluninni (eins og lýst er í kafla 4.3.1). Þegar 0.9/CR forskriftin hefur verið lögð fram af WG til BARB til endurskoðunarview, BSTS mun gera það aðgengilegt fyrir alla meðlimi að endurskoðaview og tilkynna öllum meðlimum um framboð þess. Frá þessum tímapunkti í þróunarferli forskrifta mun BSTS gera drög að forskriftinni sem lögð er fyrir BARB aðgengileg öllum félagsmönnum með reglubundnum tilkynningum sem sendar eru til allra félagsmanna.
Til að auka forskrift mun WG mæla með því við BoD hvort fyrri útgáfur af forskriftinni eigi að vera úreltar eða dregnar til baka, þar á meðal tæknilegar ástæður fyrir tilmælunum.
BARB mun afturview Greining WG á samræmi 0.9/CR forskriftarinnar við kröfurnar sem gefnar eru upp í FRD, hugsanlegum öryggisvandamálum, hvers kyns reglugerðarvandamálum, samræmi við Bluetooth arkitektúr og, til að bæta forskriftina, samræmi við kröfur um afturábak eindrægni sem lýst er í kafla 3.3.2 .XNUMX. Ef BARB greinir hugsanleg öryggisvandamál mun BARB tilkynna BSTS um endurtekninguview og samhæfingu við öryggissérfræðingahópinn; og ef BARB greinir einhverjar reglugerðaráhrif mun BARB tilkynna BSTS um að endurskoðaview og samræma við eftirlitsnefndina og lögfræðinga Bluetooth SIG. BARB verður annaðhvort að samþykkja eða hafna 0.9/CR forskriftinni á grundvelli verkfræðilegs mats og tillits til þeirra þátta sem lýst er í þessari málsgrein.
BTI mun afturview 0.9/CR prófunarskjölin að teknu tilliti til prófunargreiningarinnar. BTI verður annað hvort að samþykkja eða hafna 0.9/CR prófunarskjölunum.
Eftir að BARB hefur samþykkt 0.9/CR forskriftina sendir WG IOP prófunaráætlunina til BARB til endurskoðunarview.
BARB-viðurkennd 0.9 / CR forskriftin er kynnt BoD til að samþykkja upphaf IOP prófana og birtingu 0.9 / CR forskriftarinnar fyrir öllum meðlimum.
Til að varpa ljósi á hugsanleg lagaleg atriði geta WG beðið um forskrift umview af lögfræðingi Bluetooth SIG (lögfræðilegt umview) áður en lögboðin lög umview fer fram á ættleiðingar-/samþykktarfasa. Hins vegar, fyrir endurbætur á forskrift, laga umview ætti að vera gert á samþættum CR (öfugt við skammstafað CR) og það ætti að vera fyrirfram tímasett eins langt fram í tímann og hægt er svo úrræði séu tiltæk.
IOP próf áætlun
WG mun þróa skriflega IOP prófunaráætlun sem verður að uppfylla allar þær kröfur sem skilgreindar eru hér að neðan til notkunar á fullgildingarfasa við IOP prófunarviðburði. WGs verða að skila IOP prófunaráætluninni til BARB til endurskoðunarview áður en IOP prófunartilvikin hefjast. Fyrir einfaldar forskriftaaukabætur (sérstaklega þær sem ekki krefjast að breyta eða bæta við neinum prófunartilfellum í prófunarsvítunni), getur verið að IOP prófun sé ekki nauðsynleg og WG getur sent beiðni til BARB um undanþágu frá IOP prófun með því að nota ferlið sem er skilgreint í kafla 4.4.
IOP prófunaráætlunin verður að innihalda:
- Prófaðu mál til að staðfesta alla nýja lögboðna, valkvæða og skilyrta eiginleika
- Að minnsta kosti eitt prófdæmi fyrir hvern op kóða
- Að minnsta kosti eitt prófdæmi fyrir hverja færibreytu
- Að minnsta kosti eitt prófunartilvik fyrir hverja pakkagerð
- Tilvik til baka eindrægni til að auka forskrift svo að kröfur sem taldar eru upp í kafla 3.3.2 séu uppfylltar fyrir alla aukna virkni (sjá einnig kafla 4.3.1.1).
- Prófunartilvik þar sem IUT verður fyrir gildum utan skilgreindra sviða eða fyrir hegðunarþætti sem eru taldir ógildir eða óvæntir (Ógild atferlisprófstilvik). Athugið að gert er ráð fyrir að prófanir eins og PTS eða annað prófunartæki verði upphafsmaður að ógildri hegðun.
- Öll tímabundin úthlutuð númer (valin í samvinnu við BSTS til að koma í veg fyrir skörun á komandi IOP prófatburðum) til að nota við IOP prófatburðinn, eins og lýst er í kafla 4.3.1.2.
- Auðkenning á nauðsynlegum fjölda sjálfstæðra útfærslna sem þurfa að standast hvert próftilvik, með hliðsjón af umfjöllunarkröfum sem lýst er í kafla 4.3.1.3
- Auðkenning á prófatilvikum í Test Suite sem WG telur að eigi að vera undanskilin og réttlæting fyrir útilokun þeirra. Þetta felur venjulega í sér: • Próftilfelli í framtíðarsönnun (td algeng próf svo hægt sé að koma til móts við framtíðarviðbætur, svo sem viðbótareiginleika, útvíkkandi einkenni eða notkun áskilin eða reitir áskilinn til framtíðarnotkunar (RFU))
• Prófunartilfelli sem eru hluti af öðrum prófum sem fylgja með
• Almenn próftilvik sem eru nánast eins og próf sem hlaupa fyrir nokkrar aðrar forskriftir (td kallar á algengar villukóðar)
• Prófunartilfelli með sama prófunartilgang og prófatilfelli sem hlaupa yfir annan flutning (td BR / EDR prófdæmi sem er svipað og LE prófdæmi)
• Robustness eða álagsprófun á framkvæmdinni
IOP prófunaráætlunin getur einnig innihaldið próf sem eru einstök fyrir IOP próf eins og endapróf próf tilfelli sem strengja saman flóknari raðir sem geta líkst dæmigerðri atburðarás.
Þrátt fyrir að BARB samþykki IOP prófunaráætlunarinnar sé ekki krafist (á þeim skilningi að IOP prófunaráætluninni verði áfram breytt og bætt við hverja IOP prófatburð) er BARB samþykki IOP prófunarskýrslunnar krafist (sjá kafla 5.1.1) . Ef IOP prófunaráætlun uppfyllir ekki allar kröfur sem skilgreindar eru í kafla 4.3.1 ætti WG að leggja fram yfirlit yfir þekkt afbrigði og rök fyrir hverri breytileika fyrir BARB áður en IOP próf atburðurinn byrjar.
IOP prófunaráætlunin og prófdæmi ættu fyrst og fremst að byggja á innihaldinu í prófgögnum tengdrar forskriftar.
Til að gera IOP-prófatburði skilvirka ætti WG að hafa IOP-prófunaráætlunina og öllum tilheyrandi prófdæmum lokið og aðgengileg útfærsluaðilum, helst a.m.k. einum mánuði fyrir fyrsta IOP-prófatburðinn.
Skipuleggja afturprófanir á eindrægni
Fyrir endurbætur á forskriftum verður IOP prófun á afturábakssamhæfni að taka tillit til sannprófunar gegn öllum virkum og úreltum útgáfum forskriftarinnar vegna þess að þessar forskriftir og virkni sem almennt er að finna í Bluetooth vörum geta haft mjög langan líftíma (td farartæki). WG verður að greina viðeigandi stig bakviðasamhæfisprófa sem þarf (ef einhver er), þar á meðal hvaða útgáfur á að prófa og prófanirnar sem á að framkvæma, og veita BARB þessa greiningu. BARB verður afturview greininguna og mæla með breytingum (ef einhverjar eru) fyrir WG til að fella inn í IOP prófunaráætlunina.
Félagar sem taka þátt í prófunum á afturvirkni eindrægni eru hvattir til að taka með sér eldri tæki sem hafa verið hæft gagnvart fyrri útgáfu (r). WG verður að tilkynna um bilanir á afturvirkni í IOP prófunarskýrslunni. Aðildarfyrirtæki eru einnig hvött til að gera afturprófanir á eindrægni í eigin rannsóknarstofum utan staðsetningar IOP prófatburðarins og tilkynna WG um vandamál sem tengjast forskriftum.
Tímabundin úthlutuð númer notuð við IOP próf
Ráðfæra verður sig við BSTS og BARB til að samræma tímabundna úthlutun úthlutaðra númera sem notuð verða við IOP prófatburðinn svo að ekki skarist eða komi til árekstra við aðrar forskriftir. Þessi tímabundnu gildi verða að vera með í IOP prófunaráætluninni og verður ekki úthlutað til notkunar með neinum samþykktum forskriftum.
Fyrir IOP próf þar sem lagt er til eitt eða fleiri ný 16 bita UUID gildi eru gildin á bilinu 0x7F00 til 0x7FFF frátekin fyrir IOP próf.
Til IOP-prófunar þar sem verið er að leggja til eitt eða fleiri ný gildi fyrir Fixed Protocol Service Multiplexer (PSM) verða gildi sem byrja frá lok gildandi sviðs frá 0x0000 til 0x007F, eins og tilgreint er í kjarnatilgreiningunni.
Krafa um umfjöllun
WG verður að leggja fram sönnun fyrir BARB um að nauðsynlegur fjöldi (eins og lýst er í köflunum hér á eftir) af óháðum útfærslum hafi staðist hvert prófmál. Sérhver WG beiðni um undantekningar frá tilskildum fjölda sjálfstæðra útfærslna verður að vera tilgreind í prófunaráætlun IOP sem lögð er fyrir BARB.
Útfærslur eru taldar vera óháðar hver annarri svo framarlega sem allir hlutir sem skipta máli fyrir löggildinguna hafa verið þróaðir sjálfstætt, þ.e. af mismunandi teymum (sem koma ekki endilega frá mismunandi fyrirtækjum). BSTS getur aðstoðað við mat á því hvort frumgerðirnar geti talist óháðar hver annarri til að varðveita nafnleynd og trúnað varðandi upplýsingar um framkvæmdina.
Athugið að prófunartæki, þar á meðal PTS, eru ekki talin vera sjálfstæð útfærsla.
Kröfur um IOP umfjöllun um kjarna
A Core Specification lögun skilgreinir venjulega eitt eða fleiri hlutverk þar sem hvert hlutverk er hannað til að hafa samstarf við eitt eða fleiri hlutverk eða hugsanlega með sjálfu sér.
Fyrir hvert par af hlutverkum sem eru hönnuð til að hafa samskipti hvert við annað verður að sýna fram á að minnsta kosti þrjár sjálfstæðar útfærslur á hverju hlutverki til að vinna saman með þremur sjálfstæðum útfærslum á viðbótarhlutverkinu.
Fyrir hvert hlutverk sem getur haft samskipti við annað tæki í sama hlutverki verða að minnsta kosti þrjár sjálfstæðar útfærslur á því hlutverki að sýna fram á að þau geti haft samskipti sín á milli í því hlutverki.
Þjónustuskilyrði IOP umfjöllunarkröfur
Að minnsta kosti þrjár sjálfstæðar þjónustuútfærslur verða að sýna fram á að þær hafi samstarf við að minnsta kosti eina framkvæmd viðskiptavinar, sem getur verið PTS.
Profile og samskiptalýsingu IOP þekjukröfur
Profile og samskiptareglur skilgreina venjulega eitt eða fleiri hlutverk þar sem hvert hlutverk er hannað til að vinna saman við eitt eða fleiri önnur hlutverk, eða hugsanlega við sjálft sig.
Fyrir hvert par af hlutverkum sem eru hönnuð til að hafa samskipti sín á milli þurfa að minnsta kosti tvær sjálfstæðar útfærslur á hverju hlutverki að sýna fram á að þær hafi samvinnu við tvær sjálfstæðar útfærslur á viðbótarhlutverkinu.
Fyrir hvert hlutverk sem getur haft samskipti við annað tæki í sama hlutverki verða að minnsta kosti þrjár sjálfstæðar útfærslur á því hlutverki að sýna fram á að þau hafi samskipti sín á milli í því hlutverki.
Fyrirmyndarlýsing IOP umfjöllunarkröfur
Að minnsta kosti þrjú sjálfstæð netþjónamódel eða stjórnunarlíkanútfærsla verður að sýna fram á að þau hafi samvinnu við að minnsta kosti eina framkvæmd viðskiptavinar (sem kann að vera PTS) og að minnsta kosti ein útfærsla viðskiptavinalíkans verður að sýna fram á að hún hafi samstarf við að minnsta kosti eina útfærslu netþjónalíkans og PTS.
Forskrift útgáfu númer
Á 0.9/CR Stage, WG verður að undirbúa tilmæli um að kynna fyrir BoD varðandi útgáfunúmerið sem á að nota á forskriftina þegar hún er samþykkt.
Útgáfur forskriftanna skiptast í tvær gerðir: útgáfur í fullri útgáfu, sem innihalda nýja eða uppfærða eiginleika, og útgáfur á viðhaldsútgáfu (einnig þekktar sem „dot-Z útgáfur“), sem samþætta tæknileg og ritstjórnarleg villu, en innihalda ekki nýjar eða uppfærðar lögun. Útgáfur í fullri útgáfu eru með tvíþætt númer í formi XY, svo sem 2.1 eða 5.0, en útgáfur af viðhaldsútgáfu eru með þríþætt númer í formi XYZ, svo sem 2.1.2. Gildi Z getur ekki verið 0.
Fyrir allar tvær útgáfur er önnur kölluð „hærri útgáfan“ og hin er „lægri útgáfan“. Þetta er ákvarðað eftirfarandi reglum:
- Ef X íhlutirnir eru ólíkir er sá sem er með hærra X gildi „hærri útgáfan“.
- Ef X íhlutirnir eru eins, en Y íhlutirnir eru mismunandi, er sá með hærra Y gildi „hærri útgáfan“.
- Ef XY íhlutirnir eru eins, en Z íhlutirnir eru mismunandi, er sá sem er með hærra Z gildi „hærri útgáfan“. Tveggja hluta númer XY er í þessum tilgangi meðhöndlað sem þriggja hluta númer XY0.
Til dæmisample, eftirfarandi útgáfunúmer væru í röð frá lægstu útgáfu til hæstu útgáfu: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Fyrir CSS hækkar hver uppfærsla aðeins X hluti útgáfunúmersins.
Forsendur fyrir samþykki BoD
Í lok þróunarstigs forskriftar verður að uppfylla eftirfarandi kröfur áður en 0.9 / CR forskrift er lögð fyrir BoD til samþykktar:
- WG hefur lokið prófumfjöllunargreiningunni.
- BSTS hefur lokið við umviewing 0.9/CR forskriftina og prófunarskjölin.
- BARB hefur samþykkt 0.9 / CR forskriftina.
- BARB hefur samþykkt CSS CR (ef nýjar færslur eru krafðar í forskriftinni) sem geta verið felldar inn í styttri CR í forskriftinni.
- BARB hefur samþykkt GSS CR og MDP CR (ef nýjar færslur eru krafðar í forskriftinni).
- BTI hefur samþykkt 0.9/CR Test Suite, ICS og TCRL, ásamt IXIT (að því gefnu að IXIT sé nauðsynlegt til að framkvæma prófin í Test Suite). TCRL er valfrjálst á þessum stage fyrir uppfærslur á kjarnaforskriftinni.
- WG hefur sent IOP prófunaráætlunina til BARB til endurskoðunarview (ef próf er ekki afsalað sér af BARB).
Skjölin sem kynnt eru fyrir BoD verða að innihalda BARB-viðurkennda 0.9 / CR forskrift og kynningu fyrir BoD sem verður að innihalda:
- Allar þekktar beiðnir um að láta af IOP-prófun eða einhverjar kröfur sem skilgreindar eru í kafla 4.3.1
- Listi yfir flutninga sem forskriftin styður (td BR / EDR, LE. Osfrv.)
- Til að auka forskrift, eru allar undanþágur frá kröfum um samhæfni afturábak (lýst í kafla 3.3.2) sem WG fer fram á
- Til að auka forskrift, eru tilmæli frá WG um útgáfu númerið sem gildir um samþykkta forskrift
- Til að bæta forskriftina, eru tilmæli WG um endalok fyrir fyrri útgáfu (s) af samþykktri forskrift, þar á meðal tæknilegar ástæður fyrir því að fyrningu eða afturköllun fyrri útgáfu af forskriftinni er eða er ekki ráðlagt, og réttlætingin fyrir tilmælin
- Allar óleystar alvarlegar áhyggjur frá BARB eða BTI meðlimum (td ástæður fyrir neinum atkvæðum við samþykki, áhyggjur sem stafa af endurtekninguview af prófunarskjölum, eða áhyggjur af því að 0.9/CR forskriftin sé utan gildissviðs FRD eða skipulagsskrár)
- Undirbúningsstaða Profile Tuning Suite (PTS) eða önnur nauðsynleg verkfæri í tengslum við ættleiðingu sem eru unnin af BSTS
BoD getur valið að samþykkja 0.9 / CR forskrift fyrir IOP próf eins og krafist er í samþykktunum [2], áður en BTI samþykkir 0.9 / CR próf skjölin og áður en WG staðfestir að IOP próf áætlunin uppfylli kröfurnar sem skilgreindar eru í kafla 4.3.1. 0.9. BoD getur einnig skilyrt samþykki sitt fyrir 0.9 / CR forskriftinni fyrir IOP prófanir með samþykki BTI fyrir XNUMX / CR prófskjölunum.
0.9/CR Stage brottfararkröfur
0.9/CR Stage er lokið og staðfestingarfasinn hefst þegar BoD samþykkir upphaf IOP prófunar.
4.4 Frávik frá þróunarferli fyrir forskrift
WG getur beðið um að afsala sér einu eða fleiri af eftirfarandi skrefum:
- 0.5/DIPD Stage
- 0.7/FIPD Stage
- IOP próf innan löggildingar áfanga
Til að biðja um undanþágu verður WG að nota sniðmátið fyrir afsal ferlisins sem Bluetooth SIG [8] býður upp á og leggja fram beiðni um undanþágu til hverrar nefndar (þ.e. BARB eða BTI) sem þarf að endurskoðaview eða samþykkja drög að forskrift eða tengd prófunarskjöl á stage að WG leggur til að fallið verði frá og hver þeirra nefnda verður að samþykkja undanþágubeiðnina.
Afsalbeiðni verður að innihalda eftirfarandi:
- Auðkenni stage(s) sem WG vill falla frá
- Rökstuðningur hvers vegna stage(s) ætti að falla frá
- Auðkenni hverrar nefndar (þ.e. BTI og/eða BARB) sem þarf að endurskoðaview og samþykkja undanþágubeiðnina
Nefndin sem hefur til athugunar afsal getur krafist þess að fulltrúi WG haldi framsögu til að réttlæta SMPD ferli afsal áður en hún tekur ákvörðun um afsal beiðni.
Ef afsal fer fram á að falla frá mörgum skrefum og hluta afsalsins er hafnað og hluti er samþykktur, verður að koma fram í svari nefndarinnar hvaða skref í afsalsbeiðninni voru samþykkt og hverjir voru hafnað. Ef afsalsbeiðni er hafnað verður höfnunartilkynningin að innihalda ástæður fyrir höfnun.
5. Löggildingaráfangi
Í staðfestingarfasanum mun WG framkvæma IOP próf á 0.9/CR forskriftinni með það að markmiði að skila IOP prófunarskýrslu fyrir BARB re.view og samþykki. Alltaf þegar mögulegt er, ætti IOP prófun á forskriftabótum að fara fram á móti samþættu forskriftaruppkastinu. Auk þess hefur þingmaður Review, eins og krafist er í samþykktum [2], hefst á þessum áfanga.
Ef forskriftin (eða aukningin) krefst ekki IOP-prófs, þá er heimilt að víkja fyrir IOP-prófunum innan löggildingaráfangans með því ferli sem lýst er í kafla 4.4.
Á meðan á IOP prófunum stendur (sem getur verið einn eða fleiri atburðir), ætti WG að fylgjast með vandamálum með því að nota Bluetooth SIG vandamálarakningarkerfi og endurtaka til að fella inn uppfærslur á drögum að forskrift, prófunarskjölum og IOP prófunaráætlun. Þegar IOP prófun lýkur, verður WG að ljúka uppfærslum á drögum að forskrift og prófunarskjölum til að takast á við öll vandamál, og undirbúa og skila IOP prófunarskýrslu til BARB til endurskoðunarview og samþykki. Þetta er sýnt á mynd 5.1.
Í löggildingarstiginu eru nokkrar athafnir sem geta hafist. Þessar athafnir geta átt sér stað samhliða og innihalda eftirfarandi:
- BoD-samþykkt 0.9/CR forskrift er gerð aðgengileg öllum meðlimum af BSTS með tilkynningu um upphaf meðlims Review tímabil sem kveðið er á um í lögum.
- Allar nauðsynlegar uppfærslur eru felldar inn í CSS (sem getur verið fellt í styttri CR í forskriftinni).
- Einkennandi eða lýsingarskilgreiningar eru felldar inn í GSS forskriftina sem og PTS fyrir IOP próf.
- Skilgreiningar á möskvaeiginleikum eru felldar inn í MDP forskriftina sem og PTS fyrir IOP próf.
- BSTS gerir IOP vettvangsskráningu og árangursfærslutæki kleift að undirbúa IOP próf.
- IOP próf, ef þörf krefur (sjá kafla 5.1).
- Review Athugasemdir og atriði, þar með talið þau sem lögð eru fram vegna IOP prófunar, eru unnin og breytingar teknar inn í drög að forskrift.
5.1 IOP próf
Meginmarkmið IOP prófunar er að staðfesta forskriftina með því að tdample, athugun á nákvæmni og tvíræðni innan textans, umviewmeðhöndla allar grundvallarhönnunarvillur og aðgerðaleysi og veita staðfestingu gegn áður settum kröfum sem þróaðar voru fyrr í þróunarferli forskrifta. IOP prófun getur leitt til breytinga á uppkasti forskriftarinnar og margar IOP prófunaratburðir gætu verið nauðsynlegar til að ljúka öllum nauðsynlegum prófunum.
Það er mikilvægt að gefa félagsmönnum utan WG tækifæri til að taka þátt í IOP prófunum vegna þess að þeir veita sjálfstæða view forskriftarinnar og getur leitt í ljós tvíræðni í forskriftinni sem gæti ekki verið augljóst fyrir meðlimi WG sem þróuðu drögin. Fyrir hvern IOP prófunarviðburð mun BSTS gera upplýsingar um viðburðinn, nýjustu drög að forskrift, Test Suite og IOP prófunaráætlun aðgengileg og mun láta alla meðlimi helst vita einum mánuði fyrir hvern viðburð. Uppfærð drög að forskrift, Test Suite og IOP prófunaráætlun sem notuð er við IOP prófunarviðburð ætti að vera tiltæk að minnsta kosti einni viku fyrir hvern atburð.
Í IOP prófunum munu parvisar samsetningar vettvanga reyna að framkvæma prófin og þátttakendur í IOP prófunum skrá árangur / mistök í hverju prófi og athugasemdir. Ónafngreind samantekt á þessum niðurstöðum (sem vísar til t.d. „Pallur A“, „Pallur B“ o.s.frv.) Og allar athugasemdir verður safnað meðan á IOP prófatburðunum stendur og gerðir aðilum WG aðgengilegir meðan á OP stendur prófatburður. Ef þörf er á viðbótarupplýsingum til að öðlast betri skilning á athugasemdum eða bilunum sem áttu sér stað við IOP-próf, getur BSTS haft milligöngu um að afla frekari upplýsinga frá sendandi aðila.
Ef mögulegt er, ætti að uppfæra PTS til að styðja við IOP prófun með kerfum í öllum lögum fyrir ofan Host Controller Interface (HCI) og vera til staðar við IOP próf atburði fyrir þessi lög. Önnur prófunartæki geta einnig verið til staðar við IOP prófatburði. Yfirlit yfir niðurstöður prófana með PTS eða öðrum prófunartækjum (ef einhver eru) ætti að fylgja með prófskýrslu IOP.
IOP prófanir verða opnar öllum meðlimum sem vilja veita frumgerð útfærslu, þó getur Bluetooth SIG skilyrt þátttöku með því að samþykkja samninga við Bluetooth SIG (þ.m.t. þátttöku og trúnaðarsamninga). WG ber ábyrgð á úrvinnslu og úrlausn mála sem uppgötvuðust við IOP próf og uppfæra skjölin sem málið varðar; Breytingar sem samþykktar eru af WG verður að fella inn sem uppfærslur á drögum að forskrift og prófskjölum til notkunar við hvert IOP prófatburð.
Áður en löggildingaráfanginn er gerður geta WGs gert forprófanir á IOP við atburði sem eru aðeins opnir fyrir meðlimi WG, en niðurstöður óformlegrar prófunar mega ekki vera með í niðurstöðum IOP-prófsins.
Það getur gerst að öllum skrefum sem leiða til fyrsta IOP prófatburðarins sé fylgt, þ.mt tilkynnt IOP dagsetning og staðsetning með það í huga að hefja IOP prófun, en samþykki BoD hafði ekki verið tryggt áður en prófatburðurinn hófst. Í þessu tilviki getur BoD heimilað að taka niðurstöður prófana sem safnað var áður en BoD samþykkti að hefja IOP próf, að því tilskildu að þær niðurstöður sem safnað var byggðust á sömu forskrift og Test Suite væri samþykkt af BoD.
IOP próf er ekki krafist til að bæta við CSS, GSS eða MDP forskriftir.
IOP prófskýrsla
Eftir að IOP prófun er lokið verður WG að skila IOP prófunarskýrslunni til BARB með það að markmiði að sýna fram á að tilskilinn fjöldi óháðra palla hafi staðist tilskilin próf. BARB verður afturview og samþykkja eða hafna IOP prófunarskýrslunni og mun láta WG vita ef þörf er á frekari IOP prófun áður en atkvæðadrögum forskriftarpakkanum er skilað til BoD. BSTS og WG verða að tryggja að engar meðlimaauðkennisupplýsingar komi fram í IOP prófunarskýrslunni áður en skýrslan er send til BARB.
IOP prófunarskýrslan verður að innihalda:
- Listi yfir alla IOP prófatburði sem áttu sér stað í staðfestingarstiginu, þar á meðal dagsetningar þeirra og staðsetningar.
- Fjöldi aðildarfélaga og sjálfstæðra vettvanga sem tóku þátt í hverjum IOP viðburði, þar á meðal hvort PTS var notað.
- Listi yfir forskriftir, Test Suite og IOP prófunarútgáfur sem notaðar voru við hvern atburð.
- Yfirlit yfir stjórnendur þar sem fram kemur hvort öll próftilvik uppfylltu lágmarksskilyrði.
- Samantekt á öllum frávikum frá kröfum um prófunaráætlun IOP sem skilgreindar eru í kafla 4.3.1 og rökstuðning fyrir hverri breytileika.
- Yfirlit yfir PTS umfjöllun um próftilvik í Test Suite.
- Listi yfir öll próftilvik (þ.m.t. afturprófanir á eindrægni) úr IOP prófunaráætluninni, fjölda prófraða, fjölda bilana í prófunum og hvort lágmarksviðmiðunum hafi verið fullnægt í hverju tilviki, þar á meðal útskýring á því hvers vegna einhverjar kröfur voru ekki hitti.
- Yfirlit yfir málefni, athugasemdir og spurningar við hvern viðburð (þar á meðal þær filed gegn forskriftinni meðan á IOP prófun stendur) og áhrifin á forskriftina og prófunarskjölin.
5.2 Kröfur um útgöngustig löggildingar
Gildingarfasa er lokið og samþykkis- / ættleiðingarstig hefst þegar BARB hefur samþykkt IOP prófskýrsluna (nema BARB hafi látið af prófunum) og öllum eftirfarandi kröfum hefur verið fullnægt:
- BSTS hefur gert samþykkta 0.9/CR forskrift aðgengileg öllum meðlimum fyrir Member Review eins og kveðið er á um í lögum og tilkynnti öllum félagsmönnum um tiltækt þess.
- Öll mál sem greind voru við IOP próf og hafa áhrif á próf hafa verið tekin upp og prófuð.
- WG hefur lokið IOP prófunum (nema BARB hafi hætt við prófunina).
6. Ættleiðingar / samþykkisáfangi
Á ættleiðingar-/samþykktarfasa er gengið frá forskriftinni og tengdum prófunarskjölum, BARB, BQRB og BTI samþykki er móttekið, tilkynning um fyrirhugaðan samþykktardag er gefin út ásamt endanlegri útgáfu af drögum að forskrift sem lögð er fyrir BoD til samþykktar ( Kosningadrög), og endanlegur forskriftarpakki er lagður fyrir BoD. Eftir lágmarkstíma meðlims Review sem krafist er í samþykktum [2]) hefur verið fullnægt, mun stjórnin fjalla um forskriftina til samþykktar á samþykktardegi. Eftir samþykkt er forskriftin birt og hæfiskerfið virkt. Ættleiðingar-/samþykkisáfanginn er sýndur á mynd 6.1.
6.1 Atkvæðagreiðsla
Atkvæðagreiðslan er búin til með því að fella uppfærslur (sem gefnar eru í löggildingaráfanga) í nauðsynleg forskriftargögn og undirbúa lokadrög að nýju forskriftinni. Til að bæta tækniforskriftir mun BSTS búa til samþætta forskrift með því að samþætta einn eða fleiri CR (s) í fyrri samþykktu hærri útgáfu forskriftarinnar (sjá kafla 4.3.2) ef þeim er ekki þegar lokið fyrir löggildingaráfanga.
Ef breytingar eru gerðar á forskriftinni á þessum áfanga og WG, BARB eða BTI ákvarða að einhver breyting krefjist viðbótar IOP prófunar, mun forskriftin fara aftur í IOP prófunarhluta löggildingaráfanga fyrir WG til að framkvæma viðbótarprófin. Í ættleiðingar- / samþykkisáfanganum verða eftirfarandi skjöl fyllt út og gerð aðgengileg BoD fyrir ættleiðingardaginn:
- Atkvæðagreiðslan
- Allar stuðnings forskriftir (þ.e. CSS, GSS, MDP) eins og krafist er fyrir viðkomandi forskrift (eða aukahlut), ef þær voru ekki samþykktar áður
- Til að bæta tækniforskriftir, breytingatengd útgáfa af samþykktri forskriftarútgáfu sem sýnir breytingarnar sem lagðar eru til í atkvæðagreiðslunni
- Lýsing frá WG á kröfum um afturvirkni (eins og lýst er í kafla 3.3.2) sem ekki hefur verið fullnægt og réttlæting fyrir undanþágum
- Lýsing frá WG á kröfum um IOP prófunaráætlun (eins og lýst er í kafla 4.3.1) sem ekki hefur verið uppfyllt og rökstuðningur fyrir frávikum ásamt IOP prófunarskýrslu (sem hægt er að veita með því að gefa upp tengil á afrit á Bluetooth SIG websíða)
- Tilmæli frá WG um afskrift eða afturköllun hvers kyns fyrri útgáfu(s) af samþykktri forskrift ásamt rökstuðningi, sem undirstrikar breytingar frá 0.9/CR Stage ráðlegging um lífslok
- Samantekt, unnin af WG, um breytingar á eiginleikum eða virkni frá 0.9 / CR forskriftinni (ef einhver er)
- Samantekt, unnin af BARB, um áhyggjur af BARB meðlimum um að forskriftin sem framleidd er af WG sé utan gildissviðs samþykktar sem samþykkt er af BoD (ef einhver er)
- Listi yfir óleyst lagaleg álitaefni sem eftir eru úr lagalegum umview (ef einhver er)
- BTI-viðurkennd prófsvíta, ásamt WG-viðurkenndri samantekt um prófumfjöllun forskriftar atkvæðagreiðslunnar. Ef nýlega hefur verið bætt við eða breytt virkni án umfjöllunar um próf er skrifleg rökstuðningur fyrir aðgerðaleysi krafist
- BTI-viðurkennd ICS og IXIT (ef þess er krafist af forskriftinni)
- TCRL samþykkt bæði af BTI og BQRB
- Skýrsla unnin af BSTS ásamt BTI um stöðu verkfærni (td PTS og önnur prófunartæki, Bluetooth Launch Studio) þar á meðal ef prófatilvik í TCRL eru ekki studd af prófunartækjum
- Samantekt, unnin af WG, af öllum nauðsynlegum úthlutuðum númerum
- Tékklisti yfir ættleiðingar sem BSTS og WG hafa útbúið sem sýna að allar afgreiðslur í þessum kafla eru allar lokið
- Allar aðrar upplýsingar sem BoD óskaði eftir
Í ættleiðingar- / samþykkisáfanganum ætti WG að nota útgáfuvöktunarkerfi Bluetooth SIG til að fanga mál og athugasemdir við drög að forskrift og prófskjölum svo að gerð sé grein fyrir þeim við frágang á forskriftinni um atkvæðadrög. Til að auka forskriftina verður að fella öll viðeigandi viðurkennd errata (þ.e. þau viðurkenndu errata sem eru ekki ennþá samþætt) og auðkenna þau með því að fylgjast með breytingum.
WG verður að leggja lokadrög að forskrift til BSTS til lagalegrar meðferðarview. Að því er varðar nýjar forskriftir, laga umview mun innihalda alla forskriftina. Fyrir endurbætur á forskriftum, tilvísun tilview mun einbeita sér fyrst og fremst að breyttum hlutum forskriftarinnar. Tilgangur lagafrvview er fyrst og fremst að greina lagalegar áhættur sem WG ætti að íhuga og leitast við að leysa. Lögfræðileg viðbrögð verða flokkuð eftir alvarleika. Ef valkvæð lagaleg umview var framkvæmt á 0.9/CR Stage, útgáfan sem lögð er fram til laga umview verður að sýna, sem raktar breytingar, allar breytingar sem voru gerðar síðan í þeirri útgáfu (búnar til annað hvort af WG eða BSTS). Að lokinni lögfræðilegri umrview, munu WG og BSTS koma sér saman um endurgjöfina sem á að fella inn í drög að forskrift. Komi fram einhverjar óafgreiddar lagalegar athugasemdir frá lagafrvview á drögum að forskrift getur formaður WG óskað eftir tíma á dagskrá BoD til að koma sér saman um ályktun.
Samhliða lagafrvview, verður WG að leggja drög að forskrift til BARB til endurskoðunarview. Við fyrstu framlagningu til BARB mun BSTS tilkynna öllum félagsmönnum að drög að forskrift hafi verið lögð fyrir BARB til endurskoðunarview og að það sé einnig í boði fyrir Member Review. Ef WG leggur fram uppfærslur á drögum að forskrift fyrir BARB endur-endurview, BSTS mun senda viðbótartilkynningar til allra meðlima með reglulegu millibili.
Að loknu BARB viðaukaview, munu WG og BARB koma sér saman um endurgjöfina sem felld verði inn í drög að forskrift.
Ef laga umview hefur í för með sér hvers kyns efnisbreytingar, viðbótar umview eftir BARB gæti verið krafist. Á sama hátt, ef BARB viðrview hefur í för með sér allar efnislegar breytingar, mun BSTS ákveða hvort frekari lagabreytingarview af þeim breytingum er krafist. Að lokinni lögfræðilegri umrview og BARB review, BARB verður annað hvort að samþykkja eða hafna atkvæðagreiðsludrögunum.
Ef einhver prófskjöl þarfnast uppfærslu mun BSTS aðstoða WG við að uppfæra prófskjölin. BTI verður annað hvort að samþykkja eða hafna prófskjölunum. Ef BTI samþykkir það mun BTI aðstoða við að ganga frá TCRL og afhenda BQRB þetta skjal ásamt tilheyrandi ICS, IXIT og Test Suite. BSTS mun áætla dagsetningu BoD fundarins þegar BoD ætlar að greiða atkvæði um samþykkt atkvæðagreiðslunnar (ættleiðingardagur) og afhenda henni BTI til notkunar í TCRL. BARB samþykki forskriftarinnar, BTI samþykki allra prófunarskjala (þ.mt Test Suite, TCRL, ICS og IXIT) og BQRB samþykki TCRL verður að eiga sér stað fyrir eða fyrir ættleiðingardag.
BSTS mun upplýsa alla meðlimi um frágang og aðgengi að atkvæðadrögum og samþykktardagsetningu. Samþykktardagsetningin verður ekki sett fyrr en 60 dögum eftir að félagsmönnum var tilkynnt um BoD-samþykkta 0.9/CR forskriftina, nema meðlimur Rek.view tímabil er stytt af stjórn í samræmi við samþykktir og að minnsta kosti 14 dögum eftir að tilkynning um samþykktardag er veitt félagsmönnum í samræmi við samþykktir. Fyrir tilvik þar sem mörg CR hafa verið felld inn í atkvæðagreiðsludrög, hefst meðlimur Review er dagsetningin þegar félagsmönnum var tilkynnt um nýjasta CR-samþykkt BoD.
Eftir að félagsmönnum hefur verið tilkynnt um ættleiðingardag er leiðrétting BoD á prentvillum í atkvæðagreiðslunni leyfð. Tímalína upptöku tilgreiningar er sýnd á mynd 6.2.
6.2 Úthlutað númer
Bluetooth SIG heldur úti almennu aðgengilegu setti af úthlutuðum númerum á Bluetooth SIG Assigned Numbers websíða [7]. Þessum úthlutuðu númerum er flokkað í ýmis númerarými (tengt númerasett án afrita). Númer sem úthlutað er geta skarast við önnur úthlutað númer í mismunandi númerarými, en ekki er heimilt að endurnýta númer innan númerarýmis. Hin ýmsu númerabil eru skilgreind í forskriftinni sem skilgreinir notkun úthlutaðra númera.
Eftir að BARB hefur samþykkt IOP prófunarskýrsluna mun WG leggja fram beiðni til BARB um úthlutun nýrra númera innan þess númerarýmis sem krafist er í lokaforskriftinni. BARB mun afturview beiðninni og vinna með BSTS til að ákvarða úthlutað númer. Eftir samþykki BARB mun BSTS skipuleggja útgáfu úthlutaðra númera til að vera aðgengileg almenningi á Bluetooth SIG Assigned Numbers webstaður [7] innan viku frá samþykkt forskriftarinnar.
Þegar birting úthlutaðra númera á Bluetooth SIG úthlutað númerum webstaður eða innan samþykktrar forskriftar á sér stað, er úthlutað númer ætlað að vera óbreytanleg (að breytast hvorki í gildi né merkingu). Ef þau verða ónothæf af einhverjum ástæðum verða þau frátekin gildi og óheimilt er að endurnýta þau.
6.3 Kröfur um ættleiðingu / samþykki áfanga
Samþykkis- / ættleiðingarstigi er lokið þegar BoD hefur samþykkt forskriftina og eftirfarandi aðgerðum eftir ættleiðingu er lokið:
- BSTS hefur gert endanlegt úthlutað númer opinberlega aðgengilegt á Bluetooth SIG websíða.
- BSTS hefur gert samþykkta forskriftina aðgengilega almenningi á Bluetooth SIG websíða
- BSTS hefur gert öll fylgiskjöl (td CSS, GSS, MDP) sem krafist er fyrir viðkomandi forskrift opinberlega aðgengileg á Bluetooth SIG websíða.
- BSTS hefur gert tengd prófunarskjöl aðgengileg öllum meðlimum á Bluetooth SIG websíða.
- Fyrir endurbætur á forskriftum hefur BSTS gert upplýsandi breytingaskráða útgáfu af áður samþykktri forskriftarútgáfu með öllum breytingum sem gerðar eru með nýsamþykktu útgáfunni og gert hana aðgengilega öllum meðlimum á Bluetooth SIG websíða.
- BSTS hefur virkjað hæfiskerfið.
- BSTS hefur tilkynnt öllum meðlimum um framboð á samþykktri forskrift og öllum fylgiskjölum.
Bluetooth SIG ætlar að ljúka þessum aðgerðum eftir ættleiðingu innan viku eftir samþykkt forskriftarinnar.
7. Viðhaldsstig forskriftar
Viðhaldsstig forskriftar hefst eftir að ættleiðingar / samþykkisáfanga er lokið. Ef vandamál finnast (td tvíræðni í orði eða tæknilegar villur) við forskriftina eða tilheyrandi prófskjöl, verður að skjalfesta þau með því að búa til villutillögur með Bluetooth SIG Errata tólinu. Specification erratum tillögur verða unnar, flokkaðar og samþykktar samkvæmt EPD [3]. Test Suite erratum er unnið og flokkað samkvæmt TSTO [5]. Ef einhver árekstur er á milli SMPD og annað hvort EPD eða TSTO hefur SMPD forgang.
Tilgreining erratum má aðeins nota til að leiðrétta tæknilegar eða ritstjórnarlegar villur í endanlegum samþykktum Bluetooth forskriftum. Að bæta við, breyta og fjarlægja virkni er aðeins hægt að gera með því aðferð til að auka skilgreininguna sem skilgreind var fyrr í þessu skjali.
7.1 Flýtimeðferð við erratum
Þegar frávik er samþykkt í kjölfar ferlisins sem skilgreint er í EPD [3] getur WG, BARB eða BSTS mælt með því að það sé talið brýnt og ætti að flýta því. Þegar þetta gerist mun BSTS ásamt WG eða BARB kynna tilmælin fyrir BoD. Stjórnin mun taka ákvörðun um hvort tilmælin verði samþykkt eða hafnað. Ef tilmælin eru samþykkt mun BSTS samstundis fella samþykkta frávikið inn í sniðmátið [8] og vinna með ábyrga WG að því að ganga frá flýtileiðréttingu á villu sem skal leggja fyrir WG til endurbótaview og samþykki.
Yfirview af flýtiferlinu er sýnt á mynd 7.1.
Eftirfarandi skjöl verða að vera fyllt út og vera aðgengileg BoD fyrir ættleiðingardaginn:
- BARB-samþykkt drög að flýttri leiðréttingu á villu.
- Lýsing frá WG á kröfum um afturvirkni (eins og lýst er í kafla 3.3.2) sem ekki hefur verið fullnægt og réttlæting fyrir undanþágum.
- Listi yfir óleyst lagaleg álitaefni sem eftir eru úr lagalegum umview (ef einhver er).
- BTI-viðurkennd prófunarforrit, ICS og IXIT (ef reiknirit krefst þess).
- BTRL- og BQRB-viðurkenndur TCRL (ef reiknirit krefst þess).
- Skýrsla sem BSTS kláraði ásamt BTI varðandi stöðu reiðubúnaðar (td PTS og önnur prófunartæki, Bluetooth Launch Studio) þar á meðal ef einhver prófdæmi í TCRL eru ekki studd af prófunartækjum og skýringu (ef þörf er á erratum ).
- Tékklisti yfir ættleiðingar sem BSTS og WG hafa útfyllt og sýna að afraksturinn í þessum kafla er öllum lokið.
- Allar aðrar upplýsingar sem BoD óskaði eftir.
BSTS mun vinna með ábyrga vinnuhópnum að því að ganga frá drögum að flýtileiðréttingu á villum og búa til útgáfu til að leggja fyrir ábyrga vinnustofu til endurskoðunarview og samþykki.
WG verður að skila flýtileiðréttingunni til BSTS til lagalegrar meðferðarview. Að lokinni lögfræðilegri umrview, munu WG og BSTS koma sér saman um endurgjöfina sem felld verði inn í flýtileiðréttinguna. Komi fram einhverjar óafgreiddar lagalegar athugasemdir frá lagafrvview um flýtileiðréttingu á errata, getur WG-formaður óskað eftir tíma á dagskrá BoD til að leita eftir inntaki BoD um úrlausn.
Samhliða lagafrvview, verður WG að senda flýtileiðréttinguna til BARB til endurskoðunarview. Þegar flýtileiðréttingin hefur verið send til BARB mun BSTS gera hana aðgengilega fyrir alla meðlimi að endurskoðaview og tilkynna öllum meðlimum um framboð þess. Að loknu BARB viðaukaview, munu WG og BARB koma sér saman um að endurgjöfin verði felld inn í flýtileiðréttinguna.
Ef laga umview hefur í för með sér hvers kyns efnisbreytingar, viðbótar umview eftir BARB gæti verið krafist. Á sama hátt, ef BARB viðrview hefur í för með sér allar efnislegar breytingar, mun BSTS ákveða hvort frekari lagabreytingarview af þeim breytingum er krafist. Að lokinni lögfræðilegri umrview og BARB review, BARB verður annað hvort að samþykkja eða hafna flýtileiðréttingunni.
Ef einhver prófskjöl þarfnast uppfærslu mun BSTS aðstoða WG við að uppfæra prófskjölin. Þegar BTI hefur fengið samþykki prófunarskjalanna mun BTI aðstoða við að ganga frá TCRL og afhenda skjalið til BQRB ásamt tilheyrandi ICS, IXIT og Test Suite eftir því sem við á. BSTS mun áætla ættleiðingardag og afhenda BTI til notkunar í TCRL. BARB samþykki flýtimeðferðar leiðréttingar, BTI samþykki allra prófunarskjala (þ.m.t. Test Suite, TCRL, ICS og IXIT eftir því sem við á) og BQRB samþykki TCRL verður að eiga sér stað fyrir eða fyrir ættleiðingardag.
BSTS mun upplýsa alla meðlimi um lokafrágang og aðgengi að flýtimeðferðinni og leiðbeinandi ættleiðingardegi. Ættleiðingardagur verður settur og tilkynntur til allra félagsmanna í samræmi við samþykktirnar [2] og ættleiðingardagurinn skal vera að minnsta kosti 14 dögum eftir að tilkynningin var send félagsmönnum. Eftir að tilkynnt hefur verið félagsmönnum um fyrirhugaðan ættleiðingardag getur BoD samþykkt leiðréttingar á prentvillum í flýtimeðferðinni Errata án þess að veita viðbótartilkynningu um fyrirhugaða ættleiðingardag og bíða í 14 daga sem krafist er.
Bluetooth SIG mun gera samþykktar flýtimeðferðarleiðréttingar aðgengilegar almenningi og ætlar að gera það innan viku eftir samþykkt. Tilkynning um framboð þess verður gefin út af BSTS til allra félagsmanna.
Flýtimeðferðinni er lokið þegar BoD hefur tekið upp flýtimeðferðina og eftirfarandi aðgerðum eftir ættleiðingu er lokið:
- BSTS hefur gert samþykkta flýtileiðréttingu og tengd prófunarskjöl (ef þess er krafist af erratum) aðgengileg almenningi á Bluetooth SIG websíða.
- BSTS hefur virkjað hæfingarkerfið (ef krefjandi erratum).
- BSTS hefur tilkynnt öllum meðlimum um framboð á samþykktri flýtimeðferð.
Að þessum aðgerðum loknum verður Errata leiðréttingin áætluð til að samþætta viðkomandi upplýsingar, annað hvort sem hluti af fyrirhugaðri tæknibóta eða í væntanlegri viðhaldsútgáfu eins og lýst er í kafla 7.2.
7.2 Losunarferli viðhalds (.Z forskriftir)
Á um það bil ársgrundvelli mun BSTS ákvarða hvort til séu viðurkennd villur (nefndar Errata leiðréttingar) sem eru flokkaðar sem tæknilegar / háar eða tæknilegar / gagnrýnar og enn á eftir að fella inn í texta einhverrar virkrar forskriftar (þ.e. samþykkt forskrift sem ekki hefur verið úrelt eða dregin til baka). Sjá viðauka A varðandi skilgreiningar á rangri flokkun. Sértæki eigandi (annað hvort WG leigusamningur til að viðhalda forskriftinni, eða BARB ef engin WG er leigð til að viðhalda forskriftinni) getur einnig beðið um fyrri viðhaldsútgáfu á virkri forskrift þar sem innifalin er öll viðurkennd galla. Við annað hvort ákvörðun BSTS eða beiðni eiganda forskriftarinnar hefst losunarferlið fyrir viðhald.
Yfirview af viðhaldsútgáfuferlinu er sýnt í Villa! Tilvísunarheimild fannst ekki.
Í upphafi losunarferlis viðhalds munu BSTS ásamt forskriftareigandanum, BARB og BTI þróa og leggja fram áætlun fyrir BoD um að fella Errata leiðréttingarnar í birtu útgáfu útgáfunnar. Fyrirhuguð áætlun verður að gefa til kynna hvort Errata leiðréttingar verði felldar inn í viðhaldsútgáfu forskriftarinnar (þ.e. .Z útgáfu) eða tæknibóta sem þegar er í gangi (þ.e. XY útgáfa). Í fyrirhugaðri áætlun ætti að taka tillit til þess hvort einhverjum nýjum lögboðnum eiginleikum hafi verið bætt við á milli útgáfa samþykktra forskrifta, áætlaðs tíma þegar næsta tæknibúnaður er áætlaður til ættleiðingar og annarra þátta.
Þegar samþykki áætlunarinnar frá BoD mun BSTS ásamt forskriftareigandanum halda áfram að fella allar tæknilegar / meðalstórar, tæknilegar / háar og tæknilegar / gagnrýnar villuleiðréttingar í drög að forskrift sem vísað er til sem „viðhaldsútgáfudrög“. Fyrir leiðréttingar eða tæknilegar / lágar errata leiðréttingar, ef Errata leiðréttingin gildir um fleiri en eina útgáfu af forskriftinni, mun BSTS, nema BoD gefur til kynna annað, samþætta þessar villur í aðeins nýjustu útgáfu með hærri forskrift við næstu uppfærslu þessarar útgáfu . Engar breytingar mega vera með í drögum að viðhaldsútgáfu nema að fella Errata leiðréttingar. Í hverju drögum að viðhaldsútgáfu verður að bera kennsl á allar felldar leiðréttingar á Errata með því að nota breytingarsporing til að sýna fyrirhugaðar breytingar á áður samþykktri útgáfu af birtri forskrift.
Tímasetning fyrirhugaðrar innlimunar fyrir hverja Errata leiðréttingu í viðhaldsútkasti mun ráðast af áhrifum Test Suite: allar Errata leiðréttingar sem ekki hafa Test Suite áhrif geta verið felldar strax, en Errata leiðréttingar sem hafa áhrif á Test Suite verða unnið þannig að tímasetningin fellur saman við uppfærslu á TCRL.
BTI og BSTS munu koma á fresti til að taka upp Errata leiðréttingar með Test Suite áhrifum í drög að viðhaldsútgáfu. Þessi frestur er venjulega 3 til 6 mánuðum fyrir áætlaðan samþykkisdagsetningu næstu helstu útgáfu TCRL. Errata leiðréttingar með Test Suite áhrifum sem missa af frestinum til að taka þátt verða afgreiddar sem hluti af næstu árlegu TCRL útgáfu. Þess vegna, nema beðið sé um fyrri útgáfu, er hámarkstími tæknilegra / hárra eða tæknilegra / gagnrýninna villuleiðréttinga til að vera með í forskriftaruppfærslu um það bil 15 til 18 mánuðir.
Forskriftareigandi verður að leggja fram drög að viðhaldsútgáfu sem hann hefur samþykkt sem endanlegt til lagalegrar meðferðarview. Hin lagalega umview mun einbeita sér fyrst og fremst að breyttum hlutum forskriftarinnar. Að lokinni lögfræðilegri umrview, Eigandi forskriftarinnar og BSTS munu koma sér saman um endurgjöfina sem á að fella inn í Drög að viðhaldsútgáfu. Komi fram einhverjar óafgreiddar lagalegar athugasemdir frá lagafrvview um viðhaldsútgáfudrög, getur forskriftareigandinn óskað eftir tíma á dagskrá BoD til að leita að BoD innleggi um úrlausn.
Samhliða lagafrvview, Eigandi forskriftarinnar verður að leggja fram drög að viðhaldsútgáfu til BARB til endurskoðunarview. Þegar drög að viðhaldsútgáfu hafa verið send til BARB mun BSTS gera það aðgengilegt fyrir alla meðlimi að endurskoðaview og tilkynna öllum meðlimum um framboð þess. Að loknu BARB viðaukaview, Eigandi forskriftar og BARB munu koma sér saman um endurgjöfina til að fella inn í drög að forskrift.
Ef laga umview hefur í för með sér hvers kyns efnisbreytingar, viðbótar umview eftir BARB gæti verið krafist. Á sama hátt, ef BARB viðrview hefur í för með sér allar efnislegar breytingar, mun BSTS ákveða hvort frekari lagabreytingarview af þeim breytingum er krafist. Að lokinni lögfræðilegri umrview og BARB review, BARB verður annað hvort að samþykkja eða hafna viðhaldsútgáfudrögum. Ef BARB samþykkir, verður þetta atkvæðadrögin.
Fyrir villuréttingar sem hafa áhrif á prófskjöl og þar sem samsvarandi prófvillur verða afgreiddar tímanlega fyrir komandi TCRL útgáfu, mun BSTS vinna með forskriftareigandanum og BTI að uppfæra prófunargögnin. Að fengnu samþykki BTI á prófunargögnum mun BSTS áætla ættleiðingardagsetningu og afhenda BTI fyrirhugaða ættleiðingardag til notkunar í TCRL. BTI mun afhenda TCRL til BQRB ásamt tilheyrandi ICS, IXIT og Test Suite eftir því sem við á. BARB samþykki forskriftarinnar, BTI samþykki allra prófunarskjala (þ.mt Test Suite, TCRL, ICS og IXIT eftir því sem við á) og BQRB samþykki TCRL verður að eiga sér stað fyrir eða fyrir ættleiðingardag.
BSTS mun tilkynna öllum meðlimum um lokafrágang og aðgengi að atkvæðagreiðslunni og fyrirhugaðan dagsetningu ættleiðingar. Ættleiðingardagur verður settur og tilkynntur til allra félagsmanna í samræmi við samþykktina og ættleiðingardagur skal vera að minnsta kosti 14 dögum eftir að tilkynning var tilkynnt félagsmönnum. Eftir að félagsmönnum hefur verið tilkynnt um fyrirhugaðan ættleiðingardag getur BoD samþykkt leiðréttingar á prentvillum í atkvæðagreiðslunni án þess að láta í té viðbótar tilkynningu um fyrirhugaðan ættleiðingardag og bíða í 14 daga sem krafist er.
Eftirfarandi skjöl verða að vera fyllt út og vera aðgengileg BoD fyrir ættleiðingardaginn:
- Atkvæðagreiðslan
- Breyting á útgáfu atkvæðagreiðslunnar sem sýnir allar breytingar á samþykktri útgáfu forskriftarinnar sem hafa sama XY gildi (td ef kosningadrögin eru lögð til sem útgáfa 1.4.2, verða breytingarnar raktar miðað við 1.4.1 útgáfa af forskriftinni)
- Tilmæli frá forskriftareiganda um úreldingu eða afturköllun fyrri útgáfu (s) af samþykktri forskrift ásamt rökstuðningi
- Listi yfir óleyst lagaleg álitaefni sem eftir eru úr lagalegum umview (ef einhver er)
- BTI-viðurkennd prófunarforrit, ICS og IXIT (ef viðhaldsútgáfan krefst þess)
- BTI- og BQRB-viðurkenndur TCRL (ef viðhaldsútgáfu krefst þess)
- Skýrsla sem BSTS kláraði ásamt BTI varðandi stöðu verkfærni (td PTS og önnur prófunartæki, Bluetooth Launch Studio), þar með talin öll próftilvik í TCRL sem ekki eru studd af prófunartækjum og skýringar (ef viðhaldið krefst þess) sleppa)
- Tékklisti yfir ættleiðingar sem BSTS og tilgreiningareigandinn fylltu út og sýnir að afhendingarnar í þessum kafla eru allar lokið
- Allar aðrar upplýsingar sem BoD óskaði eftir
Losunarferli viðhalds er lokið þegar BoD hefur samþykkt atkvæðagreiðsluna og eftirfarandi aðgerðum eftir ættleiðingu er lokið:
- BSTS hefur gert samþykkta forskrift og tengd prófunarskjöl (ef þess er krafist í viðhaldsútgáfunni) aðgengileg almenningi á Bluetooth SIG websíða.
- BSTS hefur gert upplýsandi breytingaskráða útgáfu af áður samþykktri forskriftarútgáfu með öllum breytingum sem eru teknar inn í nýsamþykktu útgáfunni aðgengilegar öllum meðlimum á Bluetooth SIG websíða.
- BSTS hefur virkjað hæfiskerfið.
- BSTS hefur tilkynnt öllum meðlimum um framboð á samþykktri forskrift og fylgigögnum.
Bluetooth SIG ætlar að ljúka þessum aðgerðum eftir ættleiðingu innan viku eftir samþykkt forskriftarinnar.
Að lokinni þessari starfsemi er forskriftin áfram í viðhaldsfasa forskriftar þar til forskriftin er úrelt eða dregin til baka, eins og hún er skilgreind í kafla 8.
8. Lýsing á lokaáfanga
Tæknilýsingar geta verið úreltar eða dregnar til baka þegar þær koma í stað nýrra útgáfa, ákvarðaðar tæknilega ófullnægjandi eða af öðrum ástæðum. Úrelt og afturkölluð forskrift er geymd og ekki lengur uppfærð. Úrelt og afturkölluð forskrift er meðhöndluð á annan hátt í Bluetooth-hæfnisáætluninni.
Sérhver meðlimur, hópur eða nefnd getur sent tillögur um að úrelda eða afturkalla forskrift ásamt tilheyrandi tímalínu við BSTS (með tölvupósti til
specification.manager@bluetooth.com) hvenær sem er. BSTS getur einnig mælt með afskrift eða afturköllun á forskrift og tengdri tímalínu. BSTS mun vísa tilmælunum til BARB og hópsins eða nefndarinnar sem ber ábyrgð á að viðhalda forskriftinni fyrir umview og endurgjöf.
BARB og hlutaðeigandi hópur eða nefnd meta tillögur um að úrelda eða afturkalla forskrift og íhuga eftirfarandi (ótæmandi) viðmið:
- Er virkni í fyrri útgáfu forskriftarinnar sem er úrelt eða ætti ekki að nota?
- Er ný lögboðinni virkni bætt við síðari útgáfur?
- Eru annmarkar á fyrri útgáfum sem skerða rekstur eða samvirkni sem hafa verið leiðréttir í síðari útgáfum og þarf til að koma fram núverandi notendaviðburði?
- Er þörf á aukinni virkni í síðari útgáfum til að koma á framfæri nýjum sviðsmyndum notenda?
- Er bætt notagildi og samvirkni í síðari útgáfum?
- Eru öryggisbætur í síðari útgáfum?
BARB og hlutaðeigandi hópur eða nefnd geta lagt til aðrar tillögur.
Eftir að hafa fengið endurgjöf frá BARB eða hópnum eða nefndinni sem ber ábyrgð á að viðhalda forskriftinni mun BSTS leggja tillögurnar og endurgjöfina fyrir BoD til umfjöllunar. Stjórnin getur boðið hópnum eða nefndinni sem ber ábyrgð á að viðhalda viðkomandi forskriftum að hittast og ræða tillögurnar. Stjórnin mun íhuga tillögur og endurgjöf og getur samþykkt eða breytt tillögunni. BoD mun fara fram á að BSTS tilkynni öllum meðlimum um tillögurnar um að afnema eða afturkalla forskrift(ir) og tengda tímalínu(r) í 30 daga aftur.view tímabil til að leyfa öllum meðlimum að veita frekari endurgjöf áður en endanleg ákvörðun er tekin.
BoD mun íhuga viðbrögðin sem berast frá meðlimum. Þegar BoD samþykkir úreldingu eða afturköllun forskriftar mun BSTS tilkynna öllum meðlimum um ákvörðunina og tengda tímalínu.
8.1 Úrgangur
Þegar forskrift er úrelt mun eftirfarandi eiga sér stað:
- Forskriftin verður ekki lengur uppfærð.
- Ábyrg WG mun endurview öll útistandandi errata skrifuð á móti úreltri forskrift til að ákvarða hvort þau eigi við um aðrar forskriftir. Errata getur verið hafnað í errata kerfinu og endurskrifað í samræmi við viðeigandi forskrift(ir).
- WG eða BSTS mun búa til villur til að uppfæra nauðsynlegar tilvísanir í úreltar upplýsingar í öðrum forskriftum.
- BTI mun uppfæra viðeigandi prófunargögn til að gefa til kynna úreldingu forskriftarinnar.
- BSTS mun uppfæra Bluetooth SIG websíða með leiðbeiningum varðandi aðrar forskriftir til notkunar.
- Ekki er lengur hægt að leggja fram nýjar villur gegn úreltri forskrift.
- Ekki er vísað í forskriftina í neinum framtíðarupplýsingum.
- BSTS mun geyma útgáfu af forskriftinni sem merkt er sem úrelt fyrir félagsmenn til að fá aðgang að sögulegum tilgangi.
8.2 Afturköllun
Þegar forskrift er afturkölluð, auk skrefanna sem gilda um fyrningu, mun eftirfarandi eiga sér stað:
- BTI mun uppfæra viðeigandi prófunargögn til að gefa til kynna afturköllun forskriftarinnar.
- BSTS mun uppfæra Bluetooth SIG websíða með leiðbeiningum varðandi aðrar forskriftir til notkunar.
- BSTS mun geyma útgáfu af forskriftinni sem merkt er sem afturkölluð til að fá félagsmenn aðgang að sögulegum tilgangi.
BoD getur valið að afturkalla forskrift strax án þess að fyrna forskriftina.
9. Hvítbókarferli
Hvítar greinar eru eingöngu búnar til í upplýsingaskyni. Eftirfarandi hvítbókarferli á við um öll Bluetooth WG, EG, SG og nefndir. Þessi hluti á ekki við upplýsingaskjöl til notkunar eingöngu innan Bluetooth SIG.
Þetta ferli er sýnt á mynd 9.1 hér að neðan.
Áður en hópur eða nefnd hefst við gerð hvítbókar sem þeir hyggjast birta af Bluetooth SIG mun hópurinn eða nefndin undirbúa bæði fyrirhugaða skipulagsuppfærslu þar sem skýrt er skilgreint fyrirhugað innihald hvítbókarinnar og kynning á tillögu að hvítbók.
Kynning á hvítbókartillögunni verður að innihalda að lágmarki:
- Þörfin fyrir hvíta pappírinn
- Yfirlit yfir fyrirhugað innihald hvítbókarinnar
- Skýring á því hvers vegna ekki er mælt með því að innihaldið sé með sem hluti af forskrift
- Tilætlaður áhorfandi
- Allar viðhaldsáætlanir (þ.e. áætlaður tími fyrir næstu útgáfu þessarar hvítbókar gæti verið nauðsynlegur)
- Ráðleggingar um hvernig meðhöndla eigi fyrri útgáfur af hvítbókinni, ef einhverjar eru (t.d. skjalavörsla)
Uppfærslu skipulagsskrár og kynningu á hvítbókartillögu þarf að skila fyrir BARB umview. Við umrview og samþykki BARB uppfærslu skipulagsskrárinnar, mun BSTS leggja skipulagsskrána uppfærsluna fyrir BoD til samþykkis ásamt framsetningu hvítbókartillögunnar.
Ef BoD samþykkir skipulagsuppfærsluna getur hópurinn eða nefndin haldið áfram að þróa hvítbókina.
Þegar hópurinn eða nefndin hefur lokið þróun hvítbókarinnar mun BSTS framkvæma ritstjórn umview til samræmis við leiðbeiningar um teikningu Bluetooth.
Eftir úrlausn BSTS athugasemda verður hópurinn að skila hvítbókinni til BSTS til lagalegrar meðferðarview. Að lokinni lögfræðilegri umrview, munu hópurinn og BSTS koma sér saman um að endurgjöfin verði felld inn í hvítbókina. Komi fram einhverjar óafgreiddar lagalegar athugasemdir frá lagafrvview um hvítbókina getur formaður hópsins óskað eftir tíma á dagskrá BoD til að leita eftir innleggi BoD um úrlausn.
Samhliða lagafrvview, þarf hópurinn að skila hvítbókinni til BARB til endurskoðunarview. Sem hluti af tilhögun þeirraview, getur BARB mælt með því hvort einhver hluti hvítbókarinnar skuli fjarlægður úr hvítbókinni og felldur inn í forskrift eftir ferlinu í kafla 3. BARB getur einnig ákveðið að leggja hvítbókina fyrir aðra hópa eða nefndir til endurskoðunar.view. Að loknu BARB viðaukaview, munu hópurinn og BARB koma sér saman um að endurgjöfin verði felld inn í hvítbókina.
Ef laga umview hefur í för með sér hvers kyns efnisbreytingar, viðbótar umview eftir BARB gæti verið krafist. Á sama hátt, ef BARB viðrview hefur í för með sér allar efnislegar breytingar, mun BSTS ákveða hvort frekari lagabreytingarview af þeim breytingum er krafist. Að lokinni lögfræðilegri umrview og BARB review, BARB verður annað hvort að samþykkja eða hafna hvítbók.
Eftir að BARB hefur samþykkt hvítbókina verður hvítbókin sem samþykkt er af BARB kynnt af höfundarhópnum eða nefndinni fyrir BoD til samþykktar.
Hvítbókarferlinu er lokið þegar BoD hefur samþykkt hvítbókina og eftirfarandi aðgerðum eftir samþykki er lokið:
- BSTS hefur gert samþykkta hvítbókina aðgengilega almenningi á Bluetooth SIG websíða.
- BSTS tilkynnir öllum meðlimum samþykktrar hvítbókar.
- Ef hvítbókin er aukning á núverandi hvítbók mun BSTS safna útgáfu af hvítbókinni í geymslu fyrir félagsmenn til að fá aðgang að þeim í sögulegum tilgangi.
Bluetooth SIG ætlar að ljúka aðgerðum eftir samþykki innan viku eftir samþykki hvítbókarinnar.
10. Heimildir
Bluetooth skjöl sem vísað er til eru fáanleg frá Bluetooth websíða http://www.bluetooth.com.
- Leiðbeiningar um drög að Bluetooth (fáanlegar á síðunni Sniðmát og skjöl vinnuhópsins, á https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
- Samþykkt Bluetooth SIG, Inc. (fáanleg á síðu stjórnunarskjala, á https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
- Bluetooth Specification Errata Process skjal (fáanlegt á síðunni Sniðmát og skjöl vinnuhópsins, á https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
- Vinnuhópur vinnsluhóps (fáanlegur á síðunni Sniðmát og skjöl vinnuhópsins, á https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
- Prófastefnu og hugtök lokiðview skjal (fáanlegt á síðunni Kröfur um hæfispróf, á https://www.bluetooth.com/specifications/qualification-test-requirements)
- BTI forskrift Review Gátlisti fyrir ferli (fáanlegt á síðunni Sniðmát og skjöl vinnuhóps, á https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
- Bluetooth SIG úthlutað númer (https://www.bluetooth.com/specifications/assigned-numbers)
- Sniðmát og skjöl vinnuhóps (fáanleg á síðunni Sniðmát og skjöl vinnuhóps, á https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
- GATT Specification Supplement (GSS) (fáanlegt á GATT Specification síðu, á https://www.bluetooth.com/specifications/gatt)
- Sendu inn hugmynd að nýrri forskrift https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification
11. skammstafanir og skammstafanir
Tafla A: skammstöfun og skammstafanir
Viðauki A - Erratum alvarleikaflokkun
Þessi viðauki tekur saman leiðbeiningar um flokkun alvarleika fyrir tilgreiningu erratum. Þessari töflu verður bætt við framtíðarendurskoðun á EPD og þá verður þessum hluta eytt.
Lestu meira um þessa handbók og halaðu niður PDF:
Sérstakur skjal fyrir stjórnunarferli (SMPD) - Bjartsýni PDF
Sérstakur skjal fyrir stjórnunarferli (SMPD) - Upprunaleg PDF
Spurningar um handbókina þína? Skrifaðu í athugasemdir!