Spetsifikatsioonide haldamise protsessi dokument (SMPD)

Bluetooth®-i protsessidokument

• Redaktsioon: V27
• Läbivaatamise kuupäev: 2019-05-17
•  Tagasiside e-post: BARB-feedback@bluetooth.org

Abstraktne:
Selles dokumendis määratletakse arendusprotsessid Bluetoothi ​​spetsifikatsioonide ja valgete dokumentide loomiseks ja täiustamiseks.

Läbivaatamise ajalugu

Kaasautorid uusimale versioonile

See dokument, olenemata selle pealkirjast või sisust, ei ole Bluetoothi ​​spetsifikatsioon, mille suhtes kehtivad Bluetooth SIG Inc. (“Bluetooth SIG”) ja selle liikmete poolt Bluetoothi ​​patendi / autoriõiguse litsentsilepingu ja Bluetoothi ​​kaubamärgi litsentsilepingu alusel antud litsentsid.

KÄESOLEV DOKUMENT ON ESITATUD "OLEMAS" JA BLUETOOTH SIG, SELLE LIIKMED JA NENDE LIIDUD EI ESITA MITTE ESINDUSI VÕI GARANTII JA KEELDAMATA KÕIKI GARANTIID, SELGITATUD VÕI KAUDSED, SEALHULGAS KAUBADE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTE, KAUBANDUSTEGA ET SELLE DOKUMENDI SISU ON VIGA.

SAMMUGA, KES EI OLE KEELATUD, BLUETOOTH SIG, SELLE LIIKMED JA NENDE LIIDUD VÄLJASTAVAD KÕIK VASTUTUSED, MIS TULENEVAD SELLE DOKUMENDI NING SELLE DOKUMENDIS sisalduva teabe, sh tulude, tulude ja muude tulude kohta Katkestusi või spetsiaalseid, kaudseid, tagajärgi, juhuslikke või kahjulikke kahjusid, mis on siiski põhjustatud vastutustundlikkuse teooriast ja arvestamata sellega, isegi kui sinine märk on tema soovitatud.

See dokument kuulub Bluetooth SIGile. See dokument võib sisaldada või hõlmata teemat, mis on Bluetooth SIG-i ja selle liikmete intellektuaalne omand. Selle dokumendi esitamine ei anna Bluetooth SIG-i ega selle liikmete intellektuaalomandile litsentsi.

Seda dokumenti võidakse ette teatamata muuta.

Autoriõigus © 2004–2019, autor: Bluetooth SIG, Inc. Bluetoothi ​​sõnamärk ja logod kuuluvad ettevõttele Bluetooth SIG, Inc. Muud kolmandate isikute kaubamärgid ja nimed kuuluvad nende omanikele.

 

1. Sissejuhatus

Spetsifikatsioonihaldusprotsessi dokument (SMPD) kirjeldab protsesse, mida spetsifikatsioonid koostavad ja uuesti koostavadviewEttevõtjad peavad järgima uute spetsifikatsioonide väljatöötamist ja olemasolevate spetsifikatsioonide täiustamist (st funktsionaalsuse lisamist või eemaldamist või konkreetse funktsionaalsuse muutmist vastuvõetud spetsifikatsioonis), vastuvõetud spetsifikatsioonide säilitamist ja vastuvõetud spetsifikatsioonide kasutusaja lõppu. Lisaks kirjeldab käesolev dokument loomisprotsessiviewja valgete raamatute heakskiitmine.

Uute spetsifikatsioonide väljatöötamise ja olemasolevate spetsifikatsioonide täiustamise vahel on spetsifikatsioonide väljatöötamise protsessis erinevusi nende ülesannete ulatuse olemuslike erinevuste tõttu; neid erinevusi rõhutatakse käesolevas dokumendis.

Spetsifikatsiooni väljatöötamise protsess sisaldab:

• Nõuete faas (kirjeldatud 3. jaos) funktsionaalsete nõuete määratlemiseks
• Arendusetapp (kirjeldatud punktis 4) arendamiseks ja uuesti kasutamiseksview spetsifikatsioonid
• Valideerimisfaas (kirjeldatud 5. jaos) spetsifikatsioonide kinnitamiseks koostalitlusvõimelise prototüübi (IOP) testimise abil
• Vastuvõtmise / kinnitamise etapp (kirjeldatud punktis 6), et esitada spetsifikatsioonid Bluetooth SIG-i juhatusele (BoD) vastuvõtmiseks / kinnitamiseks

Dokument Specification Errata Process (EPD) [3] kirjeldab ettepanekute tegemise ja uuesti esitamise protsessiviewspetsifikatsioonivigu ja kinnitades need vigade parandustena (nagu on määratletud põhikirjas [2]) vastuvõetud spetsifikatsioonidele. Kui ei ole märgitud teisiti, siis kõik viited vigadele selles SMPD -s tähendavad spetsifikatsiooni viga.

1.1 Ülimuslikkus

Bluetooth SIG, Inc. põhimäärus (põhimäärus) ja liikmelisuse lepingud [2] on ülimuslikud nende dokumentide ja SMPD vastuolulise sisu suhtes. Hoolimata sellest, mida käesolevas dokumendis on, jääb juhatusele lõplik kaalutlusõigus ja volitused meetmete võtmiseks ja otsuste tegemiseks isegi siis, kui need toimingud ja otsused ei järgi ega ole vastuolus millegi selles dokumendis sisalduvaga ning miski selles dokumendis ei piira ega piira juhatuse sõltumatut võimu ja kaalutlusõigus.

Kui SMPD-s oleva teksti ja jooniste vahel esineb vastuolusid, on tekst ülimuslik.

1.2 Viidatud rühmad ja komiteed

Selles dokumendis on viidatud järgmist tüüpi rühmadele: uurimisrühmad (SG), ekspertrühmad (EG) ja töörühmad (WG). Töörühmal võib olla ka alarühm, mis annab aru töörühmale. Sarnaselt on käesolevas dokumendis viidatud järgmist tüüpi komiteedele: Bluetooth Architectural Review Board (BARB), Bluetoothi ​​test ja koostalitlusvõime (BTI) ning Bluetoothi ​​kvalifikatsioon Review Juhatus (BQRB). See dokument viitab ka Bluetooth SIG tehnilisele personalile (BSTS) ja BoD -le.

1.3 Komitee reviews ja kinnitused

Komitee review on review mida viivad läbi komisjoni liikmed (tavaliselt 3 liiget), et anda tagasisidet kindlaksmääratud aja jooksul (tavaliselt 2-3 nädalat), kuidview aeg võib varieeruda sõltuvalt materjali pikkusest ja keerukusest ning muudest komitee prioriteetidest. Rühm, kes taotleb review ja revisjoni läbiviiv komisjonview igaüks lepib kokku re kestuseview. Rühma ja komitee liikmed kasutavad Bluetooth SIG -i tööriistu, et teatada ja salvestada korduse algus ja lõppview. Üldjuhul töötleb rühm komitee tagasisidet, kui see on laekunud. Kui komisjon review kui aeg saabub, lõpetab rühm komitee tagasiside käsitlemise ja peaks arvestama ka hilinemisegaview tagasisidet, pidades silmas, et materjal võidakse hiljem komisjonis heaks kiita.

Komisjoni heakskiit saadakse komisjoni liikmete hääletusel vastavalt töörühma protsessi dokumendile [4].

1.4 Teatised liikmetele ja materjalide kättesaadavus

Kõiki selle dokumendi kohaselt liikmetele edastatud teateid võidakse edastada e-posti teel, näiteks perioodilise tehnilise värskenduse kujul. Kõigile liikmetele edastatavad teated saadetakse kõigile aktiivsetele liikmetele (st kui liikmelisust ei ole peatatud, lõpetatud ega tühistatud). Kui teated saadetakse e-posti teel, saadetakse need iga isiku, kes on registreerunud liikmesettevõtte liikmeskontol, ja kes pole e-posti teel teatiste saamisest loobunud, viimati teadaolevale e-posti aadressile (mis kajastub Bluetooth SIG-i praegustes dokumentides). Miski käesolevas dokumendis ei muuda Bluetooth SIGi kohustusi ega nõudeid teatamise kohta põhikirja või muu Bluetooth SIGi ja mõne liikme vahel sõlmitud lepingu alusel.

Kui see dokument viitab a websaidile, mis on kõigile liikmetele juurdepääsetav, viitab see juurdepääsetavusele isikutele, kellel on aktiivne Bluetooth SIG -konto. Liikmed, kellel pole aktiivset kontot, võivad luua konto Bluetooth SIG -i kaudu websaidile.

1.5 Mallid

Iga SMPD -s osutatud dokumenditüübi (nt spetsifikatsioonid, valged raamatud, testdokumendid) jaoks pakub Bluetooth SIG malli. Malli tuleb kasutada iga käesoleva SMPD kohaselt koostatud dokumendi aluseks. Kui õiget malli ei kasutata, võib dokument jääda kinnitamata. Mallid on saadaval Bluetooth SIG -is websait [8].

1.6 Spetsifikatsioonide tüübid

Bluetooth SIG -i spetsifikatsioone on mitut tüüpi. Hierarhiliselt sõltuvad kõik spetsifikatsioonid Bluetoothi ​​põhispetsifikatsioonist. Spetsifikatsioonid nagu traditsiooniline profiles; traditsioonilised protokollid; ja GATT-põhine professionaalfiles, GATT-põhised teenused ja GATT-põhised protokollid sõltuvad põhispetsifikatsiooni funktsioonidest. Muud spetsifikatsioonid, näiteks võrgusilma mudeli spetsifikatsioonid, sõltuvad Mesh Pro -stfile spetsifikatsioon, mis omakorda sõltub põhispetsifikatsioonist.

Põhispetsifikatsiooni täienduse (CSS) spetsifikatsioon määratleb andmetüübid, andmevormingud ja tavalised profidfile ja teenuse veakoodid, mida kasutatakse põhispetsifikatsioonis ja muudes spetsifikatsioonides ega määratle ise käitumist.

GATT spetsifikatsioonilisandi (GSS) spetsifikatsioon määratleb iseloomulikud ja kirjeldavad vormingud, mida Pro kasutabfiles ja Teenused ning ei määratle ise ühtegi käitumist.
Mesh Device Properties (MDP) spetsifikatsioon määratleb Mesh Pro kasutatavad võrgusilma omadusedfile ja võrgusilma mudeli spetsifikatsioonid ega määratle ise käitumist.

 

2. Üleview

See jaotis pakub üleview protsessidest ja see ei ole mõeldud hõlmama kõiki üksikasju.

Joonisel 2.1 on toodud kuus peamist etappi, mis moodustavad spetsifikatsioonide haldamise protsessi.

Esimesed neli faasi toimuvad spetsifikatsioonide väljatöötamise käigus ja need koosnevad nõuete etapist (3. jagu), arendusetapist (4. jagu), valideerimisfaasist (5. jagu) ja vastuvõtmise / kinnitamise faasist (6. jagu). Sellele järgneb kaks vastuvõtmisjärgset etappi: spetsifikatsiooni hoolduse etapp (jaotis 7) ja spetsifikatsiooni kasutusea lõpp (jaotis 8).

Joonis 2.2 illustreerib spetsifikatsioonide väljatöötamise nelja etapi üksikasju. Hallid kastid tähistavad iga etapi peamisi tulemusi. Oranžid kastid võtavad kokku protsessi verstapostid.

Nõuete faasis (kirjeldatud 3. osas) algatab uue töö alustamise ettepanek (uus tööettepanek (NWP)) spetsifikatsioonide väljatöötamise protsessi, määratledes uue stsenaariumi korral lubatavad kasutaja stsenaariumid. Kui NWP on heaks kiidetud, loob määratud rühm funktsionaalsete nõuete dokumendi (FRD). Kui FRD on kinnitatud ja rühmale määratud, algab arendusetapp.

Arendusfaasis (kirjeldatud jaotises 4) toimub spetsifikatsioonide arendamine läbi s-ide jadatages (0.5/DIPD kuni 0.9/CR), mis kulmineerub spetsifikatsiooni täieliku mustandiga. 0.9/CR spetsifikatsioon tehakse kättesaadavaks kõigile liikmetele ja esitatakse seejärel BoD-le, kes kaalub spetsifikatsiooni heakskiitmist. Pärast heakskiitmist algab valideerimisfaas.

Spetsifikatsiooni väljatöötamise valideerimisetapis (kirjeldatud jaotises 5) tehakse BoD heakskiidetud 0.9/CR spetsifikatsioon kõigile liikmetele kättesaadavaksview ja kinnitada ning liige Review on alustatud. Valideerimine toimub liikmete koostatud prototüüpide vahelise koostalitlusvõime (IOP) testimise teel. Kui IOP -testimine on lõpule viidud (kui see on spetsifikatsiooni jaoks vajalik) ja BARB kinnitab IOP -testi aruande, algab vastuvõtmise/kinnitamise etapp.

Vastuvõtmise / kinnitamise etapis (kirjeldatud 6. jaos) viimistletakse spetsifikatsioon ja sellega seotud katsedokumendid; BARB, BQRB ja STI kinnitused saadakse; ja lõplik spetsifikatsioonipakett esitatakse juhatusele, kes kaalub spetsifikatsiooni vastuvõtmist (st lõplikku kinnitamist).

Spetsifikatsioonis võib olla vaja naasta eelmisesse faasi või stage kui tehakse olulisi muudatusi. Mõnel juhul võib olla võimalik ka osast faasist loobuda, nagu on kirjeldatud jaotises 4.4.

Spetsifikatsiooni hoolduse etapp (kirjeldatud 7. jaos) algab pärast spetsifikatsiooni vastuvõtmist juhatuses. Selles etapis teatatakse ja hinnatakse vastuvõetud spetsifikatsioonides leitud potentsiaalsetest vigadest ning (kui vaja) tehakse spetsifikatsioonis vigu parandusi. Spetsifikatsiooni hoolduse etapp jätkub seni, kuni spetsifikatsioon on aegunud või tühistatud (vt järgmises lõigus spetsifikatsiooni kasutusea lõppu).

Spetsifikatsiooni kasutusea lõpp (kirjeldatud 8. jaos) kirjeldab vastuvõetud spetsifikatsioonide tühistamise ja tühistamise protsessi.

 

3. Nõuete faas

Nõuete faas algab kas NWP-st (mis ütleb soovi alustada tööd ühe või mitme kasutaja stsenaariumi korral) või pärast seda, kui on kindlaks tehtud, et soovitud uus töö on juba nende töörühma hartaga kaetud. Kui töörühm soovib alustada uut tööd, mis tema arvates kuulub juba tema töörühma reguleerimisalasse, peab töörühm järgima punktis 3.1 määratletud protsessi, et jätkata otseselt FRD väljatöötamist. Kõigi muude tööüksuste puhul peab töörühm järgima jaotises 3.2 määratletud protsessi. FRD määratleb funktsionaalsete nõuete ulatuse, mida kasutatakse arendusetapis spetsifikatsioonide koostamiseks. Nõuete etapp on illustreeritud joonisel 3.1.

3.1 Uus töö, mis on hõlmatud töörühma hartaga

Kui töörühm soovib alustada uut tööd ja usub põhjendatult, et funktsionaalsus, mida ta soovib lisada, kuulub juba tema töörühma harta reguleerimisalasse, võib töörühm alustada tööd FRD-ga, tingimusel et nad teatavad sellest viivitamatult BARB-ile. Töörühm lisab BARB-le saadetavasse teatesse kavandatava uue töö kirjelduse ja WG harta koopia koos esile tõstetud keelega, mis lubab neil uut tööd alustada.

Kui BARB lükkab töörühma analüüsi tagasi, peab töörühm lõpetama töö FRD-ga ja jätkama jaotises 3.2 kirjeldatud NWP-protsessi. Kui BARB kiidab töörühma analüüsi heaks, teavitab töörühm viivitamata BSTS-i (e-posti teel aadressile specifikatsioon.manager@bluetooth.com) ja BSTS lisab selle punkti järgmisesse BoD päevakorda.

Töörühm lisab BSTS-ile saadetavasse teatesse sama teabe, mille ta edastas BARB-le. Kui juhatus lükkab töörühma analüüsi tagasi, peab töörühm lõpetama töö FRD-ga ja jätkama punktis 3.2 kirjeldatud NWP-protsessiga. Kui juhatus kiidab töörühma analüüsi heaks, võib töörühm jätkata tööd FRD-ga, nagu on kirjeldatud jaotises 3.3.

3.2 Uus tööettepanek (NWP)

Iga liige, WG, SG või EG võib luua ja esitada NWP (Bluetooth SIG -i kaudu) websait [10]). NWP peab sisaldama vähemalt teavet järgmise kohta, kasutades [8] ametlikku malli:

• Kasutaja stsenaariumid
• Liikmete kohustus töötada välja FRD ja millistes valdkondades (nt kaasautor, autor, Reviewee, prototüüpimine)
• Kavandatud FRD töö juhtimine
• Kavandatud FRD töö grupiülesanne
• Peamise autori (te) e-posti aadress

Märkus. Juhised NWP protsessi kohta on saadaval Bluetooth SIG -is websait [10].

BSTS täidab NWP väljatöötamisel järgmisi ülesandeid:

• Esitage autor (id) kättesaamise kinnitus (tavaliselt seitsme kalendripäeva jooksul pärast kättesaamist) ja kirjeldage järgmised sammud.
• Vajadusel tehke koostööd autoriga (autoritega), et NWP oleks selge ja täielik. See võib nõuda mitut NWP kordust.
• Kui NWP sisaldab avaldusi vastuvõetud Bluetoothi ​​spetsifikatsioonide vigade kohta, tehke koostööd autori (te) ga file sisestused vigade süsteemi.
• Kui märgatakse, et NWP dubleerib tööd, mis on juba pooleli või on juba lõpetatud, teavitage nende hindamiseks teiste tööde autoreid.
• Postitage NWP NWP -sse websait on kõigile liikmetele kättesaadav.
• Teatage kõigile liikmetele, et NWP on uuesti saadavalview ja kas liikmete täiendav pühendumus FRD väljatöötamiseks on vajalik.

Liikmed võivad NWP-ga seotud küsimuste esitamiseks või tagasiside saamiseks pöörduda autori (te) poole.

Vähemalt kolm liikmesettevõtet peavad kohustuma osalema saadud FRD valmimises, et NWP saaks kandideerida BoD heakskiitmiseks, ja vähemalt üks liikmesettevõte peab olema assotsieerunud või korraldajaliige. NWP BoD heakskiidul määrab BoD NWP olemasolevale täisliikmelisele WG alamrühmale või SG tööle FRD-ga töötamiseks (kirjeldatud punktis 3.3). Kui asjakohast WG-alamrühma või SG-d pole, võidakse see luua.

NWP-de puhul, millel on piisav liikmete pühendumus, täidab BSTS järgmisi täiendavaid ülesandeid:

• Vähemalt 13 päeva enne seda, kui juhtimisüksus teeb ettepaneku NWP heaks kiita, teavitage oodatavat NWP heakskiitu BARB-st ja rühmast, kellele NWP-d soovitatakse määrata. Seda tehakse tagasiside pakkumiseks sellistes valdkondades nagu kavandatav rühm, kas olemasolev töö on juba hõlmatud NWP-ga jne.
• Esitage valmis NWP juhatusele.

1. Kui NWP esitavad liikmed, kes pole grupiga seotud, korraldage, et üks liikmetest esitaks NWP juhatusele.
2. Kui NWP esitab rühm, korraldage rühma esimehel NWP esitamine juhatusele.
3. Kutsu BDK koosolekule BARBi juhataja ja selle rühma esimehed, kuhu NWP-d soovitatakse määrata.
4. Kui BoD on NWP heaks kiitnud ja määranud, teavitage gruppi, kellele see määrati; autor (id); liikmed, kes on NWP-s määratlenud kohustuse välja töötada vastav FRD; ja kui NWP pakub välja rühm, siis tulemuste rühm ja järgmised sammud.

Kui BoD on NWP heaks kiitnud, värskendage NWP olekut websaidile.

BoD võib oma äranägemisel tagasi lükata mis tahes NWP, ntampKui ressursside piiratuse tõttu on töö juba täielikult lõpule viidud, siis ei kuulu töö Bluetooth SIG -i juhtdokumentide (nt rakenduste programmeerimisliidese (API)) [2] reguleerimisalast välja või kui kavandatud tööd tuleks filed kui viga. Kui NWP lükatakse tagasi, teatab BSTS autorile (autoritele), NWP -s kindlaksmääratud liikmetele, kes kohustuvad välja töötama vastava FRD, ja kui NWP teeb ettepaneku rühm, siis rühmale. Teade sisaldab kõiki tagasilükkamise põhjuseid. Autor (id), pühendunud liikmed või rühm võivad taotleda BoD päevakorras aega tagasilükkamise vaidlustamiseks.

Kui liige või grupp soovitab funktsiooni eemaldamist vastuvõetud spetsifikatsioonist, peab rühm või liige valmistama ette NWP. UT peab sisaldama analüüsi mõju kohta, mida eemaldamine avaldab tagasiulatuvale ühilduvusele ja koostalitlusvõimele, sealhulgas analüüsi juhtumitele avaldatava mõju kohta.

NWP-sid pole vaja CSS-, GSS- või MDP-spetsifikatsioonide täiustamiseks: tavaliselt tulenevad CSS-, GSS- või MDP-spetsifikatsioonide värskendused muudest spetsifikatsioonidest, millel on oma NWP-d.

3.3 Funktsionaalsete nõuete dokument (FRD)

FRD-d määratlevad funktsionaalsed nõuded kasutaja stsenaariumide lubamiseks. FRD peab sisaldama vähemalt järgmist teavet, kasutades [8] esitatud ametlikku malli:

• Kasutaja stsenaariumid
• Funktsionaalsed nõuded, mis põhinevad kasutaja stsenaariumidel
• Liikme kohustus töötada välja spetsifikatsioon (id)
• Liikmete valikuline prototüübi tugi oodatud rollide jaoks
• Soovitatav töörühm saadud spetsifikatsiooni (de) väljatöötamiseks

FRD arendamine

FRD-d loovad määratud täisliikmeline WG alarühm või SG-i liikmed BSTS-i toimetuse toel. Grupiga võivad liituda kõik FRD arenduses osalemisest huvitatud liikmed.

FRD-d peavad näitama vähemalt kahe (kuigi soovitatakse kolme) assotsieerunud või korraldaja tasemel liikmesettevõtte kohustust osaleda saadud spetsifikatsiooni väljatöötamisel. FRD esitavad töörühmad või peasekretärid peaksid püüdma saavutada laialdast tuge kontserni liikmetelt, kes esindavad FRD-s määratletud kavandatud sihtvaldkonnasektorit.

FRD -s välja pakutud uus funktsioon peaks olema toetatav võimalikult paljudel transpordivahenditel ja olemasolevatel seadmetel. See hõlmab ntample, toetades GATT-põhist profiles ja teenused nii põhikiiruse/laiendatud andmesageduse (BR/EDR) kui ka Bluetoothi ​​madala energiatarbega (LE) edastamisel. Kui uuel funktsionaalsusel puudub transpordi jaoks piisav liikmete tugi, ntampKuna liikmed ei ole pühendunud transpordi kasutamise määratlemisele või potentsiaalselt ebapiisav arv IOP -testplatvorme ühe või mitme rolli jaoks, võidakse selle transpordi toetus FRD -st välja jätta.

Kui pole teisiti põhjendatud, uus funktsionaalsus, profileja teenused peavad vastama punktis 3.3.2 kirjeldatud ühilduvusnõuetele.

WG või SG peab esitama FRD BARBile uuestiview ja heakskiit. BARB peab oma tehnilise hinnangu alusel FRD kas heaks kiitma või tagasi lükkama. Kui BARB on selle heaks kiitnud, tehakse FRD kõigile liikmetele kättesaadavaks ja BSTS saadab teate selle kättesaadavuse kohta.

FRS-sid pole vaja CSS-, GSS- või MDP-spetsifikatsioonide täiustamiseks: tavaliselt tulenevad CSS-, GSS- või MDP-spetsifikatsioonide värskendused muudest spetsifikatsioonidest, millel on oma FRD-d.

Tagasiühilduvusnõuded

Tagurpidi ühilduvus BR / EDR-iga

BR / EDR-i töö puhul on tagurpidi ühilduvuse nõue määratletud kui koostöö Bluetooth-i spetsifikatsiooni v1.1 ja uuemate BR / EDR-osadega.

Tagasiühilduvus Bluetoothi ​​madala energiatarbega

LE-operatsiooni puhul on tagurpidi ühilduvuse nõue määratletud kui koostöö Bluetoothi ​​spetsifikatsiooni v4.0 ja uuemate versioonide LE-osaga.

Tagasiühilduvus muude spetsifikatsioonide kui põhispetsifikatsiooni jaoks

Muude spetsifikatsioonide puhul kui Bluetoothi ​​põhispetsifikatsioon, tuleb antud versiooni ühilduvus tagasi hoida kõigi varasemate versioonidega, millel on sama põhiversiooni number. Näiteksample, versioon 1.3 peab ühilduma versioonidega 1.2, 1.1 ja 1.0, kuid versioon 2.0 ei pruugi ühilduda versioonidega 1.0, 1.1, 1.2 ja 1.3. Pange tähele, et põhispetsifikatsiooni põhiversiooni numbri suurendamine ei tähenda varasema versiooniga ühilduvuse puudumist.

Erand tagurpidi ühilduvuse nõuetest

WG või SG võib teha ettepaneku vabastada konkreetne funktsionaalsus tagurpidi ühilduvuse nõudest, kui see on põhjendatud. NäiteksampKui ilmneb, et funktsionaalsuse turuleviimise määr on madal või koostalitlusvõimega seotud probleemide tõttu on funktsionaalsuse muutmise asemel parem see eemaldada või asendada. Töörühm või SG peab FRD-sse lisama kõik tagasiühilduvuse erandid, mille BARB kiidab heaks pärast FRD heakskiitu. Kõik BARB-i heakskiidetud erandid esitatakse BoD-le kinnitamiseks 0.9/CR Stage.

3.4 Töörühma harta

Kui BARB kiidab heaks FRD, mis tehakse ettepanek määrata olemasolevale töörühmale, peab see töörühm koostama oma põhikirja värskenduse eelnõu, et lisada uus funktsionaalsus ulatusele (välja arvatud juhul, kui juhatus oli varem heaks kiitnud töörühma analüüsi, et töörühma harta värskendus on pole nõutud). Kui BARB kiidab heaks FRD, mis tehakse ettepanek määrata uuele töörühmale, peavad BARB ja liikmed, kes on huvitatud FRD-s välja toodud funktsionaalsuse väljatöötamisest, koostama uue töörühma harta eelnõu, lisades harta reguleerimisalasse uue funktsionaalsuse .

Kui uus või ajakohastatud töörühma harta on koostatud, tuleb see uuesti BARBile esitadaview ja heakskiit. Kui BARB on harta heaks kiitnud, esitatakse uue või uuendatud WG harta eelnõu BoD -le kinnitamiseks.

Kui juhatus on harta heaks kiitnud, peab töörühm, kellele juhatus määras spetsifikatsioonide väljatöötamise, tegema tihedat koostööd FRD-i ette valmistanud rühmaga, kui selle FRD-d on vaja värskendada või selgitada. Kui arendusetapis on vaja FRD värskendust, tuleb järgida jaotises 3.3 ja selles jaotises kirjeldatud protsesse; spetsifikatsioonide väljatöötamine võib toimuda paralleelselt FRD ja WG harta uuendustega.

3.5 Nõuded Faasist väljumise nõuded

Nõuete faas on lõpule jõudnud ja arendusetapp algab siis, kui töörühm on FRD jaoks vajaliku ulatusega töörühma kas kinnitanud või heaks kiitnud ja järgmised nõuded on täidetud:

• NWP on kas juhatuse poolt heaks kiidetud või juhatus on nõustunud, et NWP ei ole vajalik.
• FRD ja vastav WG harta on BARB heaks kiitnud.

 

4. Arendusfaas

Arendusetapis loovad määratud töörühmad uue spetsifikatsiooni ja / või täiustavad olemasolevat spetsifikatsiooni. FRD määratleb uue või täiustatud Bluetoothi ​​spetsifikatsiooni nõuded. Spetsifikatsioonis ei ole lubatud funktsionaalsust, mis ei ole mõistlikult seotud FRD nõuetega. Eesmärk on luua 0.9 / CR spetsifikatsioon, mis on arendusetapi lõpus valmis valideerimisetapiks (kirjeldatud 5. jaos).
Arendusfaasis edeneb spetsifikatsioon (või spetsifikatsiooni täiustamine) kolme sekundi jooksultages.

Uue spetsifikatsiooni jaoks on kolm stagneed on:

• 0.5 Stage
• 0.7 Stage
• 0.9 Stage

Spetsifikatsiooni täiustamiseks on kolm stagneed on:

• Parendusettepaneku dokumendi eelnõu (DIPD) Stage
• Lõplik parendusettepaneku dokument (FIPD) Stage
• Muudatustaotlus (CR) Stage

Iga stage on täpsemalt kirjeldatud järgmistes alajaotistes. Allpool olev joonis 4.1 illustreerib erinevaid dokumente, mida töörühm igal etapil koostabtage.

Joonis 4.1: Üleview spetsifikatsioonist stagmis ilmnevad arendusfaasis

BARBi roll kogu spetsifikatsioonide väljatöötamise protsessis on pakkuda töörühmadele nõu ja tehnilist abi. Töörühmad võivad igal ajal taotleda BARB-ilt tehnilisi nõuandeid spetsifikatsioonide väljatöötamise ja spetsifikatsioonis kasutatavate arhitektuurikontseptsioonide kohta. Töörühmi julgustatakse eriti paluma BARB-ilt varajast tagasisidet funktsioonide kohta, millel on keerulisemad arhitektuurilised kaalutlused.

4.1 0.5/DIPD Stage

0.5/DIPD S ajaltage, töörühm töötab välja järgmised ametlikud mallid, mis on esitatud punktis [8]:

1. Uue spetsifikatsiooni jaoks on spetsifikatsiooni 0.5 mustand, mis peab sisaldama vähemalt järgmist teavet:

• Arhitektuur raamdokumendis sätestatud nõuete täitmiseks
• Protokollide jaoks on määratletud teenuse pöörduspunktid
• Teenuste, andmete ja käitumise kohta
• Profi jaoksfiles, tuvastatud protokollid ja täpsustatud funktsionaalsus

2. Spetsifikatsiooni täiustamiseks DIPD mustand, mis peab sisaldama vähemalt järgmist teavet:

• Taust: Töö ulatus, tööd suunavad eesmärgid ja see, kuidas see konkreetne ettepanek mahub
• Läbiview ettepanekust: DIPD pakutud laiendatud funktsionaalsuse (lisatud paindlikkus, parem jõudlus jne) kokkuvõte, sealhulgas selge kirjeldus selle kohta, kuidas uus funktsionaalsus sobib praeguse spetsifikatsiooni versiooniga. Kui töörühm on hinnanud mitut ettepanekut, tuleks need ettepanekud lisada, et BARB-l oleks võimalus kindlaks teha, kas eelistatud ettepaneku valimisel tehti piisav hoolsus.
• Nõuete katvus: Ettepanekus esitatud funktsionaalsete nõuete katvuse kokkuvõte, viidates asjakohases FRD-s toodud asjakohastele süsteeminõuetele ja kasutusstsenaariumidele
• Probleemi määratlus: Ettepaneku (de) ga lahendatud probleemide aruanne
• Valiku kriteeriumid: Avaldus valiku / tulemuslikkuse kriteeriumide kohta seotud hindamismõõdikute põhjal, mis on juhtinud valikuprotsessi
• Valiku põhjendus: Hindamismõõdikute uurimine, mis õigustab valikut ettepanekute vahel ja näitab kompromisse
• Kirjeldus: Funktsionaalsuse ja laiendatud protokollide kirjeldus. Seda jaotist saab erinevate vajadustega kohandada, lisades asjakohaseid alajaotisi.

3. Testistrateegia: Bluetoothi ​​kvalifikatsiooniprogrammi raames kavandatava (või testimata) funktsionaalsuse kirjeldus ja selle funktsionaalsuse testimise ettepanek (nt ootused alam- või ülemisele testijale) ja kui katsetele omistatakse vastavus- või koostalitlusvõime katsed või mõlema kombinatsioon). See võib olla eraldi dokumendis või 0.5/DIPD spetsifikatsiooni eraldi osas. Testistrateegias kasutatavaid tavasid on kirjeldatud testistrateegias ja terminoloogiasview dokument (TSTO) [5].

Dokumentide esmane publik sellel stage on töörühma liikmed ja BARB, kes review arhitektuurilised ettepanekud ja nõuete katvus ning STI, kes reviews testimisstrateegia. Enamikul juhtudel on dokumendid sellel stage ei ole mõeldud sisaldama teksti, mis on kavas lisada lõplikku spetsifikatsiooni.

BSTS peab uuestiview kõik dokumendid, et need oleksid kooskõlas Bluetoothi ​​koostamisjuhistega [1], ja tuvastada probleemid, mida töörühm peab lahendama. BARB peab uuestiview 0.5/DIPD spetsifikatsioon. Spetsifikatsiooni täiustamiseks peab BARB ka uuesti tegemaview DIPD, et järgida punktis 3.3.2 kirjeldatud ühilduvusnõudeid. STI tuleb uuestiview testistrateegia.

BARB peab oma tehnilise hinnangu alusel 0.5/DIPD spetsifikatsiooni heaks kiitma või tagasi lükkama. Kui BARB selle heaks kiidab, tehakse 0.5/DIPD spetsifikatsioon kättesaadavaks Bluetooth SIG -is websaidi kõigile assotsieerunud ja korraldajaliikmetele ning BSTS väljastab selle kättesaadavuse kohta teate. 0.5/DIPD S juurestage, testimisstrateegia heakskiit ei ole nõutav.
0.5/DIPD Stage ei ole vajalik CSS-i, GSS-i või MDP spetsifikatsioonide täiustamiseks

0.5/DIPD Stage väljumisnõuded

0.5/DIPD Stage on valmis ja 0.7/FIPD Stage algab siis, kui on täidetud järgmised väljumisnõuded:

• BSTS on lõpetanud uuestiview0.5/DIPD spetsifikatsiooni ja testimisstrateegiat.
• BARB kiitis heaks spetsifikatsiooni 0.5 / DIPD.
• STI on oma töö lõpetanudview katsestrateegiast.
• BSTS on teinud heakskiidetud 0.5 / DIPD spetsifikatsiooni kõigile assotsieerunud ja korraldajate liikmetele kättesaadavaks.

4.2 0.7/FIPD Stage

0.7/FIPD S ajaltage, töörühm töötab välja järgmised ametlikud mallid, mis on esitatud punktis [8]:

1. Uue spetsifikatsiooni jaoks on spetsifikatsiooni 0.7 mustand, mis peab sisaldama vähemalt järgmist teavet:

• Kirjeldus kõikidest muudatustest, mis on tehtud pärast BARB-i poolt heaks kiidetud 0.5, sealhulgas uued või muudetud ettepanekud, valikukriteeriumid ja valiku põhjendus. Muudatusi tuleb kirjeldada sama üksikasjalikult, nagu on nõutud 0.5 S-stage.
• Käsitletud kõiki FRD funktsionaalseid nõudeid.

2. Spetsifikatsiooni täiustamiseks FIPD eelnõu, mis peab sisaldama vähemalt järgmist teavet:

• Kõigi pärast BARB-i heakskiidetud DIPD-d tehtud muudatuste kirjeldus, sealhulgas uued või muudetud ettepanekud, valikukriteeriumid ja valiku põhjendus. Muudatusi tuleb kirjeldada sama üksikasjalikult, nagu on nõutud DIPD S-stage.
• Vajaduse korral arendati edasi DIPD-d käsitlevaid alasid 4.1.
• Paranduse täielik kirjeldus.
• Uuendatud arhitektuuriline kirjeldus.
• Käsitletud kõiki FRD funktsionaalseid nõudeid.

3. 0.7 / FIPD testidokumendid, mis peavad sisaldama vähemalt järgmist teavet:

• Testikomplekt, mis koosneb TSTO-s kirjeldatud testide eesmärkide loendist [5].
• Rakenduse vastavusavaldus (ICS), nagu on kirjeldatud TSTO-s [5].

Spetsifikatsioonide täiustamiseks võib Test Suite'i ja ICS-i tarnida kas eraldi dokumentidena või FIPD-i täiendavate jaotistena.

Sellel s.-l koostatud dokumentide esmane publiktage on töörühma liikmed ja BARB, kes review funktsiooni või täiustuse täielik kirjeldus, sealhulgas lõplikku spetsifikatsiooni lisamiseks kavandatud tekst. STI on vaatajaskondview katsedokumentidest.

BSTS hakkab uuestiview 0.7/FIPD spetsifikatsiooni uued või muudetud osad ja testdokumendid, et need oleksid kooskõlas Bluetoothi ​​koostamisjuhistega, sealhulgas Bluetooth SIG -i kehtestatud keelekonventsioonid. BARB hakkab review 0.7/FIPD spetsifikatsioon.

BSTS abistab töörühma 0.7 / FIPD testdokumentide ettevalmistamisel vastavalt TSTO-le [5].

STI tuleb uuestiview 0.7/FIPD testdokumendid. Töörühm peab esitama STI -le 0.7/FIPD spetsifikatsiooni viitena, kui seda uuesti tehakseviewkasutades 0.7/FIPD testdokumente, mida STI taastabview vastavalt STI spetsifikatsioonile Review Protsessi kontrollnimekiri [6].

Pärast seda, kui BARB on oma töö lõpetanudview 0.7/FIPD spetsifikatsioonist ja STI on lõpetanud oma uuestiview 0.7/FIPD testdokumentidest teeb BSTS reviewed 0.7/FIPD spetsifikatsioon, mis on kättesaadav kõigile assotsieerunud ja promootori liikmetele.

0.7/FIPD Stage ei ole vajalik CSS-i, GSS-i või MDP spetsifikatsioonide täiustamiseks.

0.7/FIPD Stage väljumisnõuded

0.7/FIPD Stage on valmis ja 0.9/CR Stage algab siis, kui on täidetud järgmised väljumisnõuded:

• BSTS on lõpetanud uuestiview0.7/FIPD spetsifikatsiooni ja katsedokumente.
• BARB on uuesti lõpetanudviewvastavalt 0.7/FIPD spetsifikatsioonile.
• STI on uuesti lõpetanudview0.7/FIPD testikomplekti (testimiseesmärgid) ja 0.7/FIPD ICS -i.
• BSTS on teinud reviewed 0.7/FIPD spetsifikatsioon, mis on kättesaadav kõigile assotsieerunud ja promootori liikmetele.

4.3 0.9/CR Stage

CR-sid on kahte tüüpi: integreeritud CR, mis on kogu vastuvõetud spetsifikatsiooni muudatuste jälgimisega dokument, mis sisaldab kõiki muudatusi alates eelmisest versioonist, ja lühendatud CR, mis on juhis ainult mõjutatud jaotiste muutmiseks. spetsifikatsiooni versioon, millel CR põhineb.

0.9/CR S ajaltage, töörühm töötab välja järgmised ametlikud mallid, mis on esitatud punktis [8]:

1. Uue spetsifikatsiooni jaoks on spetsifikatsiooni 0.9 sisu täielik tervik, mis peab sisaldama vähemalt järgmist teavet:

• Kõigi BARB-re'i järgselt tehtud muudatuste kirjeldusviewed 0.7 spetsifikatsioon (või alates spetsifikatsioonist 0.5, kui 0.7 spetsifikatsiooni tootmisest loobuti), sealhulgas uus või
• muudetud ettepanekud, valikukriteeriumid ja valiku põhjendus. Muudatusi tuleb kirjeldada sama üksikasjalikult, nagu on nõutud 0.5 S-stage ja 0.7 Stage.

2. Spetsifikatsiooni täiustamiseks:

• Kas integreeritud CR, mis peab sisaldama vähemalt järgmist teavet:
• Kõigi BARB-re'i järgselt tehtud muudatuste kirjeldusviewed FIPD (või alates DIPD-st, kui FIPD-st on loobutud), sealhulgas uued või muudetud ettepanekud, valikukriteeriumid ja valiku põhjendus. Muudatusi tuleb kirjeldada sama üksikasjalikult, nagu on nõutud DIPD S-stage ja FIPD Stage.
• Kõik muudatused, mida pakuti varem vastuvõetud spetsifikatsioonile, kasutades muudatuste jälgimist.
• Kõik heakskiidetud tehnilised vead (kusjuures igale vigale viidatakse vigade arvule), mida näidatakse muudatuste jälgimise abil ja mis tuleb veel lisada varem vastu võetud spetsifikatsiooni versiooni, ja need mõjutavad teksti, mis on seotud spetsifikatsiooni täiustamisega; või mis muul viisil mõjutavad IOP testimist.

3. Või lühendatud CR, mis peab sisaldama vähemalt järgmist teavet:

• Kõigi BARB-re'i järgselt tehtud muudatuste kirjeldusviewed FIPD (või alates DIPD-st, kui FIPD-st on loobutud), sealhulgas uued või muudetud ettepanekud, valikukriteeriumid ja valiku põhjendus. Muudatusi tuleb kirjeldada sama üksikasjalikult, nagu on nõutud DIPD S-stage ja FIPD Stage.
• Kõik muudatusettepanekud, mis on tehtud spetsifikatsiooni igale mõjutatud jaotisele ja lõikele, mida CR soovitab muuta.
• Kõik kinnitatud tehnilised vead (kusjuures igale veale on viidatud veaarvuga), mis on näidatud märgistusega, mis ei ole veel lisatud varem vastuvõetud spetsifikatsiooni versiooni, ja see mõju-tekst, mis on seotud spetsifikatsiooni täiustamisega; või mis muul viisil mõjutavad IOP testimist.

4. CSS-i CR (kui spetsifikatsioon nõuab uusi kirjeid), mis võib olla kinnitatud spetsifikatsiooni lühendatud CR-i.
5. GSS CR (kui spetsifikatsioon nõuab uusi kirjeid), mis võib olla kinnitatud spetsifikatsiooni lühendatud CR-sse.
6. MDP CR (kui spetsifikatsioon nõuab uusi kirjeid), mis võib olla kinnitatud spetsifikatsiooni lühendatud CR-sse.
7. 0.9 / CR-testidokumendid, mis peavad sisaldama vähemalt järgmist teavet, kasutades [8] esitatud ametlikku malli:

• TSTO-s kirjeldatud kirjeldus 0.9 / CR Test Suite, mis sisaldab sisu täielikke testijuhtumeid ja sellega seotud testjuhtumite kaardistamise tabelit (TCMT) [5].
• 0.9 / CR ICS, nagu on kirjeldatud TSTO-s [5].
• Kui testide konfigureerimine nõuab rakenduse testimise (IUT) jaoks konkreetseid parameetreid, siis 0.9 / CR juurutamise eXtra teavet testimiseks (IXIT).
• 0.9 / CR testijuhtmete loend (TCRL) (valikuline põhispetsifikatsiooni värskenduste jaoks).

8. Testkatteanalüüs, mis näitab, milliseid spetsifikatsiooninõudeid on 0.9 / CR testikomplekti raames testitud või testimata (spetsifikatsiooni täiustuste jaoks peab testkatteanalüüs sisaldama ainult äsja lisatud ja mõjutatud funktsionaalsust, mitte aga algne spetsifikatsioon).
9. IOP testiplaan.

Spetsifikatsioonide täiustamiseks võib Test Suite'i, ICS-i ja IXIT-i tarnida kas eraldi dokumentidena või lühendatud CR-i lisalõikudena.

Enamasti peaks integreeritud või lühendatud CR põhinema spetsifikatsiooni varem vastuvõetud versioonil, kuid see võib põhineda ka viimasel vaheprojektil. Viimane vaheprojekti spetsifikatsiooni versiooninumber peab olema külmutatud dokumendi versiooniga seotud versiooni number, mis aja jooksul ei muutu. Muul juhul lisatakse täiendav identifitseerimisteave (näiteks dokumendi kuupäev ja a URL püsivasse kohta) tuleb esitada konkreetse „baasversiooni“ kindlakstegemiseks. Kui kasutatakse vahepealset mustandit, tuleb lisada kõik muudatused, mis ei ole otseselt CR-ga seotud antud jaotises ja mida CR modifitseerib, kuid neid ei pea näitama märgistuse abil. Kui vahepealse mustandi asjakohaseid osi hiljem värskendatakse, tuleb CR-i värskendada, et kajastada vahepealse mustandi värskendusi.

Ideaaljuhul integreeritakse lühendatud CR-materjal enne valideerimisfaasi täieliku spetsifikatsiooni ja täielike katsedokumentide mustandisse, kuid need võidakse integreerida ka valideerimisfaasi alguses. Kui spetsifikatsioonile on välja töötatud mitu funktsiooni (nt põhispetsifikatsioon), võib pärast IOP-testimise lõppu olla soovitav integreerida tunnused ühte mustandisse.

BSTS hakkab uuestiview 0.9/CR spetsifikatsioon ja testdokumendid, et need oleksid kooskõlas Bluetoothi ​​koostamisjuhistega. Siis BARB läheb uuestiview 0.9/CR spetsifikatsioonile, millele järgneb hiljem silmasisese rõhu katseplaan (nagu kirjeldatud punktis 4.3.1). Kui WG on esitanud spetsifikatsiooni 0.9/CR BARB -le uuestiview, BSTS teeb selle kõigile liikmetele uuesti kättesaadavaksview ja teavitama kõiki liikmeid selle kättesaadavusest. Sellest hetkest alates teeb BSTS spetsifikatsiooni väljatöötamise protsessis BARBile esitatud spetsifikatsiooni mustandid kõigile liikmetele kättesaadavaks, edastades perioodiliselt kõikidele liikmetele.

Spetsifikatsiooni täiustamiseks soovitab töörühm juhatusele, kas spetsifikatsiooni eelmised versioonid tuleks aeguda või tühistada, sealhulgas soovituse (te) tehnilised põhjused.

BARB hakkab review WG analüüs 0.9/CR spetsifikatsiooni vastavuse kohta FRD -s esitatud nõuetele, võimalikud turvaprobleemid, regulatiivsed probleemid, Bluetooth -arhitektuurile vastavus ja spetsifikatsiooni täiustamise puhul jaotis 3.3.2 kirjeldatud ühilduvusnõuete järgimine .XNUMX. Kui BARB tuvastab võimalikke turvaprobleeme, teavitab BARB sellest BSTS -i uuestiview ja koordineerimine turvalisuse ekspertrühmaga; ja kui BARB tuvastab regulatiivseid tagajärgi, teavitab BARB sellest BSTS -iview ning koordineerima reguleerimiskomitee ja Bluetooth SIGi õigusnõustajaga. BARB peab kas kinnitama või tagasi lükkama spetsifikatsiooni 0.9/CR, tuginedes oma tehnilisele otsusele ja käesolevas lõigus kirjeldatud teguritele.

STI saab uuestiview 0.9/CR testdokumendid, mis võtavad arvesse katvuse analüüsi. STI peab 0.9/CR testidokumendid heaks kiitma või tagasi lükkama.

Pärast seda, kui BARB on heaks kiitnud spetsifikatsiooni 0.9/CR, esitab töörühm IAR -i testplaani BARB -le uuestiview.

BARB-i poolt heaks kiidetud spetsifikatsioon 0.9 / CR esitatakse juhatusele, et kiita heaks IOP-testimise algus ja 0.9 / CR-spetsifikatsiooni avaldamine kõigile liikmetele.

Võimalike juriidiliste probleemide esiletoomiseks võivad töörühmad nõuda spetsifikatsiooni uuestiview Bluetooth SIGi õigusnõustaja (juriidiline review) enne kohustuslikku juriidilist uuestiview toimub vastuvõtmise/heakskiitmise faasis. Kuid spetsifikatsioonide täiustamiseks on õiguslik review tuleks teha integreeritud CR -ga (erinevalt lühendatud CR -st) ja see tuleks ressursside olemasolul ette planeerida nii kaua kui võimalik.

IOP-testi plaan

Töörühm töötab välja kirjaliku silmasisese rõhu katseplaani, mis peab vastama kõigile allpool määratletud nõuetele kasutamiseks silmasisese rõhu testiürituste valideerimisetapis. Töörühmad peavad esitama IOP -i testplaani BARB -le uuestiview enne IOP -testi sündmuse (te) algust. Lihtsate spetsifikatsioonide täiustuste jaoks (eriti nende puhul, mis ei nõua testkomplekti testjuhtumite muutmist ega lisamist), ei pruugi IOP -testimine olla vajalik ja WG võib esitada BARB -le taotluse IOP -testimisest loobumiseks, kasutades määratud protsessi punktis 4.4.

IOP-testide kava peab sisaldama

1. Testige juhtumeid kõigi uute kohustuslike, valikuliste ja tingimuslike funktsioonide kontrollimiseks
2. Iga op-koodi jaoks vähemalt üks testjuhtum
3. Iga parameetri kohta vähemalt üks testjuhtum
4. Igale paketitüübile vähemalt üks testjuhtum
5. Spetsifikatsioonide täiustuste tagurpidi ühilduvuse testimisjuhud, et kõigi täiustatud funktsioonide puhul oleks täidetud punktis 3.3.2 loetletud nõuded (vt ka jaotist 4.3.1.1).
6. Testjuhtumid, kus IUT puutub kokku väärtustega väljaspool määratletud vahemikke või käitumisaspektidega, mida peetakse kehtetuks või ootamatuks (kehtetu käitumise testjuhtumid). Pange tähele, et mis tahes kehtetu käitumise algatajaks on eeldatavasti testija, näiteks PTS või muu testimisvahend.
7. Kõiki ajutisi määratud numbreid (mis on valitud kooskõlastatult BSTS-iga, et vältida kattumist eelseisvatel IOP-testi üritustel), mida kasutatakse IOP-testi sündmusel, nagu on kirjeldatud punktis 4.3.1.2.
8. Vajaliku arvu sõltumatute rakenduste kindlaksmääramine, mis peavad läbima iga katsejuhtumi, võttes arvesse punktis 4.3.1.3 kirjeldatud katvusnõudeid
9. Test Suite'i kõigi testijuhtumite tuvastamine, mis töörühma arvates tuleks välja jätta, ja nende väljajätmise põhjendus. Need hõlmavad tavaliselt järgmist: • Tuleviku tõestamise testijuhud (nt ühised testid võimalike tulevaste täienduste mahutamiseks, näiteks täiendavad omadused, laiendavad omadused või tulevaseks kasutamiseks reserveeritud (RFU) bitide või väljade kasutamine)
   • Testjuhtumid, mis on teiste kaasatud testide alamhulk
   • Üldised testijuhtumid, mis on praktiliselt identsed testidega, mida kasutatakse mitme muu spetsifikatsiooni jaoks (nt tavaliste veakoodide käivitamine)
   • Katsejuhtumid, millel on sama katse-eesmärk, kui katsejuhtumitel, mis sõidavad üle teise transpordivahendi (nt BR-EDR-i juhtum, mis sarnaneb LE-testjuhtumiga)
   • Rakenduse töökindlus või stressitestimine

IOP-testide kava võib sisaldada ka IOP-testimisele ainuomaseid teste, näiteks otsast-lõpuni testimisjuhud, mis ühendavad keerulisemad järjestused, mis võivad sarnaneda tüüpilise kasutaja stsenaariumiga.

Kuigi IOP-testide kava BARB-i heakskiit pole vajalik (tingimusel, et IOP-testimiskava muudetakse ja täiustatakse iga IOP-testi sündmusega ka edaspidi), on IOP-i katsearuande BARB-i kinnitamine vajalik (vt punkt 5.1.1) . Kui IOP-testide kava ei vasta kõigile punktis 4.3.1 määratletud nõuetele, peaks töörühm enne IOP-testi sündmuse (te) algust esitama kokkuvõtte kõikidest teadaolevatest dispersioonidest ja iga BARB-i variatsiooni põhjenduse.

IOP testimiskava ja testijuhud peaksid põhinema peamiselt seotud spetsifikatsiooni testdokumentide sisul.

IOP-testisündmuste tõhusaks muutmiseks peaks töörühmal olema IOP-testide kava ja kõik sellega seotud testijuhud täidetud ning ideaaljuhul rakendajatele kättesaadavad vähemalt üks kuu enne esimest IOP-testiüritust.

Tagasiulatuva ühilduvuse testimise kavandamine
Spetsifikatsioonide täiustamiseks tuleb tagurpidi ühilduvuse silmasisese rõhu testimisel arvestada kõigi spetsifikatsiooni aktiivsete ja aegunud versioonidega, kuna need Bluetooth -toodetes tavaliselt esinevad spetsifikatsioonid ja funktsioonid võivad olla väga pika elueaga (nt sõidukid). Töörühm peab analüüsima vajalikul tasemel tagurpidi ühilduvuse testimist (kui see on vajalik), sealhulgas testitavaid versioone ja teste, ning esitama selle analüüsi BARBile. BARB peab uuestiview analüüsida ja soovitada muudatusi (kui neid on), mida töörühm silmasisese rõhu testplaani lisada.

Tagasiühilduvuse testimisel osalevatel liikmetel soovitatakse kaasa võtta pärandiseadmed, mis on kvalifitseeritud eelmise (te) spetsifikatsiooni versiooni järgi. Töörühm peab IOP-i katsearuandes teatama kõikidest tagasiulatuvatest tõrgetest. Samuti soovitatakse liikmesettevõtetel teha tagasilöökide testimine oma laborites väljaspool IOP-testi sündmuse asukohta ja teatada spetsifikatsioonidega seotud probleemidest töörühmale.

IOP-testimisel kasutatud ajutised määratud numbrid
IOP-testi üritusel kasutatavate määratud numbrite ajutise määramise kooskõlastamiseks tuleb pöörduda BSTS-i ja BARB-i poole, et ei tekiks kattumisi ega vastuolusid muude spetsifikatsioonidega. Need ajutised väärtused tuleb lisada IOP-testide kavasse ja neid ei määrata ühegi vastuvõetud spetsifikatsiooni järgi.

IOP-testimiseks, kus pakutakse ühte või mitut uut 16-bitist UUID-väärtust, reserveeritakse IOP-testimiseks väärtused vahemikus 0x7F00 kuni 0x7FFF.

IOP-testimiseks, kus pakutakse välja üks või mitu uut fikseeritud protokolli teenuse multiplekseri (PSM) väärtust, kasutatakse väärtusi, mis algavad kehtiva vahemiku 0x0000 kuni 0x007F lõpust, nagu on määratletud põhispetsifikatsioonis.

Katvuse nõuded
Töörühm peab esitama BARB-le tõendi selle kohta, et vajalik arv (nagu on kirjeldatud järgnevates punktides) sõltumatuid rakendusi on iga testjuhtumi läbinud. Kõik töögrupi taotlused erandite tegemiseks nõutava arvu sõltumatute rakenduste kohta tuleb märkida BARB-le esitatud IOP-testide kavas.

Rakendusi peetakse üksteisest sõltumatuteks seni, kuni kõik valideerimisel olulised osad on välja töötatud iseseisvalt, st erinevate meeskondade poolt (mis ei pruugi ilmtingimata erinevatelt ettevõtetelt). BSTS võib aidata hinnata, kas prototüüpe saab pidada üksteisest sõltumatuteks, et säilitada rakenduse üksikasjade anonüümsus ja konfidentsiaalsus.

Pange tähele, et testimisvahendeid, sealhulgas PTS-i, ei peeta iseseisvateks rakendusteks.

Põhispetsifikatsiooni IOP katvuse nõuded
Põhispetsifikatsiooni funktsioon määratleb tavaliselt ühe või mitu rolli, kus iga roll on mõeldud koostoimimiseks ühe või mitme muu rolliga või võib-olla iseendaga.

Iga rollipaari puhul, mis on loodud üksteisega koostoimimiseks, tuleb näidata, et iga rolli vähemalt kolm sõltumatut rakendust toimivad koos täiendava rolli kolme sõltumatu rakendusega.

Iga rolli puhul, mis saab koostoimida sama rollis oleva muu seadmega, peab selle rolli vähemalt kolm iseseisvat rakendust näitama, et nad saavad selles rollis üksteisega suhelda.

Teenuse spetsifikatsioon IOP katvuse nõuded
Vähemalt kolm sõltumatut teenuse juurutamist peavad näitama, et need töötavad koos vähemalt ühe kliendi juurutusega, milleks võib olla PTS.

Profile ja protokolli spetsifikatsiooni IOP katvuse nõuded
Profile ja protokolli spetsifikatsioonid määratlevad tavaliselt ühe või mitu rolli, kus iga roll on koostalitlusvõimeline ühe või mitme teise rolliga või võib -olla iseendaga.

Iga rollipaari puhul, mis on loodud üksteisega koostoimimiseks, peab iga rolli vähemalt kaks iseseisvat rakendust näitama, et need toimivad koos täiendava rolli kahe sõltumatu rakendusega.

Iga rolli puhul, mis saab koostoimida sama rollis oleva muu seadmega, peab selle rolli vähemalt kolm iseseisvat rakendust näitama, et nad selles rollis üksteisega suhtlevad.

Mudeli spetsifikatsioon IOP katvuse nõuded
Vähemalt kolm sõltumatut serverimudeli või juhtmudeli rakendust peavad tõendama, et need toimivad koostöös vähemalt ühe kliendirakendusega (mis võib olla PTS), ja vähemalt üks kliendimudeli juurutamine peab näitama, et see töötab vähemalt ühe serverimudeli juurutamise ja PTS-iga.

Spetsifikatsiooni versiooni numeratsioon

0.9/CR S ajaltage, töörühm peab koostama juhtnõukogule esitamise soovituse versiooninumbri kohta, mida spetsifikatsioonile vastuvõtmisel rakendada.

Spetsifikatsioonide versioonid jagunevad kahte tüüpi: täieliku versiooni versioonid, mis sisaldavad uusi või värskendatud funktsioone, ja hooldusväljaande versioonid (tuntud ka kui “dot-Z versioonid”), mis integreerivad tehnilisi ja toimetuse vigu, kuid ei sisalda uusi ega värskendatud versioone. Funktsioonid. Täisversioonide versioonidel on kaheosalised numbrid XY kujul, näiteks 2.1 või 5.0, hooldushoolduse versioonidel on aga kolmeosalised numbrid XYZ kujul, näiteks 2.1.2. Z väärtus ei saa olla 0.

Mis tahes kahe versiooni puhul nimetatakse ühte kõrgemaks versiooniks ja teiseks madalamaks versiooniks. See määratakse järgmiste reeglite kohaselt:

• Kui X komponendid erinevad, on kõrgema X väärtusega “kõrgem versioon”.
• Kui X komponendid on samad, kuid Y komponendid erinevad, on kõrgema Y väärtusega “kõrgem versioon”.
• Kui XY komponendid on samad, kuid Z komponendid erinevad, on suurema Z väärtusega üks “kõrgem versioon”. Kaheosalist arvu XY käsitletakse sel eesmärgil kolmeosalise arvuna XY0.

Näiteksample, järgmised versiooninumbrid oleksid järjestuses madalaimast versioonist kõrgeimani: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. CSS -i puhul suurendab iga värskendus ainult versiooninumbri X -komponenti.

BoD heakskiidu eeldused
Spetsifikatsioonide väljatöötamise etapi lõpus peavad enne 0.9 / CR spetsifikatsiooni esitamist BoD-le kinnitamiseks vastama järgmistele nõuetele:

• Töörühm on katse analüüsi lõpule viinud.
• BSTS on lõpetanud uuestiview0.9/CR spetsifikatsiooni ja katsedokumente.
• BARB kiitis heaks spetsifikatsiooni 0.9 / CR.
• BARB on heaks kiitnud CSS CR-i (kui spetsifikatsioon nõuab uusi kirjeid), mis võib olla kinnitatud spetsifikatsiooni lühendatud CR-i.
• BARB on heaks kiitnud GSS CR ja MDP CR (kui spetsifikatsioon nõuab uusi kandeid).
• STI on heaks kiitnud 0.9/CR Test Suite'i, ICS-i ja TCRL-i koos IXIT-iga (eeldusel, et IXIT-i on vaja testikomplekti testide tegemiseks). TCRL on sel juhul valikulinetage põhispetsifikatsiooni värskenduste jaoks.
• Töörühm on esitanud BARB -le uuesti IOP -i katseplaaniview (kui BARB ei loobu testimisest).

BoD-le esitatavad dokumendid peavad sisaldama BARB-i poolt heaks kiidetud spetsifikatsiooni 0.9 / CR ja esitlust BoD-le, mis peab sisaldama järgmist:

• Kõik teadaolevad taotlused IOP-testimisest loobumiseks või mis tahes punktis 4.3.1 määratletud nõue
• Loetelu spetsifikatsiooniga toetatud vedudest (nt BR / EDR, LE jne)
• Spetsifikatsiooni täiustamiseks tagurpidi ühilduvuse nõuetest (kirjeldatud punktis 3.3.2) erandeid, mida töörühm nõuab
• Spetsifikatsiooni täiustamiseks peab töörühma soovitus versiooninumbrit rakendama vastuvõetud spetsifikatsioonile
• Spetsifikatsiooni täiustamiseks on töörühma soovitus vastuvõetud spetsifikatsiooni eelmise (te) versiooni (de) kohta kasutusea lõpul, sealhulgas tehnilised põhjused, miks spetsifikatsiooni mis tahes eelmise versiooni tühistamine või tühistamine on soovitatav või mitte, ning põhjendus soovituse saamiseks
• Kõik BARBi või STI liikmete lahendamata tõsised probleemid (nt põhjused, miks heakskiitmise ajal ei antud hääli,view testdokumentidest või on mures, et spetsifikatsioon 0.9/CR ei kuulu FRD või harta reguleerimisalasse)
• Pro ettevalmistamise staatusfile Tuning Suite (PTS) või muud vajalikud adopteerimisega seotud tööriistad, mille on koostanud BSTS

Enne kui STI kinnitab 0.9 / CR testidokumendid ja enne kui töörühm kinnitab, et IOP testimiskava vastab punktis 2 määratletud nõuetele, võib juhatus otsustada kinnitada IOP testimise spetsifikatsiooni IOP testimiseks vastavalt põhimäärusele [0.9]. 4.3.1. Samuti võib juhatus nõuda, et IOP testimiseks kinnitataks 0.9 / CR spetsifikatsioon, kui STI kinnitab 0.9 / CR testidokumendid.

0.9/CR Stage väljumisnõuded
0.9/CR Stage on lõppenud ja valideerimisfaas algab siis, kui BoD kiidab IOP testimise alguse.

4.4 Spetsifikatsioonide väljatöötamise protsessist loobumine

Töörühm võib paluda loobuda ühest või mitmest järgmisest protsessietapist:

• 0.5/DIPD Stage
• 0.7/FIPD Stage
• IOP testimine valideerimisfaasis

Loobumise taotlemiseks peab töörühm kasutama Bluetooth SIG -i [8] pakutavat protsessist loobumise malli ja esitama loobumistaotluse igale komisjonile (st BARB -le või STI -le), mis on kohustatudview või kinnitama spetsifikatsiooni eelnõu või sellega seotud testimisdokumendid aadressil stage et töörühm teeb ettepaneku loobuda ja kõik need komiteed peavad loobumistaotluse heaks kiitma.

Vabastustaotlus peab sisaldama järgmist:

• Tunnistus stage(d), millest töörühm soovib loobuda
• Põhjendus, miks stage(d) tuleks loobuda
• Iga komisjoni (st STI ja/või BARB) identifitseerimine, mida on vaja uuesti esitadaview ja nõustuge loobumistaotlusega

Vabanemist kaaluv komisjon võib nõuda, et töörühma esindaja esitaks SMPD-protsessist loobumise põhjenduseks ettekande enne loobumispalve üle otsustamist.

Kui loobumine taotleb mitmest etapist loobumist ja osa loobumisest lükatakse tagasi ja osa kiidetakse heaks, tuleb komisjoni vastuses näidata, millised loobumispalves olevad etapid kiideti heaks ja millised tagasi. Kui loobumisavaldus lükatakse tagasi, peab tagasilükkamisteatis sisaldama tagasilükkamise põhjuseid.

5. Valideerimise faas

Valideerimisetapis teostab töörühm 0.9/CR spetsifikatsiooni silmasisese rõhu testimist eesmärgiga esitada silindri katseprotokoll BARB re jaoksview ja heakskiit. Kui vähegi võimalik, tuleks spetsifikatsiooni täiustuste silmasisese rõhu testimist läbi viia integreeritud spetsifikatsiooni eelnõuga. Lisaks liige Review, nagu nõuab põhikiri [2], algab selles faasis.

Kui spetsifikatsioon (või täiustus) ei nõua IOP-testimist, võib IOP-testimisest valideerimisfaasis loobuda, kasutades jaotises 4.4 kirjeldatud protsessi.

IOP -i testimise käigus (mis võib olla üks või mitu sündmust) peaks töörühm jälgima probleeme, kasutades Bluetooth SIG -i probleemide jälgimissüsteemi, ja kordama, et lisada spetsifikatsiooni mustandi, testdokumentide ja IOP -testplaani värskendused. Kui silmasisese rõhu testimine on lõppenud, peab töörühm viima lõpule spetsifikatsiooni projekti ja katsedokumentide värskendused, et lahendada kõik probleemid, ning koostama ja esitama IAR -i testiaruande BARBile uuestiview ja heakskiit. Seda illustreerib joonis 5.1.

Valideerimisfaasis võib alata mitu tegevust. Need tegevused võivad toimuda paralleelselt ja hõlmata järgmist:

• BoD poolt heaks kiidetud 0.9/CR spetsifikatsioon on BSTS poolt kõigile liikmetele kättesaadav, teatades liikmestaatuse algusestview põhikirjas nõutud periood.
• Kõik vajalikud värskendused lisatakse CSS-i (mis võib olla kinnitatud spetsifikatsiooni lühendatud CR-i).
• Iseloomulikud või kirjeldavad definitsioonid on integreeritud GSS spetsifikatsiooni ja PTS-i IOP-testimiseks.
• Võrgusilma omaduste definitsioonid on integreeritud nii MDP spetsifikatsiooni kui ka PTS-i IOP-testimiseks.
• BSTS võimaldab IOP-platvormi registreerimist ja tulemuste sisestamise tööriista, et valmistuda IOP-testimiseks.
• IOP testimine, kui see on vajalik (vt punkt 5.1).
• Review kommentaare ja probleeme, sealhulgas silmasisese rõhu testimise tulemusena esitatud küsimusi, töödeldakse ja muudatused lisatakse spetsifikatsiooni eelnõusse.

5.1 IOP testimine

Silmasisese rõhu testimise esmane eesmärk on spetsifikatsiooni valideerimine, ntample, kontrollides teksti täpsust ja ebaselgust, reviewpõhiliste projekteerimisvigade ja väljajätmiste eest ning kinnituse andmise spetsifikatsiooni väljatöötamise käigus varem välja töötatud nõuetele. Silmasisese rõhu testimine võib muuta spetsifikatsiooni mustandit ja kõigi nõutavate testide lõpuleviimiseks võib osutuda vajalikuks mitu IOP -testi sündmust.

Oluline on anda WG -välistele liikmetele võimalus osaleda silmasisese rõhu testimisel, sest nad pakuvad sõltumatut view spetsifikatsiooni ja võib paljastada spetsifikatsioonis ebaselgust, mis ei pruugi olla eelnõu välja töötanud töörühma liikmetele ilmne. Enne igat IOP testisündmust teeb BSTS kättesaadavaks sündmuse üksikasjad, viimase mustandi spetsifikatsiooni, Test Suite'i ja IOP testplaani ning teavitab kõiki liikmeid ideaalis üks kuu enne iga sündmust. Uuendatud mustandi spetsifikatsioon, testikomplekt ja silmasisese rõhu testplaan, mida kasutatakse silmasisese rõhu testimisüritusel, peaks olema saadaval vähemalt nädal enne iga sündmust.

IOP-testimise ajal proovivad platvormide paariskombinatsioonid teste läbi viia ja IOP-testimisel osalejad registreerivad iga katse edukate / ebaõnnestunud tulemused ja kommentaarid. Nende tulemuste anonüümne kokkuvõte (viidates nt platvormile A, platvormile B jne) ja kõik kommentaarid kogutakse IOP-testi sündmuste ajal ja tehakse töörühma liikmetele kättesaadavaks IOP-i ajal ja pärast seda. testüritus. Juhul kui IOP-testimise käigus tekkinud kommentaaride või rikete paremaks mõistmiseks on vaja lisateavet, võib BSTS tegutseda vahendajana, et koguda esitaja liikmelt täiendavat teavet.

Võimaluse korral tuleks PTS-i uuendada, et toetada IOP-testimist platvormidega kõigil hostikontrolleri liidese (HCI) kohal asuvatel kihtidel ja olla kohal nende kihtide IOP-testi üritustel. IOP-testi üritustel võivad olla ka muud testimisvahendid. IOP-testi aruandesse tuleks lisada kokkuvõte PTS-i või muude testimisvahenditega (kui neid on) testimise tulemustest.

IOP-testimine on avatud kõigile liikmetele, kes soovivad prototüübi juurutamist pakkuda, kuid Bluetooth SIG võib osalemise tingimuseks seada Bluetooth SIG-ga sõlmitud lepingute (sealhulgas osalemis- ja konfidentsiaalsuslepingud) vastuvõtmise. Töörühm vastutab IOP-testimise käigus avastatud probleemide töötlemise ja lahendamise ning mõjutatud dokumentide ajakohastamise eest; WG-ga heaks kiidetud muudatused tuleb lisada spetsifikatsiooni ja testdokumentide eelnõude värskendustena, et neid saaks kasutada igal IOP-testi üritusel.

Enne valideerimisfaasi võivad töörühmad teha esialgseid IOP-teste sündmustel, mis on avatud ainult töörühma liikmetele, kuid mitteametliku testimise tulemusi ei tohi IOP-testi tulemuste hulka lisada.

Võib juhtuda, et järgitakse kõiki samme, mis viivad esimese IOP-testi sündmuseni, sealhulgas väljakuulutatud IOP-i kuupäeva ja asukohta, pidades silmas IOP-testimise alustamist, kuid BoD kinnitust ei olnud enne testisündmuse algust veel tagatud. Sellisel juhul võib BoD lubada lisada testitulemusi, mis koguti enne BoD heakskiitu IOP testimise alustamiseks, tingimusel et kogutud tulemused põhinesid samadel spetsifikatsioonidel ja BoD poolt heaks kiidetud Test Suite'il.

CSS-, GSS- või MDP-spetsifikatsioonide täiustamiseks ei ole vaja IOP-testi teha.

IOP-testi aruanne
Pärast silmasisese rõhu testimist peab töörühm esitama BARB -le IOP katsearuande eesmärgiga näidata, et nõutav arv sõltumatuid platvorme on nõutud testid läbinud. BARB peab uuestiview ning kiita heaks või lükata tagasi IOP testi aruanne ning teavitab töörühma, kui enne hääletusprojekti spetsifikatsioonipaketi BoD -le esitamist on vaja täiendavat IOP -testi. BSTS ja töörühm peavad enne aruande BARB-le esitamist tagama, et IOP-testi aruandes ei kuvataks liikmeid tuvastavat teavet.

IOP-testi aruanne peab sisaldama järgmist:

• Kõigi kontrollimisfaasis aset leidnud IOP-testi sündmuste loetelu, sealhulgas nende kuupäevad ja asukohad.
• IOP üritusel osalenud liikmesettevõtete ja sõltumatute platvormide arv, sealhulgas PTS-i kasutamine.
• Igal üritusel kasutatavate spetsifikatsioonide, Test Suite'i ja IOP testplaani versioonide loend.
• Kommenteeritud kokkuvõte, milles märgitakse, kas kõik testijuhud vastasid miinimumtestimise kriteeriumidele.
• Kokkuvõte punktis 4.3.1 määratletud IOP katseplaani nõuetest tulenevate erinevuste kohta ja iga dispersiooni põhjendus.
• Test Suite'i testijuhtumite PTS-leviala kokkuvõte.
• Kõigi kontrolljuhtumite loend (sh ühilduvuskatsed tagasiulatuvalt) IOP katseplaanist, läbitud katsete arv, testide ebaõnnestumiste arv ja see, kas ühe juhtumi kohta on täidetud miinimumkriteeriumid, sealhulgas selgitus, miks nõudeid ei täidetud kohtusime.
• Kokkuvõte probleemidest, kommentaaridest ja küsimustest igal üritusel (sh need filed) spetsiifika vastu IOP -testimise ajal) ning mõju spetsifikatsioonile ja katsedokumentidele.

5.2 Valideerimise faasist väljumise nõuded

Valideerimisfaas on lõppenud ja kinnitamis- / vastuvõtmisetapp algab siis, kui BARB on kinnitanud IOP-i katsearuande (kui BARB ei loobunud testimisest) ja kui kõik järgmised nõuded on täidetud:

• BSTS on teinud heakskiidetud 0.9/CR spetsifikatsiooni kõigile liikmetele kättesaadavaksview nagu põhikiri nõuab ja teavitas kõiki liikmeid selle kättesaadavusest.
• Kõik IOP-testimisel tuvastatud probleemid, millel on testimõju, on integreeritud ja testitud.
• WG on lõpetanud IOP-testimise (kui BARB ei loobunud testimisest).

 

6. Vastuvõtmise / kinnitamise etapp

Vastuvõtmise/heakskiitmise etapis viimistletakse spetsifikatsioon ja sellega seotud katsedokumendid, saadakse BARB, BQRB ja STI heakskiit, väljastatakse teade kavandatud vastuvõtmiskuupäeva kohta koos spetsifikatsiooni eelnõu lõpliku versiooniga, mis esitatakse BoD -le vastuvõtmiseks ( Hääletusprojekt) ja lõplik spetsifikatsioonipakett esitatakse BoD -le. Pärast liikme Re minimaalset kestustview põhikirjaga nõutud [2]), kaalub BoD spetsifikatsiooni vastuvõtmiseks vastuvõtmise kuupäeval. Pärast vastuvõtmist spetsifikatsioon avaldatakse ja kvalifikatsioonisüsteem lubatakse. Vastuvõtmise/heakskiitmise etapp on näidatud joonisel 6.1.

6.1 Hääletuse eelnõu

Hääletuse mustand luuakse värskenduste (mis on kinnitatud valideerimise etapis) lisamisega nõutavatesse spetsifikatsioonidokumentidesse ja uue spetsifikatsiooni lõpliku mustandi ettevalmistamiseks. Spetsifikatsiooni täiustuste jaoks loob BSTS integreeritud spetsifikatsiooni, integreerides ühe või mitu CR-i spetsifikatsiooni varem vastuvõetud kõrgemasse versiooni (vt jaotist 4.3.2), kui see pole enne valideerimise faasi veel lõpule viidud.

Kui selle etapi jooksul tehakse spetsifikatsiooni muudatusi ja WG, BARB või BTI tuvastab, et mis tahes muudatus nõuab täiendavat IOP-testimist, naaseb spetsifikatsioon WG-le täiendavate testide tegemiseks valideerimisfaasi IOP-testimise ossa. Vastuvõtmise / kinnitamise etapis täidetakse järgmised dokumendid ja tehakse juhatusele kättesaadavaks enne vastuvõtmise kuupäeva:

• Hääletuse eelnõu
• Kõik toetavad spetsifikatsioonid (st CSS, GSS, MDP), mis on vajalik vastava spetsifikatsiooni (või täiustuse) tüübi jaoks, kui neid pole varem vastu võetud
• Spetsifikatsiooni täiustuste jaoks on vastuvõetud spetsifikatsiooni versiooni muudatustega jälgitav versioon, mis näitab hääletuse eelnõus kavandatud muudatusi
• Töörühma kirjeldus kõigi tagasiulatuvate ühilduvusnõuete kohta (nagu kirjeldatud punktis 3.3.2), mis ei ole täidetud, ja võimalike erandite põhjendus
• Töörühma kirjeldus mis tahes IOP katsekava nõuete kohta (mida on kirjeldatud punktis 4.3.1), mida ei ole täidetud, ja põhjendused kõrvalekallete kohta koos IOP katsearuandega (mille võib esitada, lisades lingi koopiale Bluetooth SIG websait)
• Töörühma soovitus vastuvõetud spetsifikatsiooni mis tahes varasema(te) versiooni aegumise või tühistamise kohta koos põhjendusega, mis tõstab esile muudatusi alates 0.9/CR Stage kasutusaja lõpu soovitus
• Töörühma koostatud kokkuvõte funktsioonide või funktsionaalsuse muudatustest alates 0.9 / CR spetsifikatsioonist (kui on)
• BARBi koostatud kokkuvõte BARBi liikmete tõstatatud murest, et töörühma koostatud spetsifikatsioon ei kuulu juhatuse poolt heaks kiidetud harta reguleerimisalasse (kui see on olemas)
• Loetelu lahendamata juriidilistest küsimustest juriidilisest review (kui on)
• STI poolt heaks kiidetud testikomplekt koos WG poolt heaks kiidetud kokkuvõttega hääletuse projekti spetsifikatsiooni testide ulatusest. Äsja lisatud või muudetud funktsionaalsuse korral, mis ei hõlma testimist, on vaja väljajätmist kirjalikult põhjendada
• STI poolt heaks kiidetud ICS ja IXIT (kui spetsifikatsioon seda nõuab)
• Nii STI kui ka BQRB poolt heaks kiidetud TCRL
• BSTSi koostatud aruanne koos STI-ga tööriistade valmisoleku oleku kohta (nt PTS ja muud testimisvahendid, Bluetooth Launch Studio), sealhulgas kui TCRL-i testimisjuhud ei toeta testimisvahendeid
• Töörühma koostatud kokkuvõte kõikidest vajalikest numbritest
• BSTSi ja töörühma koostatud lapsendamise kontroll-loend näitab, et kõik selles jaotises olevad tulemused on lõpule viidud
• Kogu muu ameti poolt nõutav teave

Vastuvõtmise / kinnitamise etapis peaks töörühm kasutama Bluetooth SIG-i probleemide jälgimise süsteemi, et spetsifikatsiooni eelnõule ja testdokumentidele vastavaid probleeme ja kommentaare jäädvustada, nii et neid arvestataks hääletusprojekti spetsifikatsiooni lõpuleviimisel. Spetsifikatsiooni täiustamiseks tuleb lisada kõik asjakohased heakskiidetud vead (st need, mis on heaks kiidetud, veel integreerimata) ja need tuleb tuvastada jälgitavate muudatuste abil.

Töörühm peab esitama spetsifikatsiooni lõpliku projekti BSTS -ile juriidiliseks läbivaatamiseksview. Uute spetsifikatsioonide puhul on õiguslik review sisaldab kogu spetsifikatsiooni. Spetsifikatsiooni täiustamiseks vaadake review keskendub peamiselt spetsifikatsiooni muudetud osadele. Eesmärk õiguslik review on eelkõige tuvastada juriidilised riskid, mida töörühm peaks kaaluma ja lahendama. Õiguslik tagasiside liigitatakse raskusastme järgi. Kui valikuline juriidiline review viidi läbi 0.9/CR S juurestage, versioon, mis esitatakse juriidiliseks asjaksview peab jälgitavate muudatustena näitama kõiki muudatusi, mis on tehtud pärast seda versiooni (loodud kas WG või BSTS). Pärast juriidilise korra lõpetamistview, WG ja BSTS lepivad kokku tagasisides, mis lisatakse spetsifikatsiooni eelnõusse. Kui juriidilisest re -ist on lahendamata juriidilisi märkusiview spetsifikatsiooni eelnõu osas võib töörühma esimees nõuda ajakava päevakorras aega kokkuleppele jõudmiseks.

Paralleelselt juriidilise review, peab töörühm esitama spetsifikatsiooni projekti BARB -le uuestiview. Pärast esmakordset esitamist BARB -le teavitab BSTS kõiki liikmeid, et spetsifikatsiooni eelnõu on BARB -le uuesti esitamiseks esitatudview ja et see on saadaval ka liikmele Review. Kui töörühm esitab BARB re-re spetsifikatsiooni eelnõu uuendusedview, BSTS saadab perioodiliselt kõigile liikmetele lisateateid.

Pärast BARB review, WG ja BARB lepivad kokku spetsifikatsiooni eelnõusse lisatava tagasiside osas.

Kui seaduslik review tulemuseks on sisulised muudatused, täiendavad review võib nõuda BARB. Samamoodi, kui BARB review mis toob kaasa olulisi muudatusi, otsustab BSTS, kas täiendav õiguslik review neist muudatustest on vajalik. Pärast juriidilise korra lõpetamistview ja BARB review, BARB peab kas hääletusprojekti heaks kiitma või tagasi lükkama.

Kui mõni testdokument vajab uuendamist, aitab BSTS töörühma testdokumentide värskendamisel. STI peab katsedokumendid kas heaks kiitma või tagasi lükkama. Kui STI on selle heaks kiitnud, aitab STI TCRL-i vormistamisel ja toimetab selle dokumendi koos sellega seotud ICS-i, IXIT-i ja Test Suite'iga BQRB-le. BSTS hindab juhatuse koosoleku kuupäeva, millal juhatus kavatseb hääletada hääletuse eelnõu vastuvõtmise üle (vastuvõtmise kuupäev), ja esitab selle STI kasutamiseks TCRL-is. Spetsifikatsiooni BARB-i kinnitamine, kõigi testdokumentide (sealhulgas Test Suite, TCRL, ICS ja IXIT) STI-heakskiit ja TCRL-i BQRB-kinnitamine peavad toimuma vastuvõtmiskuupäeval või enne seda.

BSTS teavitab kõiki liikmeid hääletusprojekti valmimisest ja kättesaadavusest ning vastuvõtmise kuupäevast. Vastuvõtmise kuupäev määratakse mitte varem kui 60 päeva pärast seda, kui liikmetele teatati BoD-heakskiidetud 0.9/CR spetsifikatsioonist, välja arvatud juhul, kui liigeview tähtaega lühendab BD vastavalt põhikirjale ja vähemalt 14 päeva pärast vastuvõtmise kuupäeva teatamist antakse liikmetele vastavalt põhikirjale. Juhtude puhul, kui hääletusprojekti on integreeritud mitu krediidiasutust, tuleb alustada liikmest Review on kuupäev, mil liikmetele teatati viimasest BoD poolt heaks kiidetud CR-st.

Kui liikmetele on teatatud vastuvõtmiskuupäevast, on hääletuse eelnõus lubatud trükivigade parandused juhatuse heakskiidul. Spetsifikatsiooni vastuvõtmise ajaskaala on illustreeritud joonisel 6.2.

6.2 Määratud numbrid

Bluetooth SIG säilitab avalikult kättesaadava määratud numbrite komplekti Bluetooth SIG -i määratud numbritele websait [7]. Need määratud numbrid on rühmitatud erinevatesse numbriruumidesse (seotud numbrite komplekt ilma duplikaatideta). Määratud numbrid võivad kattuda teiste numbriruumides olevate numbritega, kuid ühtegi numbriruumi kuuluvat numbrit ei ole lubatud uuesti kasutada. Erinevad numbriruumid on määratletud spetsifikatsioonis, mis määratleb määratud numbrite kasutamise.

Pärast seda, kui BARB kinnitab IOP katsearuande, esitab töörühm BARB -le taotluse uute numbrite määramiseks lõplikus spetsifikatsioonis nõutud numbriruumi (de) piires. BARB hakkab review päring ja tööta koos BSTS -iga määratud numbrite määramiseks. Pärast BARB -i heakskiitu ajastab BSTS määratud numbrite avaldamise avalikult kättesaadavaks Bluetooth SIG -i määratud numbritele websaidil [7] ühe nädala jooksul pärast spetsifikatsiooni vastuvõtmist.

Pärast avaldamist määratud numbrid Bluetooth SIG määratud numbrid websaidil või vastuvõetud spetsifikatsioonides, on määratud numbrid muutumatud (mitte muutuma väärtuses ega tähenduses). Kui need muutuvad mingil põhjusel kasutuskõlbmatuks, muutuvad need reserveeritud väärtusteks ja neid ei tohi uuesti kasutada.

6.3 Vastuvõtmise / kinnitamise etapist väljumise nõuded

Kinnitamis- / vastuvõtmisetapp on lõppenud, kui juhatus on spetsifikatsiooni vastu võtnud ja järgmised vastuvõtmisjärgsed toimingud on lõpule viidud:

• BSTS on teinud viimased määratud numbrid Bluetooth SIG -is avalikult kättesaadavaks websaidile.
• BSTS tegi vastuvõetud spetsifikatsiooni Bluetooth SIG -is avalikult kättesaadavaks websaidile
• BSTS on teinud kõik asjakohaste spetsifikatsioonide jaoks vajalikud tõendavad dokumendid (nt CSS, GSS, MDP) Bluetooth SIG -is avalikult kättesaadavaks websaidile.
• BSTS on teinud seotud testidokumendid kõigile Bluetooth SIG -i liikmetele kättesaadavaks websaidile.
• Spetsifikatsioonide täiustamiseks on BSTS teinud varem vastu võetud spetsifikatsiooni versiooni informatiivse muudatuste jälgimise versiooni koos kõigi äsja vastu võetud versiooni muudatustega ja teinud selle kättesaadavaks kõigile Bluetooth SIG-i liikmetele websaidile.
• BSTS on lubanud kvalifikatsioonisüsteemi.
• BSTS on teavitanud kõiki liikmeid vastuvõetud spetsifikatsiooni ja kõigi täiendavate dokumentide olemasolust.

Bluetooth SIG kavatseb need pärast vastuvõtmist ühe nädala jooksul pärast spetsifikatsiooni vastuvõtmist lõpule viia.

 

7. Spetsifikatsiooni hooldusetapp

Spetsifikatsiooni hoolduse etapp algab pärast vastuvõtmise / kinnitamise etapi lõppu. Kui spetsifikatsiooni või sellega seotud testdokumentidega leitakse probleeme (nt sõnastuse ebaselgust või tehnilisi vigu), tuleb need dokumenteerida, luues vigade ettepanekud, kasutades tööriista Bluetooth SIG Errata. Spetsifikatsioonide vigaseid ettepanekuid töödeldakse, liigitatakse kategooriatesse ja kinnitatakse vastavalt EPD-le [3]. Test Suite erratumit töödeldakse ja kategoriseeritakse vastavalt TSTO-le [5]. Kui SMPD ja EPD või TSTO vahel on konflikte, on SMPD ülimuslik.

Spetsifikatsiooni viga võib kasutada ainult lõplike vastuvõetud Bluetoothi ​​spetsifikatsioonide tehniliste või redigeerimisvigade parandamiseks. Funktsioonide lisamine, muutmine ja eemaldamine on võimalik ainult käesolevas dokumendis varem määratletud spetsifikatsiooni täiustamise protsessi abil.

7.1 Kiirendatud valeprotsess

Kui viga on heaks kiidetud EPD -s [3] määratletud protsessi järgides, võib WG, BARB või BSTS soovitada seda kiireloomuliseks pidada ja kiirendada. Kui see juhtub, esitab BSTS koos WG või BARB soovitusega BoD -le. Juhatus otsustab soovituse vastu võtta või tagasi lükata. Kui soovitus vastu võetakse, lisab BSTS kohe heakskiidetud eksimuse vigade malli [8] ja töötab koos vastutava töörühmaga, et viia lõpule kiirendatud vigade parandus, mis esitatakse töörühmale uuestiview ja heakskiit.

Üleview kiirendatud eksimisprotsessi on illustreeritud joonisel 7.1.

Enne vastuvõtmise kuupäeva tuleb täitedokumendile täita ja teha kättesaadavaks järgmised dokumendid:

• BARBi heakskiidetud mustand Expedited Errata Correction.
• Töörühma kirjeldus kõigi tagasiulatuvate ühilduvusnõuete kohta (nagu on kirjeldatud jaotises 3.3.2), mis ei ole täidetud, ja võimalike erandite põhjendused.
• Loetelu lahendamata juriidilistest küsimustest juriidilisest review (kui on).
• STI poolt heaks kiidetud Test Suite, ICS ja IXIT (kui erratum seda nõuab).
• STI ja BQRB poolt heaks kiidetud TCRL (kui erratum seda nõuab).
• BSTSi koos STI-ga täidetud aruanne tööriistade valmisoleku oleku kohta (nt PTS ja muud testimisvahendid, Bluetooth Launch Studio), sealhulgas see, kas TCRL-i ühtegi testimisjuhtu ei toeta testimisvahendid ja selgitus (kui erratum seda nõuab ).
• BSTS ja töörühm on täitnud lapsendamise kontroll-loendi, mis näitab, et selles jaotises olevad tulemused on kõik lõpule viidud.
• Kogu muu ameti poolt nõutav teave.

BSTS teeb koostööd vastutava töörühmaga, et viia lõpule kiirendatud vigade parandamise eelnõu ja luua versioon, mis esitatakse vastutavale töörühmale uuestiview ja heakskiit.

Töörühm peab esitama kiirendatud vigade paranduse BSTS -ile juriidiliseks läbivaatamiseksview. Pärast juriidilise korra lõpetamistview, WG ja BSTS lepivad kokku tagasisides, mis lisatakse kiirendatud vigade parandusse. Kui juriidilisest re -ist on lahendamata juriidilisi märkusiview kiirendatud vigade paranduse osas võib töörühma esimees nõuda aega BoD päevakorras, et küsida BoD panust kriisilahendusse.

Paralleelselt juriidilise review, peab WG esitama BARB -le uuesti kiirendatud vigade paranduseview. Kui kiirendatud vigade parandus on BARBile esitatud, teeb BSTS selle kõigile liikmetele uuesti kättesaadavaksview ja teavitama kõiki liikmeid selle kättesaadavusest. Pärast BARB review, WG ja BARB lepivad kokku tagasisides, mis lisatakse kiirendatud vigade parandusse.

Kui seaduslik review tulemuseks on sisulised muudatused, täiendavad review võib nõuda BARB. Samamoodi, kui BARB review mis toob kaasa olulisi muudatusi, otsustab BSTS, kas täiendav õiguslik review neist muudatustest on vajalik. Pärast juriidilise korra lõpetamistview ja BARB review, BARB peab kiirkorras paranduse heaks kiitma või tagasi lükkama.

Kui mõni testdokument vajab uuendamist, aitab BSTS töörühma testdokumentide värskendamisel. Testdokumentide STI kinnitamisel aitab STI TCRL-i lõpule viia ja toimetab dokumendi BQRB-le koos asjakohaste ICS-i, IXIT-i ja Test Suite'iga. BSTS hindab vastuvõtmiskuupäeva ja edastab selle STI-le kasutamiseks TCRL-is. Kiirendatud vigade paranduse BARB-i heakskiit, kõigi testdokumentide (sealhulgas vajaduse korral ka Test Suite, TCRL, ICS ja IXIT) STI-heakskiit ja TCRL-i BQRB-kinnitus peavad toimuma vastuvõtmiskuupäeval või enne seda.

BSTS teavitab kõiki liikmeid kiirendatud vigade paranduse vormistamisest ja kättesaadavusest ning kavandatavast vastuvõtmiskuupäevast. Vastuvõtukuupäev määratakse ja sellest teatatakse kõigile liikmetele vastavalt põhimäärusele [2] ning vastuvõtmise kuupäev peab olema vähemalt 14 päeva pärast teate edastamist liikmetele. Pärast seda, kui liikmetele on teatatud kavandatavast vastuvõtmiskuupäevast, võib juhatus heaks kiita kiirendatud vigade paranduse trükivigade parandused, ilma et peaksite kavandatava vastuvõtmiskuupäeva kohta lisateavet esitama ja nõutavat 14 päeva ootama.

Bluetooth SIG teeb vastuvõetud kiirendatud vigade paranduse üldsusele kättesaadavaks ja kavatseb seda teha ühe nädala jooksul pärast vastuvõtmist. BSTS annab kõigile liikmetele teada selle kättesaadavuse kohta.

Kiirendatud tühistamisprotsess on lõppenud, kui juhatus on vastu võtnud kiirendatud vigade paranduse ja järgmised vastuvõtmisjärgsed toimingud on lõpule viidud:

• BSTS tegi vastuvõetud kiirendatud vigade paranduse ja sellega seotud testidokumendid (kui viga nõuab) Bluetooth SIG -is avalikult kättesaadavaks websaidile.
• BSTS on lubanud kvalifitseerimissüsteemi (kui erratum seda nõuab).
• BSTS on teavitanud kõiki liikmeid vastuvõetud kiirendatud vigade paranduse kättesaadavusest.

Nende toimingute lõpuleviimisel kavandatakse vigade parandus integreerida mõjutatud spetsifikatsioonidesse kas kavandatava spetsifikatsiooni täiustamise osana või eelseisva hooldusteatise kohaselt, nagu on kirjeldatud jaotises 7.2.

7.2 Hoolduse vabastamise protsess (.Z spetsifikatsioonid)

Ligikaudu igal aastal teeb BSTS kindlaks, kas on olemas heakskiidetud vigu (viidatud vigade parandustele), mis on liigitatud tehniliseks / kõrgeks või tehniliseks / kriitiliseks ja mis tuleb veel lisada mis tahes aktiivse spetsifikatsiooni teksti (st vastuvõetud spetsifikatsioon, mida pole amortiseerunud ega tagasi võetud). Vigade klassifikatsiooni määratlused leiate lisast A. Spetsifikatsiooni omanik (kas spetsifikatsiooni säilitamiseks prahitud WG või BARB, kui spetsifikatsiooni säilitamiseks ei ole prahitud ühtegi WG-d) võib taotleda ka aktiivse spetsifikatsiooni varasemat hooldusväljaannet, kuhu lisada kõik heakskiidetud vead. Kas BSTS-i määramisel või spetsifikatsiooni omaniku taotlusel algab hoolduse vabastamise protsess.

Üleview hoolduse vabastamise protsessi on illustreeritud jaotises Viga! Viiteallikat ei leitud.

Hoolduse väljaandmise protsessi alguses töötavad BSTS koos spetsifikatsiooni omaniku, BARBi ja BTI-ga välja ja esitavad juhatusele plaani, kuidas lisada vigade parandused avaldatud spetsifikatsiooni versiooni. Kavandatud plaan peab näitama, kas Errata Corrections lisatakse spetsifikatsiooni hooldusväljaandesse (st .Z versioon) või juba pooleliolevasse spetsifikatsiooni täiendusse (st XY versioon). Kavandatavas plaanis tuleks arvestada, kas vastuvõetud spetsifikatsioonide versioonide vahel on lisatud uusi kohustuslikke funktsioone, eeldatavat aega, millal järgmine spetsifikatsiooni täiustamine on kavandatud vastuvõtmiseks, ja muid tegureid.

BoD poolt plaani heakskiitmisel lisab BSTS koos spetsifikatsiooni omanikuga kõik tehnilised / keskmised, tehnilised / kõrged ja tehnilised / kriitilised vigade parandused spetsifikatsiooni eelnõusse, mida nimetatakse hoolduse väljalaskeprojektiks. Toimetuslike või tehniliste / madalate vigade paranduste korral integreerib BSTS need vead selle versiooni järgmisel värskendusel ainult viimasesse kõrgema spetsifikatsiooni versiooni, kui vigade parandus kehtib mitmele spetsifikatsiooni versioonile. . Hoolduse väljalaske mustandisse ei tohi lisada muudatusi, välja arvatud Errata parandused. Iga hoolduse väljalaske mustand peab tuvastama kõik lisatud vigade parandused, kasutades muudatuste jälgimist, et näidata avaldatud spetsifikatsiooni varem vastuvõetud versiooni kavandatud muudatusi.

Hoolduse väljalaske mustri iga vigade paranduse kavandatava lisamise aeg sõltub Test Suite'i mõjust: kõik vigade parandused, millel puudub Test Suite mõju, võidakse kohe lisada, kuid Test Suite'i mõjutavad vigade parandused lisatakse kohe töödeldakse nii, et ajastus langeks kokku TCRL-i värskendusega.

STI ja BSTS määravad tähtaja test Suite'i mõjuga vigade paranduste lisamiseks hoolduse väljalaske mustandisse. See tähtaeg on tavaliselt 3–6 kuud enne järgmise olulise TCRL-i väljaande kavandatud kinnitamise kuupäeva. Test Suite'i mõjuga vigade parandused, mis jäävad lisamise tähtajast mööda, töödeldakse järgmise TCRL-i aastase väljalaske osana. Seega, kui varasemat versiooni ei taotleta, on tehniliste / kõrgete või tehniliste / kriitiliste vigade paranduste maksimaalne aeg spetsifikatsiooni värskendusse lisamiseks umbes 15–18 kuud.

Spetsifikatsiooni omanik peab seaduslikuks uuesti esitamiseks esitama lõpliku heakskiidetud hooldustõendiview. Juriidiline review keskendub peamiselt spetsifikatsiooni muudetud osadele. Pärast juriidilise korra lõpetamistview, spetsifikatsiooni omanik ja BSTS lepivad kokku tagasisides, mis lisatakse hoolduse vabastamise eelnõusse. Kui juriidilisest re -ist on lahendamata juriidilisi märkusiview hoolduse väljalaske eelnõu kohta võib spetsifikatsiooni omanik nõuda BoD päevakorral aega, et otsida BoD sisendit lahenduse leidmiseks.

Paralleelselt juriidilise review, peab spetsifikatsiooni omanik esitama hooldustõendi eelnõu BARBile uuestiview. Kui hooldustõendi eelnõu on BARBile esitatud, teeb BSTS selle kõigile liikmetele uuesti kättesaadavaksview ja teavitama kõiki liikmeid selle kättesaadavusest. Pärast BARB review, spetsifikatsiooni omanik ja BARB lepivad kokku spetsifikatsiooni eelnõusse lisatava tagasiside osas.

Kui seaduslik review tulemuseks on sisulised muudatused, täiendavad review võib nõuda BARB. Samamoodi, kui BARB review mis toob kaasa olulisi muudatusi, otsustab BSTS, kas täiendav õiguslik review neist muudatustest on vajalik. Pärast juriidilise korra lõpetamistview ja BARB review, BARB peab hoolduse vabastamise eelnõu kas heaks kiitma või tagasi lükkama. Kui BARB selle heaks kiidab, muutub see hääletusprojektiks.

Vigade paranduste puhul, mis mõjutavad testidokumente, ja kui vastavad testide vead töödeldakse õigeaegselt enne TCRLi eelseisvat versiooni, töötab BSTS koos spetsifikatsiooni omaniku ja STT-ga testdokumentide värskendamiseks. Testdokumentide STI kinnitamisel hindab BSTS vastuvõtmise kuupäeva ja edastab STI-le kasutamiseks kavandatud vastuvõtmiskuupäeva STI-le. STI edastab TCRL-i BQRB-le koos asjakohaste ICS-i, IXIT-i ja Test Suite'iga. Spetsifikatsiooni BARB-i heakskiitmine, kõigi testdokumentide (sealhulgas vajaduse korral Test Suite, TCRL, ICS ja IXIT) STI-heakskiit ja TCRL-i BQRB-kinnitus peavad toimuma vastuvõtmiskuupäeval või enne seda.

BSTS teavitab kõiki liikmeid hääletuse eelnõu vormistamisest ja kättesaadavusest ning kavandatavast vastuvõtmise kuupäevast. Vastuvõtukuupäev määratakse ja sellest teatatakse kõigile liikmetele vastavalt põhimäärusele ning vastuvõtmise kuupäev peab olema vähemalt 14 päeva pärast teate teatamist liikmetele. Pärast seda, kui liikmetele on teatatud kavandatavast vastuvõtmiskuupäevast, võib juhatus heaks kiita hääletusprojekti trükivigade parandused, lisateavet kavandatava vastuvõtmiskuupäeva kohta esitamata ja nõutavat 14 päeva ootamata.

Enne vastuvõtmise kuupäeva tuleb täitedokumendile täita ja teha kättesaadavaks järgmised dokumendid:

• Hääletuse eelnõu
• Hääletuse eelnõu muudatustega jälgitav versioon, mis näitab kõiki muudatusi spetsifikatsiooni vastuvõetud versioonis, millel on sama XY väärtus (nt kui hääletuse mustandit pakutakse versioonina 1.4.2, jälgitakse muudatusi 1.4.1 spetsifikatsiooni versioon)
• Spetsifikatsiooni omaniku soovitus vastuvõetud spetsifikatsiooni kõigi varasemate versioonide tühistamise või tühistamise kohta koos põhjendusega
• Loetelu lahendamata juriidilistest küsimustest juriidilisest review (kui on)
• STI-ga heaks kiidetud Test Suite, ICS ja IXIT (kui see on vajalik hooldusteates)
• STI ja BQRB poolt heaks kiidetud TCRL (kui see on vajalik hooldusteates)
• BSTSi koos STI-ga täidetud aruanne tööriistade valmisoleku oleku kohta (nt PTS ja muud testimisvahendid, Bluetooth Launch Studio), sealhulgas kõik TCRL-i testjuhtumid, mida testimisvahendid ei toeta, ja selgitus (kui hooldus seda nõuab) vabastamine)
• BSTS-i ja spetsifikatsiooni omaniku täidetud vastuvõtmise kontroll-loend näitab, et kõik selles jaotises olevad tulemused on lõpule viidud
• Kogu muu ameti poolt nõutav teave

Hoolduse vabastamise protsess on lõppenud, kui juhatus on hääletamise eelnõu vastu võtnud ja järgmised pärast vastuvõtmist toimingud on lõpule viidud:

• BSTS tegi vastuvõetud spetsifikatsiooni ja sellega seotud testidokumendid (kui hooldusväljaanne seda nõuab) Bluetooth SIG -is avalikult kättesaadavaks websaidile.
• BSTS on muutnud informatiivse muudatuste jälgimise versiooni varem vastu võetud spetsifikatsiooniversioonist koos kõigi muudatustega, mis on kaasatud äsja vastuvõetud versioonile, kõigile Bluetooth SIG-i liikmetele kättesaadavaks websaidile.
• BSTS on lubanud kvalifikatsioonisüsteemi.
• BSTS on teavitanud kõiki liikmeid vastuvõetud spetsifikatsiooni ja täiendavate dokumentide kättesaadavusest.

Bluetooth SIG kavatseb need pärast vastuvõtmist ühe nädala jooksul pärast spetsifikatsiooni vastuvõtmist lõpule viia.

Nende toimingute lõpuleviimisel jääb spetsifikatsioon spetsifikatsiooni hoolduse faasi seni, kuni spetsifikatsioon on aegunud või tagasi võetud, nagu on määratletud 8. jaos.

 

8. Spetsifikatsioon eluea lõpufaas

Spetsifikatsioonid võidakse kaotada või need tühistada, kui need asendatakse uuemate versioonidega, leitakse, et need on tehniliselt ebapiisavad, või muudel põhjustel. Katkestatud ja tühistatud spetsifikatsioonid arhiveeritakse ja neid ei värskendata enam. Katkestatud ja tühistatud spetsifikatsioone käsitletakse Bluetoothi ​​kvalifikatsiooniprogrammis erinevalt.

Iga liige, rühm või komitee võib BSTS-ile saata e-posti aadressil soovitused spetsifikatsiooni tühistamiseks või tühistamiseks koos sellega seotud ajaskaalaga

specification.manager@bluetooth.com) igal ajal. BSTS võib soovitada ka spetsifikatsiooni ja sellega seotud ajakava tühistamist või tühistamist. BSTS edastab soovituse BARBile ja spetsifikatsiooni säilitamise eest vastutavale rühmale või komiteeleview ja tagasisidet.

BARB ja vastutav rühm või komisjon hindavad soovitusi spetsifikatsiooni tühistamiseks või tühistamiseks ning kaaluvad järgmisi (mitteammendavaid) kriteeriume:

• Kas spetsifikatsiooni eelmises versioonis on vananenud funktsionaalsus või seda ei tohiks kasutada?
• Kas hilisematesse versioonidesse on lisatud uus kohustuslik funktsioon?
• Kas varasemates versioonides on puudusi, mis kahjustavad toimimist või koostalitlusvõimet, mis on hilisemates versioonides parandatud ja mida on vaja olemasolevate kasutajastsenaariumide edendamiseks?
• Kas uute stsenaariumide edendamiseks on hilisemates versioonides vaja täiendavat funktsionaalsust?
• Kas hilisemates versioonides on paranenud kasutatavus ja koostalitlusvõime?
• Kas hilisemates versioonides on turvalisuse parandusi?

BARB ja vastutav rühm või komisjon võivad pakkuda alternatiivset soovitust.

Pärast tagasiside saamist BARBilt või spetsifikatsiooni säilitamise eest vastutavalt rühmalt või komiteelt esitab BSTS soovituse (d) ja tagasiside BoD -le kaalumiseks. Juhatus võib kutsuda rühma või komitee, kes vastutab mõjutatud spetsifikatsioonide säilitamise eest, soovitustega kohtuma ja neid arutama. Juhatus arvestab soovitusi ja tagasisidet ning võib ettepanekuga nõustuda või seda muuta. BoD palub, et BSTS teavitaks kõiki liikmeid ettepanekutest tühistada või tühistada spetsifikatsioon (id) ja nendega seotud ajakava (d) 30 päeva jooksulview aega, et kõik liikmed saaksid enne lõpliku otsuse tegemist täiendavat tagasisidet anda.

Juhatus arvestab liikmetelt saadud tagasisidet. Kui juhatus kiidab heaks spetsifikatsiooni amortiseerimise või tühistamise, teavitab BSTS kõiki liikmeid otsusest ja sellega seotud ajakavast.

8.1 Amortisatsioon

Kui spetsifikatsioon on aegunud, toimub järgmine:

• Spetsifikatsiooni enam ei värskendata.
• Vastutav WG hakkab uuestiview kõik tasumata vead, mis on kirjutatud aegunud spetsifikatsiooni vastu, et teha kindlaks, kas need kehtivad muude spetsifikatsioonide suhtes. Vead võidakse vigade süsteemis tagasi lükata ja ümber kirjutada kohaldatavate spetsifikatsioonide alusel.
• Töörühm või BSTS loob vigade, et värskendada muid viiteid vananenud spetsifikatsioonidele teistes spetsifikatsioonides.
• STI ajakohastab kohaldatavaid katsedokumente, et näidata spetsifikatsiooni aegumist.
• BSTS värskendab Bluetooth SIG -i websaidil koos juhistega alternatiivsete spetsifikatsioonide kohta.
• Uut viga ei saa enam esitada vananenud spetsifikatsiooni vastu.
• Spetsifikatsioonile ei viidata tulevikus.
• BSTS arhiveerib spetsifikatsiooni versiooni, mis on liikmetele ajaloolistel eesmärkidel juurdepääsuks aegunud.

8.2 Taganemine

Kui spetsifikatsioon on tühistatud, toimub lisaks amortisatsiooni taotlevatele toimingutele järgmine:

• STI ajakohastab kohaldatavaid katsedokumente, et näidata spetsifikatsiooni tagasivõtmist.
• BSTS värskendab Bluetooth SIG -i websaidil koos juhistega alternatiivsete spetsifikatsioonide kohta.
• BSTS arhiveerib spetsifikatsiooni versiooni, mis on märgitud tagasivõtetuks, et liikmed saaksid seda ajaloolistel eesmärkidel kasutada.

Juhatus võib otsustada spetsifikatsiooni kohe tagasi võtta, ilma et see spetsifikatsiooni eelnevalt tühistaks.

 

9. Valge paberi protsess

Valgeid raamatuid luuakse ainult teavitamise eesmärgil. Järgmine valge raamatu protsess kehtib kõigi Bluetoothi ​​WG-de, EG-de, SG-de ja komiteede kohta. See jaotis ei kehti teabedokumentide kohta, mida kasutatakse ainult Bluetooth SIG-is.

Seda protsessi on illustreeritud allpool joonisel 9.1.

Enne kui mõni rühm või komitee alustab tööd valge raamatuga, mille kavatseb Bluetooth SIG avaldada, valmistab rühm või komitee ette nii harta ajakohastamise kavandi, milles määratletakse selgelt valge raamatu kavandatud sisu, kui ka valge raamatu ettepaneku esitluse.

Valge raamatu ettepaneku esitlus peab sisaldama vähemalt järgmist:

• Vajadus valge paberi järele
• Valge raamatu kavandatud sisu kokkuvõte
• Selgitus selle kohta, miks sisu ei soovitata lisada spetsifikatsiooni osana
• Kavandatud publik
• Kõik hooldusplaanid (st hinnanguline aeg enne selle valge raamatu järgmise väljaandmist võib olla vajalik)
• Soovitused valge raamatu varasemate versioonide (kui need on olemas) käsitsemiseks (nt arhiveerimine)

Harta uuendus ja valge raamatu ettepaneku esitlus tuleb esitada BARB re jaoksview. Pärast uuestiview ja BARB poolt harta uuendamise kinnitamise, esitab BSTS harta uuenduse BoD -le kinnitamiseks koos toetava valge raamatu ettepaneku esitlusega.

Kui juhatus kiidab harta ajakohastamise heaks, võib rühm või komitee jätkata valge raamatu väljatöötamist.

Kui rühm või komisjon on valge raamatu väljatöötamise lõpule viinud, viib BSTS läbi toimetuseview kooskõlas Bluetoothi ​​koostamisjuhistega.

Pärast BSTS -i kommentaaride lahendamist peab rühm esitama valge raamatu BSTS -ile juriidiliseks läbivaatamiseksview. Pärast juriidilise korra lõpetamistview, lepivad rühm ja BSTS kokku valgesse raamatusse lisatava tagasiside osas. Kui juriidilisest re -ist on lahendamata juriidilisi märkusiview Valgel paberil võib fraktsiooni esimees nõuda BoD päevakorras aega, et otsida BoD panust resolutsiooni.

Paralleelselt juriidilise review, peab rühm esitama valge raamatu uuesti BARBileview. Osana nende review, BARB võib soovitada, kas mõni valge paberi osa tuleks valgest paberist eemaldada ja lisada spetsifikatsiooni, järgides 3. jaotises kirjeldatud protsessi. BARB võib otsustada esitada valge raamatu ka teistele rühmadele või komiteedeleview. Pärast BARB review, lepivad rühm ja BARB kokku valgesse raamatusse lisatava tagasiside osas.

Kui seaduslik review tulemuseks on sisulised muudatused, täiendavad review võib nõuda BARB. Samamoodi, kui BARB review mis toob kaasa olulisi muudatusi, otsustab BSTS, kas täiendav õiguslik review neist muudatustest on vajalik. Pärast juriidilise korra lõpetamistview ja BARB review, BARB peab valge paberi heaks kiitma või tagasi lükkama.

Pärast seda, kui BARB on valge raamatu heaks kiitnud, esitab autorirühm või komitee BARB-i poolt heaks kiidetud valge raamatu BoD-le kinnitamiseks.

Valge raamatu protsess on lõppenud, kui juhatus on valge raamatu heaks kiitnud ja järgmised heakskiidujärgsed toimingud on lõpule viidud:

• BSTS on teinud heakskiidetud valge raamatu Bluetooth SIG -is avalikult kättesaadavaks websaidile.
• BSTS teavitab kõiki heakskiidetud valge raamatu liikmeid.
• Kui valge raamat on olemasoleva valge raamatu täiustus, arhiveerib BSTS valge raamatu versiooni, et liikmed saaksid seda ajaloolistel eesmärkidel kasutada.

Bluetooth SIG plaanib pärast heakskiidu saamist pärast heakskiitmist pärast nädala jooksul toiminguid lõpule viia.

 

10. Viited

Viidatud Bluetooth -dokumendid on saadaval Bluetoothi ​​kaudu websaidile http://www.bluetooth.com.

1. Bluetoothi ​​koostamise juhised (saadaval töörühma mallide ja dokumentide lehel, aadressil https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
2. Bluetooth SIG, Inc. põhimäärus (saadaval haldavate dokumentide lehel, aadressil https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
3. Bluetoothi ​​spetsifikatsiooni Errata Process dokument (saadaval töörühma mallide ja dokumentide lehel aadressil https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
4. Töörühma protsessidokument (saadaval töörühma mallide ja dokumentide lehel, aadressil https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
5. Testistrateegia ja terminoloogia läbiview dokument (saadaval kvalifikatsioonitesti nõuete lehel, aadressil https://www.bluetooth.com/specifications/qualification-test-requirements)
6. STI spetsifikatsioon Review Protsessi kontrollnimekiri (saadaval töörühma mallide ja dokumentide lehel, aadressil https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
7. Bluetoothi ​​SIG määratud numbrid (https://www.bluetooth.com/specifications/assigned-numbers)
8. Töörühma mallid ja dokumendid (saadaval töörühma mallide ja dokumentide lehel, aadressil https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
9. GATTi spetsifikatsiooni lisa (GSS) (saadaval GATTi spetsifikatsioonide lehel, aadressil https://www.bluetooth.com/specifications/gatt)
10. Esitage uue spetsifikatsiooni idee https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

 

11. Akronüümid ja lühendid

Tabel A: Akronüümid ja lühendid

 

A liide - Erratumi raskusastme klassifikatsioon

Selles lisas võetakse kokku spetsifikatsiooni vigade raskusastme klassifitseerimise juhised. See tabel lisatakse EPD tulevasele redaktsioonile ja seejärel see jaotis kustutatakse.

 

Lugege selle juhendi kohta lisateavet ja laadige alla PDF:

Spetsifikatsioonide haldamise protsessi dokument (SMPD) - Optimeeritud PDF
Spetsifikatsioonide haldamise protsessi dokument (SMPD) - Algne PDF

Kas teil on käsiraamatu kohta küsimusi? Postita kommentaaridesse!

Viited

• Kasutusjuhend