Dokumen Proses Manajemen Spesifikasi (SMPD)

Dokumen iki, tanpa preduli judhul utawa isine, dudu Spesifikasi Bluetooth sing tundhuk lisensi sing diwenehake dening Bluetooth SIG Inc. ("Bluetooth SIG") lan anggotane miturut Perjanjian Lisensi Paten / Hak Cipta lan Perjanjian Lisensi Merek Dagang Bluetooth.

DOKUMEN INI Kasedhiya "AS IS" LAN BLUETOOTH SIG, ANGGOTANE, lan AFFILIATE KANGGO NGANGGO TANPA REPRESENTASI UTAWA JAMINAN lan mbantah Kabeh JAMINAN, EXPRESS UTAWA IMPLIED, Klebu JAMINAN MERCHANTABILITY, TITUR, APLIKASI, YEN ISI DOKUMEN INI TANPA KESAL.

TO THE EXTENT ORA LARANGAN LAW, BLUETOOTH SIG, ANGGOTA, LAN KABEH APLIKASI KANGGO KABEH KABEH KANGGO NGANGGO ORA GAMPANG GUNA DOKUMEN INI LAN INFORMASI APA KANGGO ING DOKUMEN INI, Klebu REVENUE, ORGISIS, INTERRUPTION, UTAWA KERUSAKAN KHUSUS, INDIRECT, CONSEQUENTIAL, INCIDENTAL UTAWA PUNITIF, APA PUNCA LAN KANGGO GAMPUNG TEORI TANGGUNG JAWAB, lan Sanajan BLUETOOTH SIG, ANGGOTANE, UTAWA AFFILIATE KANGGO NGADILIKAKE GOLONGAN.

Dokumen iki duweke Bluetooth SIG. Dokumen iki bisa ngemot utawa nutupi subyek sing dadi properti intelektual Bluetooth SIG lan anggotane. Penyediaan dokumen iki ora menehi lisensi marang properti intelektual Bluetooth SIG utawa para anggotane.

Dokumen iki bisa diganti tanpa kabar.

1. Pambuka

Dokumen Proses Manajemen Spesifikasi (SMPD) nggambarake proses sing ditulis spesifikasi penulis lan reviewkudu tindakake kanggo nggawe spesifikasi anyar lan kanggo nambah spesifikasi sing ana (yaiku kanggo nambah utawa mbusak fungsi utawa kanggo ngganti fungsi tartamtu ing spesifikasi sing diadopsi), kanggo njaga spesifikasi sing diadopsi, lan kanggo ngatur spesifikasi sing diadopsi pungkasan. Kajaba iku, dokumen iki nggambarake proses nggawe, reviewing, lan nyetujoni kertas putih.

Ana bedane proses pangembangan spesifikasi antarane ngembangake spesifikasi anyar lan nambah spesifikasi sing ana amarga ana bedane ing ruang lingkup tugas kasebut; bedane kasebut disorot ing dokumen iki.

Proses pangembangan spesifikasi kalebu:

Tahap Syarat (diterangake ing Bagean 3) kanggo netepake syarat fungsional
Fase Pangembangan (diterangake ing Bagean 4) kanggo berkembang lan review spesifikasi

Tahap Validasi (diterangake ing bagean 5) kanggo ngesyahake spesifikasi kanthi tes Interoperable Prototype (IOP)
Tahap Adopsi / Persetujuan (diterangake ing Bagean 6) kanggo nyedhiyakake spesifikasi menyang Direksi SIG Bluetooth (BoD) kanggo adopsi / persetujuan

Dokumen Proses Errata Spesifikasi (EPD) [3] nggambarake proses ngusulake lan reviewkesalahan spesifikasi, lan disetujoni minangka Koreksi Errata (kaya sing ditemtokake ing Aturan [2]) kanggo spesifikasi sing diadopsi. Kajaba yen ora dicathet, kabeh referensi errata ing SMPD iki tegese errata spesifikasi.

1.1 Keutamaan

Undhang-undhang Bluetooth SIG, Inc. (Bylaws) lan perjanjian keanggotaan [2] dadi prioritas tinimbang konten sing ana konflik ing dokumen kasebut lan SMPD. Ora ana prekara apa wae ing dokumen iki, BoD tetep duwe kebijaksanaan lan wewenang utama kanggo njupuk tindakan lan njupuk keputusan sanajan tumindak lan keputusan kasebut ora ngetutake, utawa mbantah karo apa wae ing dokumen iki, lan ora ana dokumen sing mbatesi utawa matesi otoritas independen BoD lan budi pakerti.

Yen ana konflik antarane teks ing SMPD lan paraga, teks kasebut bakal dadi prioritas.

1.2 Kelompok lan komite sing dirujuk

Jinis klompok ing ngisor iki dirujuk ing dokumen iki: Klompok Studi (SG), Klompok Ahli (EG), lan Kelompok Kerja (WG). WG uga duwe subkelompok sing nglaporake menyang WG. Kajaba, jinis komite ing ngisor iki dirujuk ing dokumen iki: Bluetooth Architectural Review Papan (BARB), Uji Bluetooth lan Interoperabilitas (BTI), lan Kualifikasi Bluetooth Review Papan (BQRB). Dokumen iki uga nuduhake Staff Teknis Bluetooth SIG (BSTS), lan BoD.

1.3 Panitia reviews lan persetujuan

Panitia review yaiku review sing ditindakake dening anggota panitia (biasane 3 anggota) kanggo menehi umpan balik sajrone wektu sing ditemtokake (biasane 2-3 minggu), nangingview wektu bisa beda-beda gumantung saka dawa lan kerumitan materi lan prioritas liyane ing panitia. Klompok sing njaluk review lan panitia sing nganakake review saben setuju suwene review. Klompok lan anggota panitia nggunakake alat Bluetooth SIG kanggo ngabari lan nyathet wiwitan lan pungkasan review. Klompok umume bakal ngolah tanggapan panitia nalika ditampa. Nalika panitia review wektune kadaluwarsa, klompok kasebut rampung kanggo menehi tanggapan marang panitia, lan uga kudu nimbang-nimbang manawa re telat sing tekaview saran sing eling yen materi kasebut bisa uga disetujoni dening panitia sabanjure.

Persetujuan panitia dipikolehi kanthi swara swara saka anggota panitia sing tundhuk karo Dokumen Proses Grup Kerja [4].

1.4 Kabar kanggo anggota lan aksesibilitas bahan

Kabeh kabar sing diwenehake menyang anggota miturut dokumen iki bisa uga diwenehake liwat email, kayata nganyari teknis kanthi periodik. Notifikasi sing bakal diwenehake menyang kabeh anggota bakal dikirim menyang kabeh anggota aktif (yaiku, yen anggota durung ditanggepi, dipungkasi, utawa ditarik). Nalika notifikasi dikirim lewat email, dheweke bakal dikirim menyang alamat email sing paling dikenal (kaya sing kacathet ing cathetan Bluetooth SIG saiki) kanggo saben wong sing wis ndaftar ing akun anggota perusahaan lan sing ora milih nampa kabar email. Ora ana dokumen iki sing ngowahi kewajiban utawa syarat Bluetooth SIG babagan penyediaan kabar miturut Undhang-undhang utawa perjanjian liyane antarane Bluetooth SIG lan anggota apa wae.

Ing endi wae dokumen iki nuduhake a websitus sing bisa diakses kabeh anggota, iki nuduhake aksesibilitas kanggo individu sing duwe akun Bluetooth SIG sing aktif. Anggota sing ora duwe akun aktif bisa nggawe akun liwat Bluetooth SIG websitus.

1.5 Cithakan

Kanggo saben jinis dokumen (kayata, spesifikasi, kertas putih, dokumen tes) sing dirujuk ing SMPD iki, Bluetooth SIG nyedhiyakake template. Cithakan kasebut kudu digunakake minangka dhasar kanggo saben dokumen sing digawe sesuai karo SMPD iki. Gagal nggunakake template sing bener bisa nyebabake dokumen ora disetujoni. Cithakan kasedhiya ing Bluetooth SIG websitus [8].

1.6 Jinis Spesifikasi

Ana sawetara jinis spesifikasi Bluetooth SIG. Secara hirarkis, kabeh spesifikasi gumantung karo Spesifikasi Inti Bluetooth. Spesifikasi kayata pro tradisionalfiles; protokol tradisional; lan pro adhedhasar GATTfiles, layanan adhedhasar GATT, lan protokol adhedhasar GATT kabeh gumantung karo fitur ing Spesifikasi Inti. Spesifikasi liyane, kayata spesifikasi Model Mesh, gumantung karo Mesh Profile spesifikasi sing sabanjure gumantung karo Spesifikasi Inti.

Spesifikasi Suplemen Spesifikasi Inti (CSS) nemtokake jinis data, format data, lan pro umumfile lan kode kesalahan layanan sing digunakake dening Spesifikasi Inti lan spesifikasi liyane lan ora nemtokake tumindak apa wae.

Spesifikasi Suplemen Spesifikasi GATT (GSS) nemtokake format karakteristik lan deskriptor sing digunakake dening Profiles lan Layanan lan ora netepake tumindak apa wae.
Spesifikasi Mesh Device Properties (MDP) nemtokake sifat bolong sing digunakake dening Mesh Profile lan spesifikasi Model Mesh lan ora nemtokake tumindak apa wae.

2. Liwatview

Bagian iki menehi liwatview proses lan ora dimaksudake kanggo nyakup kabeh rincian.

Gambar 2.1 nuduhake enem fase utama sing nggawe Proses Manajemen Spesifikasi.

Papat tahap pertama kedadeyan sajrone proses pangembangan spesifikasi lan kalebu Tahap Syarat (Bagean 3), Tahap Pangembangan (Bagean 4), Tahap Validasi (Bagean 5), lan Tahap Adopsi / Persetujuan (Bagean 6). Iki diterusake karo rong tahap pasca adopsi: Fase Pangopènan Spesifikasi (Bagean 7) lan Tahap Akhir-Spesifikasi Pungkasan (Bagian 8).

Gambar 2.2 nggambarake rincian patang fase sajrone proses pangembangan spesifikasi. Kothak abu-abu nuduhake kiriman utama kanggo saben tahap. Kothak oranye ngringkes tonggak proses.

Ing Tahap Syarat (diterangake ing Bagean 3), proposal kanggo miwiti karya anyar (Proposal Kerja Anyar (NWP)) miwiti proses pangembangan spesifikasi kanthi nemtokake skenario pangguna supaya bisa diaktifake yen karya anyar kasebut diterusake. Yen NWP disetujoni, klompok sing ditugasake nggawe Functional Requirements Document (FRD). Sawise FRD disetujoni lan ditugasake menyang grup, Tahap Pengembangan diwiwiti.

Sajrone Tahap Pangembangan (diterangake ing Bagean 4), pangembangan spesifikasi lumaku kanthi urutan stages (0.5 / DIPD dadi 0.9 / CR) pungkasane dadi rancangan spesifikasi lengkap. Spesifikasi 0.9 / CR kasedhiya kanggo kabeh anggota, banjur dikirim menyang BoD sing nganggep spesifikasi kanggo disetujoni. Sawise disetujoni, Tahap Validasi diwiwiti.

Sajrone Tahap Validasi pangembangan spesifikasi (diterangake ing Bagean 5), spesifikasi 0.9 / CR sing disetujoni BoD kasedhiya kanggo kabeh anggotaview lan validasi, lan Anggota Review wis diwiwiti Validasi ditindakake liwat tes interoperabilitas (IOP) ing antarane prototipe sing dibangun dening anggota. Sawise pengujian IOP rampung (yen dibutuhake kanggo spesifikasi) lan BARB nyetujoni laporan tes IOP, mula Tahap Adopsi / Persetujuan diwiwiti.

Sajrone Tahap Adopsi / Persetujuan (diterangake ing Bagean 6), spesifikasi lan dokumen tes sing gegandhengan dirampungake; Disetujoni BARB, BQRB, lan BTI; lan paket spesifikasi pungkasan dikirim menyang BoD sing nganggep spesifikasi adopsi (yaiku, persetujuan pungkasan).

Spesifikasi bisa uga kudu bali menyang tahap utawa s sadurungetage yen ana pangowahan sing signifikan. Ing sawetara kasus, sampeyan uga bisa ngilangi bagean saka fase kaya sing dijelasake ing Bagean 4.4.

Tahap Maintenance Spesifikasi (diterangake ing Bagean 7) diwiwiti sawise spesifikasi diadopsi dening BoD. Sajrone tahap iki, kemungkinan kesalahan sing ditemokake ing spesifikasi sing diadopsi dilaporake lan dievaluasi, lan (yen dibutuhake) Koreksi Errata ditrapake kanggo spesifikasi kasebut. Tahap Maintenance Spesifikasi terus nganti spesifikasi ora digunakake utawa ditarik maneh (waca Fase Akhir-Umure Spesifikasi ing paragraf ing ngisor iki).

Fase Akhir-Umpan Spesifikasi (diterangake ing Bagean 8) nerangake proses penyusutan lan penarikan spesifikasi sing diadopsi.

3. Tahap Syarat

Tahap Syarat diwiwiti kanthi NWP (sing nyebutake kepinginan kanggo miwiti makarya ing siji utawa luwih skenario pangguna) utawa sawise netepake manawa karya anyar sing dipengini wis dijamin dening piagam WG. Yen WG pengin miwiti karya anyar sing diyakini wis ana ing lingkup piagam WG, WG kudu ngetutake proses sing ditemtokake ing Bagean 3.1 kanggo terus ngembangake FRD. Kanggo kabeh barang kerja liyane, WG kudu ngetutake proses sing ditemtokake ing Bagean 3.2. FRD nemtokake ruang lingkup syarat fungsional sing digunakake kanggo mbangun spesifikasi ing Tahap Pangembangan. Tahap Syarat digambarake ing Gambar 3.1.

3.1 Karya anyar sing dilindhungi dening charter WG

Nalika WG pengin miwiti karya anyar lan cukup yakin manawa fungsionalitas sing pengin ditambahake wis ana ing jangkauan piagam WG, WG bisa uga miwiti kerja ing FRD, yen dheweke bakal langsung ngandhani BARB. WG bakal nyakup kabar babagan BARB babagan makarya anyar sing diusulake lan salinan piagam WG kanthi basa sing disorot sing menehi wewenang kanggo miwiti karya anyar kasebut.

Yen BARB nolak analisis WG, WG kudu mandheg nggarap FRD lan nerusake proses NWP sing digambarake ing Bagean 3.2. Yen BARB nyetujoni analisis WG, WG bakal langsung ngandhani BSTS (liwat email menyang spesifikasi.manager@blu Bluetooth.com) lan BSTS bakal nambah item kasebut ing agenda BoD sabanjure.

WG bakal nyakup kabar menyang BSTS informasi sing padha diwenehake menyang BARB. Yen BoD nolak analisis WG, WG kudu mandheg nggarap FRD lan nerusake proses NWP sing dijelasake ing Bagian 3.2. Yen BoD nyetujoni analisis WG, WG bisa uga terus nggarap FRD kaya sing dijelasake ing Bagean 3.3.

3.2 Proposal Kerja Anyar (NWP)

Anggota apa wae, WG, SG, utawa EG bisa nggawe lan ngirim NWP (liwat Bluetooth SIG websitus [10]). NWP kudu nyakup, paling ora, informasi babagan ing ngisor iki kanthi nggunakake template resmi sing diwenehake ing [8]:

Skenario pangguna
Komitmen anggota kanggo ngembangake FRD lan wilayah apa wae (kayata, Kontributor, Panganggit, Reviewer, Prototyping)

Usul kepemimpinan kerja FRD
Ngusulake tugas kelompok kanggo kerja FRD
Alamat email penulis utama

Cathetan: Pandhuan kanggo proses NWP kasedhiya ing Bluetooth SIG websitus [10].

BSTS bakal nindakake tugas ing ngisor iki sajrone ngembangake NWP:

Nyedhiyakake panganggit kuitansi (biasane sajrone pitung dina tanggalan nalika nampa) lan jelasake langkah-langkah sabanjure.

Yen perlu, kerjo bareng karo panulis supaya NWP jelas lan lengkap. Iki bisa uga mbutuhake sawetara pengulangan NWP.
Yen NWP ngemot pratelan babagan kesalahan spesifikasi Bluetooth sing diadopsi, kerjo bareng karo panulis kanggo file entri menyang sistem errata.
Yen wis dingerteni manawa NWP duweni potensi nduplikasi karya sing wis lumaku utawa wis rampung, ngabari penulis babagan karya liyane kanggo evaluasi.

Kirimake NWP menyang NWP websitus diakses kabeh anggota.
Ngabari kabeh anggota yen NWP kasedhiya kanggo review lan prelu komitmen anggota tambahan kanggo ngembangake FRD.

Anggota bisa ngubungi penulis kanggo takon utawa menehi tanggapan babagan NWP.

Paling ora ana telung perusahaan anggota sing kudu komitmen kanggo melu ngrampungake FRD sing diasilake kanggo NWP kanggo dadi calon persetujuan BoD, lan paling ora siji perusahaan anggota kudu dadi anggota Associate utawa Promotor. Sawise disetujoni BoD saka NWP, BoD bakal milih NWP menyang sub-kelompok WG kabeh anggota utawa SG sing digunakake kanggo nggarap FRD (diterangake ing bagean 3.3). Yen subgrup WG utawa SG sing cocog ora ana, bisa uga digawe.

Kanggo NWP sing nduweni komitmen anggota cukup, BSTS bakal nindakake tugas tambahan ing ngisor iki:

Paling ora 13 dina sadurunge NWP diusulake kanggo disetujoni dening BoD, ngabari BARB, lan klompok sing disaranake NWP kanggo tugas, saka persetujuan NWP sing isih ana. Iki ditindakake kanggo menehi kesempatan kanggo menehi umpan balik ing bidang kayata klompok sing diusulake, apa NWP wis dilindhungi karya sing wis ana, lsp.

Kirimake NWP sing wis rampung menyang BoD.

Yen NWP diajukake dening anggota sing ora ana gandhengane karo klompok, atur supaya salah sawijining anggota ngirim NWP menyang BoD.
Yen NWP diajukake dening sawijining klompok, atur ketua klompok kanggo nampilake NWP menyang BoD.

Undang kursi BARB lan kursi klompok, sing disaranake NWP kanggo tugas, ing rapat BoD.
Yen NWP disetujoni lan diwenehake dening BoD, ngabari klompok sing ditugasake; panganggit; anggota sing diidentifikasi ing NWP minangka komitmen kanggo ngembangake FRD sing cocog; lan yen NWP diusulake dening klompok, klompok asil lan langkah sabanjure.

Sawise NWP disetujoni dening BoD, nganyari status ing NWP websitus.

NWP bisa ditolak dening BoD miturut pamrentahane, kayataampamarga watesan sumber daya, yen pakaryan wis rampung, pakaryan kasebut ora ana ing jangkoan dokumen pamrentah Bluetooth SIG (kayata, Application Programming Interface (API)) [2], utawa yen karya sing diusulake kudu filed minangka erratum. Yen NWP ditolak, BSTS bakal menehi notifikasi marang panganggit, anggota sing diidentifikasi ing NWP duwe komitmen kanggo ngembangake FRD sing cocog, lan, yen NWP diusulake dening klompok, grup kasebut. Kabar kasebut bakal nyakup alasan apa wae sing ditolak. Panulis, anggota sing setya, utawa klompok bisa njaluk wektu ing agenda BoD kanggo narik penolakan kasebut.

Yen anggota utawa klompok pengin ngusulake mbusak fitur saka spesifikasi sing diadopsi, klompok utawa anggota kasebut kudu nyiyapake NWP. NWP kudu nyakup analisis pengaruh sing bakal ditindakake ing kompatibilitas mundur lan interoperabilitas, kalebu analisis pengaruh ing kasus tes.

NWP ora dibutuhake kanggo nambah spesifikasi CSS, GSS, utawa MDP: biasane, nganyari spesifikasi CSS, GSS, utawa MDP asil saka update menyang spesifikasi liyane sing duwe NWP dhewe.

3.3 Dokumen Syarat Fungsional (FRD)

FRD nemtokake syarat fungsional kanggo ngaktifake skenario pangguna. FRD kudu nyakup, paling ora, informasi babagan ing ngisor iki kanthi nggunakake template resmi sing diwenehake ing [8]:

Skenario pangguna
Syarat fungsional adhedhasar skenario pangguna

Komitmen anggota kanggo ngembangake spesifikasi sing diasilake
Dhukungan prototipe opsional dening anggota kanggo peran sing diantisipasi
WG sing disaranake kanggo nggawe spesifikasi sing diasilake

Pangembangan FRD

FRD digawe dening subgroup WG kabeh anggota utawa anggota SG kanthi dhukungan editorial saka BSTS. Sapa wae anggota sing kepengin melu pengembangan FRD bisa gabung karo grup kasebut.

FRD kudu nuduhake komitmen saka paling ora rong (sanajan telung disengkuyung) Perusahaan anggota level Associate utawa Promoter kanggo melu pengembangan spesifikasi sing diasilake. WGs utawa SG sing ngirim FRD kudu nyoba entuk dhukungan wiyar saka perusahaan anggota klompok sing makili segmen industri target sing diidentifikasi ing FRD.

Fungsionalitas anyar sing diusulake ing FRD kudu didhukung nalika transportasi lan piranti sing ana saiki bisa didhukung. Iki kalebu, kanggo mantanample, ndhukung pro adhedhasar GATTfiles lan layanan ing transportasi dhasar Rate Rate / Extended Data Rate (BR / EDR) lan transportasi Bluetooth Low Energy (LE). Yen fungsi anyar ora duwe dhukungan anggota kanggo transportasi, kanggo mantanampamarga ora ana komitmen anggota kanggo netepake panggunaan transportasi utawa sawetara platform tes IOP sing cukup kanggo siji utawa luwih peran, dhukungan kanggo transportasi kasebut bisa uga ora kalebu FRD.

Kajaba digunakake kanthi bener, fungsi anyar, profiles, lan layanan kudu tundhuk karo syarat kompatibilitas mundur sing diterangake ing Bagean 3.3.2.

WG utawa SG kudu ngirim FRD menyang BARB kanggo review lan persetujuan. BARB kudu nyetujoni utawa nolak FRD adhedhasar penilaian teknik kasebut. Yen disetujoni dening BARB, FRD bakal kasedhiya kanggo kabeh anggota lan kabar yen kasedhiya bakal ditanggepi dening BSTS.

FRD ora dibutuhake kanggo nambah spesifikasi CSS, GSS, utawa MDP: biasane, nganyari spesifikasi CSS, GSS, utawa MDP asil saka update spesifikasi liyane sing duwe FRD dhewe.

Syarat kompatibilitas mundur

Kompatibilitas mundur kanggo BR / EDR

Kanggo operasi BR / EDR, syarat kompatibilitas mundur ditetepake minangka interoperasi karo bagean BR / EDR saka Spesifikasi Inti Bluetooth v1.1 lan mengko.

Kompatibilitas mundur kanggo Bluetooth Low Energy

Kanggo operasi LE, syarat kompatibilitas mundur ditemtokake minangka interoperasi karo bagean LE saka Spesifikasi Inti Bluetooth v4.0 lan mengko.

Kompatibilitas mundur kanggo spesifikasi kajaba Spesifikasi Inti

Kanggo spesifikasi kajaba Spesifikasi Inti Bluetooth, kompatibilitas mundur versi tartamtu kudu dijaga karo kabeh versi sadurunge sing duwe nomer versi utama sing padha. Kanggo mantanampversi 1.3 kudu kompatibel karo versi 1.2, 1.1, lan 1.0, nanging versi 2.0 bisa uga ora kompatibel karo versi 1.0, 1.1, 1.2, lan 1.3. Elinga yen kenaikan nomer versi utama Spesifikasi Inti ora ateges kurang kompatibilitas mundur karo versi sadurunge.

Bebasan saka syarat kompatibilitas mundur

WG utawa SG bisa uga ngusulake ora duwe fungsi tartamtu saka syarat kompatibilitas mundur yen diwenehake. Kanggo mantanampyen fungsionalitas ditampilake duwe tarif adopsi pasar sing kurang utawa, amarga ana masalah interoperabilitas, luwih becik mbusak utawa ngganti fungsi tinimbang ngowahi fungsi. WG utawa SG kudu nyakup pengecualian kompatibilitas mundur ing FRD, sing disetujoni dening BARB sawise disetujoni FRD. Sembarang pengecualian sing disetujoni BARB bakal diwenehake menyang BoD kanggo disetujoni ing 0.9 / CR Stage.

3.4 Piagam Grup Pakaryan

Nalika BARB nyetujoni FRD sing diusulake diwenehake menyang WG sing ana, WG kasebut kudu nyiyapake draf pembaruan menyang piagam kasebut kanggo nambah fungsi anyar ing ruang lingkup (kajaba BoD sadurunge wis nyetujoni analisis WG yen nganyari charter WG ora dibutuhake). Nanging, nalika BARB nyetujoni FRD sing diusulake ditugasake menyang WG anyar, BARB lan anggota sing kepengin ngembangake fungsi sing digambarake ing FRD kudu nyiyapake draf piagam kanggo WG anyar kanthi fungsi anyar sing kalebu ing ruang lingkup charter .

Sawise charter WG sing anyar utawa anyar disiapake, kudu dikirim menyang BARB manehview lan persetujuan. Sawise BARB nyetujoni piagam kasebut, draf piagam WG sing anyar utawa sing dianyari bakal dikirim menyang BoD kanggo disetujoni.

Sawise BoD nyetujoni piagam kasebut, WG sing digunakake kanggo pengembangan spesifikasi dening BoD kudu kerja sama karo klompok sing nyiapake FRD yen perlu nganyari utawa klarifikasi yen FRD dibutuhake. Yen nganyari FRD dibutuhake sajrone Tahap Pangembangan, proses sing dijelasake ing Bagean 3.3 lan bagean iki kudu ditindakake; Nanging, pangembangan spesifikasi bisa uga sejajar karo nganyari charter FRD lan WG.

3.5 Syarat syarat Fase metu

Tahap Syarat wis rampung lan Tahap Pangembangan diwiwiti nalika piagam WG kanthi ruang lingkup sing dibutuhake kanggo FRD dikonfirmasi utawa disetujoni dening BoD lan persyaratan ing ngisor iki wis dipenuhi:

NWP wis disetujoni dening BoD, utawa BoD wis setuju manawa NWP ora prelu.

Piagam FRD lan WG sing cocog wis disetujoni dening BARB.

4. Tahap Pangembangan

Sajrone Tahap Pangembangan, WG sing ditugasake nggawe spesifikasi anyar lan / utawa ningkatake spesifikasi sing ana. FRD nemtokake persyaratan spesifikasi Bluetooth sing anyar utawa sing luwih apik. Ora ana fungsi sing diidini ing spesifikasi sing ora ana gandhengane karo syarat ing FRD. Tujuane yaiku nggawe spesifikasi 0.9 / CR sing siyap kanggo Tahap Validasi (diterangake ing Bagean 5) ing pungkasan Tahap Pangembangan.
Sajrone Tahap Pangembangan, spesifikasi (utawa tambahan spesifikasi) maju liwat telung stages.

Kanggo spesifikasi anyar, telung stagyaiku:

0.5 Stage
0.7 Stage

0.9 Stage

Kanggo paningkatan spesifikasi, telung stagyaiku:

Dokumen Proposal Peningkatan Draf (DIPD) Stage

Dokumen Proposal Peningkatan Akhir (FIPD) Stage
Panjaluk Ganti (CR) Stage

Saben stage dijlentrehake luwih ing bagean ing ngisor iki. Gambar 4.1 ing ngisor iki nggambarake macem-macem dokumen sing bakal disiapake WG ing saben stage.

Gambar 4.1: Overview saka spesifikasi stagsing kedadeyan sajrone Tahap Pangembangan

Peran BARB sajrone proses pangembangan spesifikasi yaiku menehi saran lan pitulungan teknis kanggo WG. WG bisa uga kapan wae njaluk panjaluk marang BARB babagan saran teknis babagan pangembangan spesifikasi lan konsep arsitektur sing bakal digunakake ing spesifikasi. WGs utamane dianjurake kanggo njaluk saran awal saka BARB kanggo fitur sing duwe pertimbangan arsitektur sing luwih kompleks.

4.1 0.5 / DIPD Stage

Sajrone 0.5 / DIPD Stage, WG bakal berkembang ing ngisor iki kanthi nggunakake template resmi sing diwenehake ing [8]:

Kanggo spesifikasi anyar, draf spesifikasi 0.5, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:

Arsitektur kanggo nutupi syarat kaya sing kacathet ing FRD

Kanggo protokol, jalur akses layanan ditetepake
Kanggo layanan, data lan prilaku sing kapapar
Kanggo profiles, protokol sing diidentifikasi lan fungsionalitas sing ditemtokake

2. Kanggo paningkatan spesifikasi, draf DIPD, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:

Latar mburi: Ruang lingkup kerja, tujuan sing nuntun karya, lan kepiye proposal spesifik iki cocog karo ruang lingkup
Swaraview proposal: Ringkesan fungsi sing ditambahi (nambah keluwesan, kinerja sing luwih apik, lsp) sing diwenehake dening DIPD kalebu katrangan sing jelas babagan cara fungsi anyar cocog karo versi spesifikasi saiki. Yen WG wis ngevaluasi macem-macem proposal, usulan-usulan kasebut kudu dilebokake kanggo ngidini BARB kesempatan kanggo nemtokake manawa rajin cekap digawe ing pilihan proposal sing disenengi.

Jangkoan syarat: Ringkesan jangkoan syarat fungsional sing diwenehake dening proposal, kanthi referensi syarat sistem sing cocog lan skenario panggunaan sing diwenehake ing FRD sing gegandhengan
Definisi masalah: Pratelan masalah sing ditanggulangi dening proposal
Kriteria pilihan: Pratelan babagan kriteria pilihan / kinerja saka metrik evaluasi sing gegandhengan sing nuntun proses pemilihan

Justifikasi pilihan: Pemeriksaan metrik evaluasi sing mbenerake pilihan antarane proposal lan mbukak perdagangan
katrangan: Deskripsi fungsi lan protokol lengkap. Bagean iki bisa adaptasi karo macem-macem kabutuhan kanthi nambah sub-bagean sing relevan.

3. Strategi Tes: Deskripsi fungsi sing diusulake kanggo dites (utawa ora dites) minangka bagean saka Program Kualifikasi Bluetooth lan cara fungsionalitas sing diusulake kanggo dites (kayata, pangarepan kanggo Tester Bawah utawa Tester Atas, lan yen tes kasebut bakal dianggep minangka tes sing cocog utawa interoperabilitas utawa kombinasi saka kalorone). Iki bisa uga ana ing dokumen sing kapisah utawa bagean sing beda ing spesifikasi 0.5 / DIPD. Konvensi sing bakal digunakake ing Strategi Tes diterangake ing Strategi Tes lan Terminologi Overview dokumen (TSTO) [5].

Pamirsa utama dokumen ing stage kalebu anggota WG lan BARBview proposal arsitektur lan jangkoan syarat, lan BTI sing reviews Strategi Tes. Ing kasus paling, dokumen ing stage ora dimaksudake kanggo ngemot teks sing direncanakake kalebu ing spesifikasi pungkasan.

BSTS kudu manehview kabeh dokumen kanggo konsistensi karo Pedoman Panyusunan Bluetooth [1] lan ngenali masalah sing kudu ditangani WG. BARB kudu manehview spesifikasi 0.5 / DIPD. Kanggo paningkatan spesifikasi, BARB uga kudu digunakake manehview DIPD kanggo netepi syarat kompatibilitas mundur sing diterangake ing Bagean 3.3.2. BTI kudu manehview Strategi Tes.

BARB kudu nyetujoni utawa nolak spesifikasi 0.5 / DIPD adhedhasar penilaian teknik kasebut. Yen disetujoni dening BARB, spesifikasi 0.5 / DIPD bakal kasedhiya ing Bluetooth SIG websitus kanggo kabeh anggota Associate lan Promotor lan menehi kabar babagan kasedhiyan bakal ditanggepi dening BSTS. Ing 0.5 / DIPD Stage, persetujuan Strategi Tes ora dibutuhake.
0.5 / DIPD Stage ora dibutuhake kanggo nambah spesifikasi CSS, GSS, utawa MDP

0.5 / DIPD Stage syarat metu

0.5 / DIPD Stage lengkap lan 0.7 / FIPD Stage diwiwiti nalika syarat metu ing ngisor iki dipenuhi:

BSTS wis rampung reviewspesifikasi 0.5 / DIPD lan Strategi Tes.

BARB wis nyetujoni spesifikasi 0.5 / DIPD.
BTI wis ngrampungakeview saka Strategi Tes.
BSTS wis nyedhiyakake spesifikasi 0.5 / DIPD sing disetujoni kanggo kabeh anggota Associate lan Promotor.

4.2 0.7 / FIPD Stage

Sajrone 0.7 / FIPD Stage, WG bakal berkembang ing ngisor iki kanthi nggunakake template resmi sing diwenehake ing [8]:

Kanggo spesifikasi anyar, draf spesifikasi 0.7, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:

Katrangan babagan kabeh pangowahan sing digawe wiwit disetujoni BARB 0.5, kalebu proposal anyar utawa modifikasi, kriteria pilihan, lan justifikasi pilihan. Pangowahan kudu diandharake ing level detail sing padha karo sing dibutuhake ing 0.5 Stage.

Kabeh syarat fungsional saka FRD sing ditangani.

2. Kanggo paningkatan spesifikasi, rancangan FIPD, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:

Katrangan babagan kabeh pangowahan sing ditindakake wiwit DIPD sing disetujoni BARB, kalebu proposal anyar utawa modifikasi, kriteria pilihan, lan justifikasi pilihan. Pangowahan kudu diandharake ing level detail sing padha karo sing dibutuhake ing DIPD Stage.

Yen perlu, wilayah sing dikembangake luwih lanjut sing diterangake ing bagean 4.1 babagan DIPD.
Katrangan lengkap babagan asil dandan.
Katrangan arsitektur sing dianyari.
Kabeh syarat fungsional saka FRD sing ditangani.

3. Dokumen tes 0.7 / FIPD, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:

Suite Test, kalebu dhaptar Tujuan Tes kaya sing diandharake ing TSTO [5].
Statement Conformance Conformance (ICS), kaya sing dijelasake ing TSTO [5].

Kanggo tambahan spesifikasi, Test Suite lan ICS bisa uga diwenehake minangka dokumen kapisah utawa minangka bagean tambahan ing FIPD.

Pamirsa utama dokumen sing diprodhuksi ing stage kalebu anggota WG lan BARBview katrangan lengkap babagan fitur utawa asil dandan kalebu sawetara teks sing direncanakake kalebu ing spesifikasi pungkasan. BTI minangka pamirsa kanggo review dokumen tes.

BSTS bakal manehview bagean anyar utawa pangowahan saka spesifikasi 0.7 / FIPD lan dokumen tes kanggo konsistensi karo Pedoman Panyusunan Bluetooth, kalebu konvensi basa sing digawe dening Bluetooth SIG. BARB bakal manehview spesifikasi 0.7 / FIPD.

BSTS bakal ngewangi WG nyiyapake dokumen tes 0.7 / FIPD sesuai karo TSTO [5].

BTI kudu manehview dokumen tes 0.7 / FIPD. WG kudu nyedhiyakake spesifikasi 0.7 / FIPD menyang BTI minangka referensi nalika reviewing dokumen tes 0.7 / FIPD, sing bakal ditampilake BTIview sesuai karo Re Spesifikasi BTIview Dhaptar Priksa Proses [6].

Sawise BARB ngrampungake review spesifikasi 0.7 / FIPD lan BTI wis ngrampungakeview saka 0.7 / dokumen tes FIPD, BSTS bakal ngasilakeviewspesifikasi 0.7 / FIPD kasedhiya kanggo kabeh anggota Associate lan Promotor.

0.7 / FIPD Stage ora dibutuhake tambahan kanggo spesifikasi CSS, GSS, utawa MDP.

0.7 / FIPD Stage syarat metu

0.7 / FIPD Stage rampung lan 0.9 / CR Stage diwiwiti nalika syarat metu ing ngisor iki dipenuhi:

BSTS wis rampung reviewing spesifikasi 0.7 / FIPD lan dokumen tes.
BARB wis ngrampungake reviewing spesifikasi 0.7 / FIPD.
BTI wis rampung reviewing 0.7 / FIPD Test Suite (Tujuan Tes) lan 0.7 / FIPD ICS.
BSTS wis nggawe reviewspesifikasi 0.7 / FIPD kasedhiya kanggo kabeh anggota Associate lan Promotor.

4.3 0.9 / CR Stage

Ana rong jinis CR: CR Integrasi, yaiku dokumen sing dilacak karo kabeh spesifikasi sing diadopsi sing nuduhake kabeh pangowahan wiwit versi sadurunge, lan CR singkatan, yaiku dokumen sing menehi instruksi kanggo ngowahi bagean sing mung magepokan karo versi spesifikasi sing adhedhasar CR.

Sajrone 0.9 / CR Stage, WG bakal berkembang ing ngisor iki kanthi nggunakake template resmi sing diwenehake ing [8]:

Kanggo spesifikasi anyar, draf spesifikasi lengkap 0.9 isi, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:

Katrangan babagan kabeh pangowahan sing digawe wiwit BARB-reviewspesifikasi 0.7 ed (utawa wiwit spesifikasi 0.5 yen ngasilake spesifikasi 0.7 wis dibebasake), kalebu sing anyar utawa
usulan modifikasi, kriteria pilihan, lan justifikasi pilihan. Pangowahan kudu diandharake ing level detail sing padha karo sing dibutuhake ing 0.5 Stage lan 0.7 Stage.

2. Kanggo tambahan spesifikasi:

Salah siji CR Terpadu, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:
Katrangan babagan kabeh pangowahan sing digawe wiwit BARB-reviewed FIPD (utawa wiwit DIPD yen FIPD wis dibebasake) kalebu usulan-usulan anyar utawa modifikasi, kriteria pilihan, lan justifikasi pilihan. Pangowahan kudu diandharake ing level detail sing padha karo sing dibutuhake ing DIPD Stage lan FIPD Stage.
Kabeh pangowahan sing diusulake kanggo spesifikasi sing sadurunge digunakake nggunakake pelacakan pangowahan.
Kabeh kesalahan teknis sing disetujoni (kanthi saben referensi erratum karo nomer erratum), ditampilake nggunakake pelacakan pangowahan, sing durung bisa dilebokake ing versi spesifikasi sing sadurunge digunakake, lan teks pengaruh sing ana gandhengane karo paningkatan spesifikasi; utawa sing nyebabake pengujian IOP.

3. Utawa CR Singkatan, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki:

Katrangan babagan kabeh pangowahan sing digawe wiwit BARB-reviewed FIPD (utawa wiwit DIPD yen FIPD wis dibebasake) kalebu usulan-usulan anyar utawa modifikasi, kriteria pilihan, lan justifikasi pilihan. Pangowahan kudu diandharake ing level detail sing padha karo sing dibutuhake ing DIPD Stage lan FIPD Stage.
Kabeh pangowahan sing diusulake kanggo saben bagean lan paragraf spesifikasi sing diusulake CR sing bakal diowahi.
Kabeh kesalahan teknis sing disetujoni (kanthi saben referensi erratum karo nomer erratum), ditampilake nggunakake markup, sing durung bisa dilebokake ing versi spesifikasi sing sadurunge diadopsi, lan teks pengaruh sing ana gandhengane karo paningkatan spesifikasi; utawa sing nyebabake pengujian IOP.

4. CR CSS (yen entri anyar dibutuhake spesifikasi), sing bisa ditempelake ing CR singkatan saka spesifikasi.
5. CR GSS (yen entri anyar dibutuhake spesifikasi), sing bisa ditempelake ing CR singkatan saka spesifikasi kasebut.
6. CR MDP (yen entri anyar dibutuhake spesifikasi), sing bisa ditempelake ing CR singkatan saka spesifikasi kasebut.
7. Dokumen tes 0.9 / CR, sing kudu kalebu, paling ora, informasi babagan ing ngisor iki nggunakake template resmi sing diwenehake ing [8]:

0.9 / CR Test Suite, sing kalebu kasus tes lengkap isi lan Tabel Kasus Pemetaan Kasus (TCMT), kaya sing dijelasake ing TSTO [5].
0.9 / CR ICS, kaya sing dijelasake ing TSTO [5].
Yen ngonfigurasi tes mbutuhake paramèter tartamtu kanggo Implementation Under Test (IUT), Informasi 0.9 / CR Implementasi eXtra kanggo Pengujian (IXIT).
Dhaptar Referensi Kasus Uji 0.9 / CR (TCRL) (opsional kanggo nganyari Spesifikasi Inti).

8. Analisis jangkoan tes sing nuduhake persyaratan spesifikasi sing dites utawa ora dites ing 0.9 / CR Test Suite (kanggo tambahan spesifikasi, analisis jangkoan tes mung kudu nyakup fungsionalitas sing mentas ditambahake lan kena pengaruh, lan dudu wilayah sing durung kena pengaruh spesifikasi asli).
9. Rencana tes IOP.

Kanggo paningkatan spesifikasi, Test Suite, ICS, lan IXIT bisa uga diwenehake minangka dokumen kapisah utawa minangka bagean tambahan ing CR Singkatan.

Ing kasus paling umum, CR Integrasi utawa Singkatan kudu adhedhasar versi spesifikasi sing sadurunge diadopsi, nanging bisa uga adhedhasar draf penengah paling anyar. Nomer versi spesifikasi draf paling anyar paling anyar yaiku nomer versi sing ana gandhengane karo versi dokumen sing beku lan ora bakal suwe saya suwe. Yen ora, informasi identifikasi tambahan (kayata tanggal dokumen lan a URL menyang lokasi permanen) kudu disedhiyakake kanggo ngenali versi "garis dasar" tartamtu. Yen draf penengah digunakake, pangowahan sing ora ana gandhengane karo CR ing bagean tartamtu sing diowahi CR kudu dilebokake, nanging ora dibutuhake ditampilake nganggo markup. Yen bagean sing relevan kanggo draf penengah mengko diupdate, CR kudu diupdate kanggo nggambarake update ing draf menengah.

Saenipun, materi CR Singkatan digabungake dadi draf spesifikasi lengkap lan dokumen tes lengkap, sadurunge Tahap Validasi, nanging bisa uga digabungake ing wiwitan Tahap Validasi. Yen pirang-pirang fitur sing dikembangake kanggo spesifikasi (kayata, Spesifikasi Inti), luwih becik integrasi fitur dadi siji konsep sawise tes IOP rampung.

BSTS bakal manehview spesifikasi 0.9 / CR lan dokumen tes kanggo konsistensi karo Pedoman Panyusunan Bluetooth. Banjur BARB bakal manehview spesifikasi 0.9 / CR banjur diterusake karo rencana tes IOP (kaya sing dijelasake ing Bagean 4.3.1). Sawise spesifikasi 0.9 / CR dikirim dening WG menyang BARB kanggo review, BSTS bakal bisa diakses kabeh anggota bisa digunakake manehview lan ngabari kabeh anggota kasedhiyan kasebut. Wiwit saiki, ing proses pangembangan spesifikasi, BSTS bakal nyedhiyakake draf spesifikasi sing dikirim menyang BARB kanggo kabeh anggota kanthi kabar manawa dikirim menyang kabeh anggota.

Kanggo paningkatan spesifikasi, WG bakal menehi saran marang BoD manawa versi spesifikasi sadurunge utawa ora, kudu dibatalake utawa ditarik, kalebu alasan teknis rekomendasi kasebut.

BARB bakal manehview analisis WG kanggo kepatuhan spesifikasi 0.9 / CR karo persyaratan sing diwenehake ing FRD, masalah keamanan potensial, masalah regulasi, selaras karo arsitektur Bluetooth, lan, kanggo peningkatan spesifikasi, tundhuk karo syarat kompatibilitas mundur sing diterangake ing Bagean 3.3.2 .XNUMX. Yen BARB nemtokake masalah keamanan sing potensial, BARB bakal ngabari BSTS kanggo review lan koordinasi karo Grup Ahli Keamanan; lan yen BARB nemtokake implikasi peraturan apa wae, BARB bakal ngabari BSTS manehview lan koordinasi karo Komite Regulasi lan penasihat hukum Bluetooth SIG. BARB kudu nyetujoni utawa nolak spesifikasi 0.9 / CR adhedhasar penilaian teknik lan pertimbangan faktor sing diterangake ing paragraf iki.

BTI bakal manehview dokumen tes 0.9 / CR sing dianakake analisis jangkoan tes. BTI kudu nyetujoni utawa nolak dokumen tes 0.9 / CR.

Sawise BARB nyetujoni spesifikasi 0.9 / CR, WG ngirim rencana tes IOP menyang BARB kanggo review.

Spesifikasi 0.9 / CR sing disetujoni BARB diwenehake menyang BoD kanggo nyetujoni wiwitan tes IOP lan publikasi spesifikasi 0.9 / CR kanggo kabeh anggota.

Kanggo nyorot masalah hukum sing potensial, WG bisa uga njaluk spesifikasi manehview dening penasihat hukum Bluetooth SIG (re legalview) sadurunge re ukum sing wajibview kedadeyan sajrone Adopsi / Tahap Persetujuan. Nanging, kanggo tambahan spesifikasi, re sahview kudu rampung ing CR Terpadu (beda karo CR Singkatan) lan iki kudu dijadwalake sadurunge supaya sumber kasedhiya.

Rencana tes IOP

WG bakal nggawe rencana tes IOP tertulis sing kudu nyukupi kabeh syarat sing ditemtokake ing ngisor iki kanggo digunakake sajrone Tahap Validasi ing acara tes IOP. WG kudu ngirim rencana tes IOP menyang BARB kanggo review sadurunge acara tes IOP diwiwiti. Kanggo paningkatan spesifikasi sing gampang (utamane sing ora mbutuhake modifikasi utawa nambah kasus uji coba ing Suite Suite), pengujian IOP bisa uga ora dibutuhake, lan WG bisa uga ngirim panjaluk menyang BARB kanggo ngilangi pengujian IOP kanthi nggunakake proses sing wis ditemtokake ing Bagean 4.4.

Rencana tes IOP kudu kalebu:

Kasus uji kanggo verifikasi kabeh fitur wajib, opsional, lan kondisional sing anyar
Paling ora siji kasus tes kanggo saben kode op
Paling ora siji kasus tes kanggo saben parameter
Paling ora siji kasus tes kanggo saben jinis paket
Kasus uji kompatibilitas mundur kanggo tambahan spesifikasi saéngga persyaratan sing kacathet ing Bagean 3.3.2 dipenuhi kanggo kabeh fungsi sing ditambahake (uga deleng Bagean 4.3.1.1).
Kasus uji yen IUT kena nilai ing njaba kisaran sing ditemtokake utawa aspek prilaku sing dianggep ora valid utawa ora dikarepake (kasus uji coba Prilaku ora valid). Elinga, manawa panguji kayata PTS utawa alat uji coba liyane bakal dadi inisiatif tumindak salah.
Nomer sing ditugasake sementara (dipilih kanthi koordinasi karo BSTS supaya ora tumpang tindih ing acara tes IOP mbesuk) kanggo digunakake ing acara tes IOP, kaya sing dijelasake ing Bagean 4.3.1.2.
Identifikasi jumlah implementasi independen sing dibutuhake sing kudu dilewati ing saben kasus uji coba, kanthi njupuk syarat jangkoan sing diterangake ing Bagean 4.3.1.3
Identifikasi kasus uji coba ing Suite Suite sing dipercaya WG kudu dikalahake lan sabdhoning amarga ora kalebu. Biasane kalebu: • Kasus uji Bukti mbesuk (contone, tes umum supaya kemungkinan tambahan bisa ditambah, kayata karakteristik tambahan, karakteristik tambahan, utawa panggunaan bit utawa kolom Reservation for Future Use (RFU))
• Kasus tes sing minangka bagean saka tes liyane sing kalebu
• Kasus tes umum sing meh padha karo tes sing mbukak sawetara spesifikasi liyane (kayata, nyebabake kode kesalahan umum)
• Kasus tes kanthi tujuan tes sing padha karo kasus uji sing mbukak transportasi liyane (kayata, kasus tes BR / EDR sing padha karo kasus tes LE)
• Tes kestabilan utawa stres saka implementasine

Rencana tes IOP bisa uga kalebu tes sing unik kanggo tes IOP kayata kasus tes end-to-end sing ngurutake urutan sing luwih kompleks sing bisa uga padha karo skenario pangguna khas.

Sanajan persetujuan BARB kanggo rencana tes IOP ora dibutuhake (amarga ngerti yen rencana tes IOP bakal terus diowahi lan ditambah karo saben acara tes IOP), persetujuan BARB kanggo laporan tes IOP dibutuhake (deleng Bagean 5.1.1) . Yen rencana tes IOP ora memenuhi kabeh persyaratan sing ditemtokake ing Bagean 4.3.1, WG kudu menehi ringkesan variasi sing dingerteni lan alesan kanggo saben varian menyang BARB sadurunge acara uji IOP diwiwiti.

Rencana tes IOP lan kasus uji coba utamane adhedhasar konten ing dokumen tes spesifikasi sing gegandhengan.

Kanggo nggawe acara uji coba IOP dadi efisien, WG kudu duwe rencana tes IOP lan kabeh kasus tes sing gegandhengan rampung lan kasedhiya kanggo para pelaksana paling ora sewulan sadurunge acara tes IOP pisanan.

Rencana kanggo nyoba kompatibilitas mundur
Kanggo paningkatan spesifikasi, tes IOP kompatibilitas mundur kudu nimbang verifikasi tumrap kabeh versi spesifikasi sing aktif lan ora aktif amarga spesifikasi lan fungsi sing umume ditemokake ing produk Bluetooth bisa uga duwe umur dawa banget (kayata kendaraan). WG kudu nganalisa tingkat tes kompatibilitas mundur sing cocog sing dibutuhake (yen ana) kalebu versi sing bakal dites lan tes sing bakal ditindakake, lan nyedhiyakake analisis iki menyang BARB. BARB kudu manehview analisis lan nyaranake pangowahan (yen ana) supaya WG dilebokake ing rencana tes IOP.

Anggota sing melu tes kompatibilitas mundur disaranake nggawa piranti lawas sing wis cocog karo versi spesifikasi sadurunge. WG kudu nglaporake kegagalan kompatibilitas mundur ing laporan tes IOP. Perusahaan anggota uga dianjurake kanggo nindakake tes kompatibilitas mundur ing laboratorium dhewe ing sanjabane lokasi acara tes IOP lan nglaporake masalah sing gegandhengan karo spesifikasi menyang WG.

Nomer Ditugasake Sementara digunakake ing tes IOP
BSTS lan BARB kudu dikonsultasikan kanggo mengkoordinasi tugas nomer nomer sing ditugasake sing bakal digunakake ing acara tes IOP supaya ora ana tumpang tindih utawa bentrokan karo spesifikasi liyane. Nilai-nilai sementara kasebut kudu dilebokake ing rencana tes IOP lan ora bakal diwenehake kanggo nggunakake spesifikasi apa wae sing diadopsi.

Kanggo tes IOP ing endi sing diusulake siji utawa luwih nilai UUID 16-bit, angka ing kisaran 0x7F00 nganti 0x7FFF dilindhungi undhang-undhang kanggo tes IOP.

Kanggo uji coba IOP ing endi siji utawa luwih nilai Fixed Protocol Service Multiplexer (PSM) sing diusulake, angka diwiwiti saka pungkasan kisaran valid saka 0x0000 nganti 0x007F, kaya sing ditemtokake ing Spesifikasi Inti, bakal digunakake.

Syarat jangkoan
WG kudu menehi bukti marang BARB manawa nomer sing dibutuhake (kaya sing diterangake ing bagean sabanjure) implementasi independen wis lolos ing saben kasus uji coba. Sembarang panjaluk WG sing dikatutake kanggo implementasi independen sing dibutuhake kudu dicantumake ing rencana tes IOP sing dikirim menyang BARB.

Implementasine dianggep independen, yen kabeh bagean sing ana gandhengane karo validasi wis dikembangake kanthi mandhiri, yaiku dening tim sing beda-beda (sing ora mesthi asale saka perusahaan liyane). BSTS bisa uga mbantu mbiji apa prototipe bisa dianggep bebas saka siji lan liyane kanggo njaga rincian anonimitas lan kerahasiaan babagan implementasine.

Elinga yen alat tes, kalebu PTS, ora dianggep minangka implementasi independen.

Persyaratan jangkoan IOP Spesifikasi Inti
Fitur Spesifikasi Inti biasane nemtokake siji utawa luwih peran ing endi saben peran dirancang kanggo interoperasi karo siji utawa luwih peran liyane utawa bisa uga dhewe.

Kanggo saben pasangan peran sing dirancang kanggo saling kerja bareng, paling ora telung implementasi independen kanggo saben peran kudu dituduhake kanggo interoperasi karo telung implementasi independen kanggo peran pelengkap.

Kanggo saben peran sing bisa interoperasi karo piranti liyane kanthi peran sing padha, paling ora telung implementasi independen saka peran kasebut kudu nduduhake manawa dheweke bisa saling komunikasi ing peran kasebut.

Persyaratan jangkoan IOP spesifikasi layanan
Paling ora telung implementasi layanan independen kudu nduduhake manawa ana interoperasi paling ora siji implementasine klien, yaiku PTS.

Profile lan syarat jangkoan IOP spesifikasi protokol
Profile lan spesifikasi protokol biasane nemtokake siji utawa luwih peran ing endi saben peran dirancang kanggo makarya karo siji utawa luwih peran liyane, utawa bisa uga dhewe.

Kanggo saben pasangan peran sing dirancang kanggo saling kerja bareng, paling ora rong implementasi independen kanggo saben peran kudu nuduhake manawa ana interoperasi karo rong implementasi independen kanggo peran pelengkap.

Kanggo saben peran sing bisa interoperasi karo piranti liyane kanthi peran sing padha, paling ora telung implementasi independen kanggo peran kasebut kudu nduduhake manawa ana sesambungan karo siji liyane ing peran kasebut.

Syarat jangkoan IOP spesifikasi model
Paling ora telung model server independen utawa implementasi model kontrol kudu nduduhake manawa ana interoperasi paling ora siji implementasine klien (yaiku PTS), lan paling ora ana siji model model klien kudu nuduhake manawa ana interoperasi paling ora siji implementasi model server lan PTS.

Nomer versi spesifikasi

Sajrone 0.9 / CR Stage, WG kudu nyiyapake rekomendasi kanggo menehi saran menyang BoD babagan nomer versi sing bakal ditrapake kanggo spesifikasi nalika diadopsi.

Versi spesifikasi dadi rong jinis: versi rilis lengkap, kalebu fitur anyar utawa sing dianyari, lan versi rilis pangopènan (uga dikenal minangka "versi dot-Z"), sing nggabungake kesalahan teknis lan editorial, nanging ora kalebu sing anyar utawa sing dianyari fitur. Versi rilis lengkap duwe nomer loro bagean ing bentuk XY, kayata 2.1 utawa 5.0, dene versi rilis pangopènan duwe nomer telung bagean ing bentuk XYZ, kayata 2.1.2. Nilai Z ora bisa 0.

Kanggo rong versi, siji diarani "versi sing luwih dhuwur" lan liyane minangka "versi ngisor". Iki ditemtokake miturut aturan ing ngisor iki:

Yen komponen X beda, sing duwe nilai X luwih dhuwur yaiku "versi sing luwih dhuwur".
Yen komponen X padha, nanging komponen Y beda, sing nduweni nilai Y luwih dhuwur yaiku "versi sing luwih dhuwur".
Yen komponen XY padha, nanging komponen Z beda, sing nduweni nilai Z sing luwih dhuwur yaiku "versi sing luwih dhuwur". Nomer loro-bagean XY, kanggo tujuan iki, dianggep nomer telu bagean XY0.

Kanggo examp, nomer versi ing ngisor iki bakal saka urutan paling murah nganti versi paling dhuwur: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Kanggo CSS, saben nganyari mung nambah komponen X nomer versi.

Prasyarat persetujuan BoD
Ing pungkasan tahap Pengembangan Spesifikasi, persyaratan ing ngisor iki kudu dipenuhi sadurunge spesifikasi 0.9 / CR dikirim menyang BoD kanggo disetujoni:

WG wis ngrampungake analisis jangkoan tes.
BSTS wis rampung reviewing spesifikasi 0.9 / CR lan dokumen tes.
BARB wis nyetujoni spesifikasi 0.9 / CR.
BARB wis nyetujoni CSS CR (yen entri anyar dibutuhake spesifikasi) sing bisa ditempelake ing CR singkatan saka spesifikasi kasebut.
BARB wis nyetujoni GSS CR lan MDP CR (yen entri anyar dibutuhake kanthi spesifikasi).
BTI wis nyetujoni 0.9 / CR Test Suite, ICS, lan TCRL, bebarengan karo IXIT (yen dibutuhake IXIT kanggo nindakake tes ing Test Suite). TCRL opsional ing stage kanggo nganyari Spesifikasi Inti.
WG wis ngirim rencana tes IOP menyang BARB kanggo review (yen tes ora dibuwang dening BARB).

Dokumen sing diwenehake menyang BoD kudu kalebu spesifikasi 0.9 / CR sing disetujoni BARB, lan presentasi menyang BoD sing kudu kalebu:

Panjaluk sing dingerteni kanggo ngilangi pengujian IOP utawa syarat sing ditemtokake ing Bagean 4.3.1
Dhaptar transportasi sing didhukung karo spesifikasi (kayata, BR / EDR, LE. Lsp)
Kanggo paningkatan spesifikasi, ana pambebasan saka syarat kompatibilitas mundur (diterangake ing Bagean 3.3.2) sing dijaluk dening WG
Kanggo nambah spesifikasi, rekomendasi saka WG kanggo nomer versi sing ditrapake kanggo spesifikasi sing diadopsi
Kanggo paningkatan spesifikasi, rekomendasi pungkasan WG kanggo spesifikasi sing diadopsi versi sadurunge, kalebu alasan teknis kenapa penyusutan utawa penarikan versi spesifikasi sadurunge utawa ora disaranake, lan justifikasi kanggo rekomendasi
Ana uneg-uneg serius sing ora bisa dirampungake saka anggota BARB utawa BTI (umpamane, alesan ora ana swara suwene persetujuan, masalah sing anaview dokumen tes, utawa kuatir yen spesifikasi 0.9 / CR ana ing njaba jangkoan FRD utawa piagam)
Status persiyapan Profile Tuning Suite (PTS) utawa alat liya sing dibutuhake digandhengake karo adopsi sing disiapake dening BSTS

BoD bisa milih nyetujoni spesifikasi 0.9 / CR kanggo tes IOP kaya sing diwajibake dening Aturan [2], sadurunge BTI nyetujoni dokumen tes 0.9 / CR lan sadurunge WG negesake manawa rencana tes IOP nyukupi persyaratan sing ditemtokake ing Bagean 4.3.1. 0.9. BoD uga bisa nyetujoni spesifikasi 0.9 / CR kanggo tes IOP sawise disetujoni BTI dokumen tes XNUMX / CR.

0.9 / CR Stage syarat metu
0.9 / CR Stage rampung lan Tahap Validasi diwiwiti nalika BoD nyetujoni wiwitan tes IOP.

4.4 Pangentasan Proses Pangembangan Spesifikasi

WG bisa njaluk ngilangi siji utawa luwih saka langkah-langkah proses ing ngisor iki:

0.5 / DIPD Stage
0.7 / FIPD Stage
Tes IOP ing Tahap Validasi

Kanggo njaluk pengabaian, WG kudu nggunakake template waiver proses sing diwenehake dening Bluetooth SIG [8] lan ngirim panjaluk pengabaian menyang saben panitia (yaiku, BARB utawa BTI) sing dibutuhakeview utawa nyetujoni konsep spesifikasi utawa dokumen tes sing ana gandhengane ing stagmanawa WG usul ngilangi, lan masing-masing komite kasebut kudu nyetujoni panjaluk pengabaian.

Panjaluk pengabaian kudu kalebu ing ngisor iki:

Identifikasi stage (s) sing pengin dikepengini WG
Pembenaran kenapa stage (s) kudu dibebasake
Identifikasi saben panitia (yaiku, BTI lan / utawa BARB) sing dibutuhakeview lan nyetujoni panjaluk pengabaian

Panitia sing ngelingi pengabaian bisa uga mrentah supaya wakil saka WG nggawe presentasi kanggo mbenerake proses ngilangi proses SMPD sadurunge mutusake panjaluk pengabaian.

Yen panyuwunan njaluk ngilangi pirang-pirang langkah lan bagean saka penolakan kasebut ditolak lan bagean disetujoni, tanggapan panitia kudu nuduhake langkah-langkah ing panjaluk pengabaian sing disetujoni lan sing ditolak. Yen panjaluk ngilangi ditolak, notifikasi penolakan kudu kalebu sebab ditolak.

5. Tahap Validasi

Sajrone Tahap Validasi, WG bakal nindakake tes IOP ing spesifikasi 0.9 / CR kanthi tujuan ngirim laporan tes IOP kanggo BARB review lan persetujuan. Yen bisa, pangujian spesifikasi spesifikasi IOP kudu dileksanakake marang spesifikasi draf terintegrasi. Kajaba iku, Anggota Review, kaya sing diwajibake dening Undhang-undhang [2], diwiwiti sajrone tahap iki.

Yen spesifikasi (utawa paningkatan) ora mbutuhake pangujian IOP, mula pangujian IOP sajrone Tahap Validasi bisa dibebasake kanthi nggunakake proses sing diterangake ing bagean 4.4.

Sajrone tes IOP (sing bisa uga ana siji utawa luwih acara), WG kudu nglacak masalah nggunakake sistem pelacakan masalah Bluetooth SIG lan ngulang kanggo nggabungake pembaruan draf spesifikasi, dokumen tes, lan rencana tes IOP. Sawise tes IOP rampung, WG kudu ngrampungake update kanggo spesifikasi konsep lan dokumen tes kanggo ngatasi kabeh masalah, lan nyiapake lan ngirim laporan tes IOP menyang BARB kanggoview lan persetujuan. Iki digambarake ing Gambar 5.1.

Sajrone Tahap Validasi, ana sawetara kegiyatan sing bisa diwiwiti. Aktivitas kasebut bisa uga sejajar lan kalebu ing ngisor iki:

Spesifikasi sing disetujoni BoD 0.9 / CR kasedhiya kanggo kabeh anggota dening BSTS kanthi notifikasi babagan wiwitan Anggota Review periode sing dibutuhake dening Undhang-undhang.
Sembarang nganyari sing dibutuhake dilebokake ing CSS (sing bisa ditempelake ing CR sing disingkat spesifikasi).
Definisi karakteristik utawa deskriptor dilebokake ing spesifikasi GSS uga PTS kanggo tes IOP.
Definisi properti bolong kalebu ing spesifikasi MDP uga PTS kanggo tes IOP.
BSTS mbisakake registrasi platform IOP lan alat entri asil minangka persiyapan tes IOP.
Tes IOP, yen dibutuhake (deleng Bagean 5.1).
Review komentar lan masalah, kalebu sing diajukake minangka asil tes IOP, diproses lan pangowahan dilebokake ing konsep spesifikasi.

5.1 Tes IOP

Tujuan utama tes IOP yaiku kanggo validasi spesifikasi dening, kanggo mantanample, mriksa akurasi lan ambiguitas ing teks, reviewkanggo kesalahan lan kekurangan desain dhasar, lan menehi validasi tumrap syarat sing wis ditemtokake sadurunge sing dikembangake sadurunge ing proses pangembangan spesifikasi. Tes IOP bisa uga nyebabake owah-owahan spesifikasi draf lan sawetara kedadeyan tes IOP bisa uga dibutuhake kanggo ngrampungake kabeh tes sing dibutuhake.

Penting, supaya anggota ing njaba WG duwe kesempatan kanggo melu tes IOP amarga dheweke duwe independen view spesifikasi kasebut lan bisa nemokake area ambiguitas ing spesifikasi sing bisa uga ora dingerteni kanggo anggota WG sing nggawe rancangan kasebut. Sadurunge saben acara tes IOP, BSTS bakal menehi rincian acara, spesifikasi konsep paling anyar, Suite Suite, lan rencana tes IOP sing kasedhiya lan bakal menehi notifikasi marang kabeh anggota sewulan sadurunge saben acara. Rancangan spesifikasi draf sing dianyari, Suite Suite, lan rencana tes IOP sing digunakake ing acara tes IOP kudu kasedhiya paling ora seminggu sadurunge saben acara.

Sajrone tes IOP, kombinasi platform kanthi pasangan bakal nyoba nglakokake tes lan peserta pangujian IOP bakal nyathet asil sing lulus / gagal kanggo saben tes lan komentar. Ringkesan asil kasebut kanthi anonim (nuduhake eg, "Platform A", "Platform B", lan liya-liyane) lan komentar apa wae, bakal diklumpukake sajrone acara tes IOP lan kasedhiya kanggo anggota WG sajrone lan sawise IOP acara tes. Yen dibutuhake informasi tambahan kanggo entuk pangerten sing luwih apik babagan komentar utawa kegagalan sing kedadeyan sajrone tes IOP, BSTS bisa uga dadi perantara kanggo nglumpukake informasi luwih lengkap saka anggota sing ngirim.

Yen bisa, PTS kudu dianyari kanggo ndhukung tes IOP kanthi platform ing kabeh lapisan ing ndhuwur Host Controller Interface (HCI), lan saiki ana ing acara uji IOP kanggo lapisan kasebut. Alat uji coba liyane uga ana ing acara tes IOP. Ringkesan asil tes karo PTS utawa alat uji coba liyane (yen ana) kudu dilebokake ing laporan tes IOP.

Tes IOP bakal mbukak kanggo kabeh anggota sing pengin nyedhiyakake prototipe, nanging, Bluetooth SIG bisa uga duwe partisipasi nalika nampa perjanjian karo Bluetooth SIG (kalebu partisipasi lan perjanjian kerahasiaan). WG tanggung jawab kanggo ngolah lan ngrampungake masalah sing ditemokake sajrone tes IOP, lan nganyari dokumen sing kena pengaruh; Owahan sing disetujoni WG kudu dilebokake minangka nganyari update spesifikasi lan dokumen tes kanggo digunakake ing saben acara tes IOP.

Sadurunge Tahap Validasi, WG bisa nindakake tes IOP wiwitan ing acara sing mung mbukak anggota WG, nanging asil tes informal bisa uga ora kalebu ing asil tes IOP.

Muga-muga kabeh langkah sing nyebabake acara tes IOP pisanan ditindakake, kalebu tanggal lan lokasi IOP sing diumumake kanthi tujuan kanggo miwiti tes IOP, nanging persetujuan BoD durung dijamin sadurunge wiwitan acara tes. Ing kasus iki, BoD bisa ngidini kalebu asil tes sing dikoleksi sadurunge persetujuan BoD kanggo miwiti tes IOP, yen asil sing dikumpulake adhedhasar spesifikasi sing padha lan Test Suite sing disetujoni dening BoD.

Tes IOP ora dibutuhake kanggo nambah spesifikasi CSS, GSS, utawa MDP.

Laporan tes IOP
Sawise tes IOP rampung, WG kudu ngirim laporan tes IOP menyang BARB kanthi tujuan kanggo nuduhake manawa jumlah platform independen sing dibutuhake wis lulus tes sing dibutuhake. BARB kudu manehview lan nyetujoni utawa nolak laporan tes IOP lan bakal ngabari WG yen dibutuhake tes IOP tambahan sadurunge ngirim paket spesifikasi Draf Voting menyang BoD. BSTS lan WG kudu mesthekake ora ana informasi ngenali anggota sing ditampilake ing laporan tes IOP sadurunge ngirim laporan menyang BARB.

Laporan tes IOP kudu kalebu:

Dhaptar kabeh acara tes IOP sing kedadeyan sajrone Tahap Validasi kalebu tanggal lan dununge.
Nomer perusahaan anggota lan platform independen sing melu ing saben acara IOP, kalebu PTS digunakake.
Dhaptar spesifikasi, versi uji coba Suite, lan versi tes IOP sing digunakake ing saben acara.
Ringkesan eksekutif sing nyatakake manawa kabeh kasus uji coba wis memenuhi kriteria minimum pass.
Ringkesan sembarang variasi saka syarat rencana tes IOP sing ditemtokake ing Bagean 4.3.1 lan alesan kanggo saben varian.
Ringkesan jangkoan PTS kanggo kasus tes ing Test Suite.
Dhaptar kabeh kasus tes (kalebu tes kompatibilitas mundur) saka rencana tes IOP, jumlah tes sing dilewati, jumlah tes sing gagal, lan apa kriteria minimum sing dipenuhi saben kasus tes kalebu panjelasan kenapa ana syarat sing ora ketemu
Ringkesan masalah, komentar, lan pitakon ing saben acara (kalebu filed karo spesifikasi sajrone tes IOP) lan pengaruh menyang spesifikasi lan dokumen tes.

5.2 Persyaratan metu Fase Validasi

Tahap Validasi rampung lan Tahap Persetujuan / Adopsi diwiwiti nalika BARB wis nyetujoni laporan tes IOP (kajaba tes dibebasake dening BARB) lan kabeh syarat ing ngisor iki wis dipenuhi:

BSTS nyedhiyakake spesifikasi 0.9 / CR sing disetujoni kanggo kabeh anggota kanggo Re Anggotaview kaya sing diwajibake dening Undhang-undhang lan menehi kabar marang kabeh anggota kasedhiyan kasebut.
Kabeh masalah sing diidentifikasi sajrone tes IOP, lan sing duwe pengaruh tes, wis dilebokake lan dites.
WG wis ngrampungake tes IOP (kajaba uji coba dibuwang dening BARB).

6. Tahap Adopsi / Persetujuan

Sajrone Tahap Adopsi / Persetujuan, dokumen spesifikasi lan tes sing gegandhengan dirampungake, persetujuan BARB, BQRB, lan BTI ditampa, kabar tanggal Adopsi sing diusulake diterbitake bebarengan karo versi pungkasan konsep spesifikasi sing dikirim menyang BoD kanggo adopsi ( Voting Draft), lan paket spesifikasi pungkasan dikirim menyang BoD. Sawise dadi minimal anggota Review sing dibutuhake dening Undhang-undhang [2]) wis wareg, BoD bakal nimbang spesifikasi adopsi ing Tanggal Adopsi. Sawise diadopsi, spesifikasi diterbitake lan sistem kualifikasi diaktifake. Tahap Adopsi / Persetujuan digambarake ing Gambar 6.1.

6.1 Draf Voting

Voting Draft digawe kanthi nggabungake pembaruan (disedhiyakake ing Tahap Validasi) menyang dokumen spesifikasi sing dibutuhake, lan nyiyapake rancangan pungkasan spesifikasi anyar. Kanggo tambahan spesifikasi, BSTS bakal nggawe spesifikasi terintegrasi kanthi nggabungake siji utawa luwih CR menyang versi spesifikasi sing luwih dhuwur sadurunge (waca Bagean 4.3.2) yen durung rampung sadurunge Tahap Validasi.

Yen ana pangowahan spesifikasi sajrone fase iki lan WG, BARB, utawa BTI nemtokake manawa ana pangowahan mbutuhake tes IOP tambahan, spesifikasi kasebut bakal bali menyang bagean pengujian IOP saka Tahap Validasi kanggo WG kanggo nindakake tes tambahan. Sajrone Tahap Adopsi / Persetujuan, dokumen ing ngisor iki bakal lengkap lan kasedhiya ing BoD sadurunge Tanggal Adopsi:

Draf Voting
Kabeh spesifikasi pendukung (yaiku, CSS, GSS, MDP) kaya sing dibutuhake kanggo jinis spesifikasi (utawa tambahan) sing relevan, yen durung digunakake
Kanggo paningkatan spesifikasi, versi dilacak pangowahan saka versi spesifikasi adopsi sing nuduhake pangowahan sing diajokake ing Voting Draft
Katrangan saka WG babagan syarat kompatibilitas mundur (kaya sing diandharake ing Bagean 3.3.2) sing durung bisa dipenuhi lan sabdhoning kanggo ana pambebasan
Katrangan saka WG babagan syarat rencana tes IOP (kaya sing diandharake ing Bagean 4.3.1) sing durung bisa dipenuhi lan sabdhoning kanggo panyimpangan uga laporan tes IOP (sing bisa diwenehake kanthi menehi link menyang salinan ing SIG Bluetooth websitus)
Rekomendasi saka WG babagan penyusutan utawa penarikan versi sadurunge saka spesifikasi sing diadopsi bebarengan karo sabdhoning, nyorot pangowahan wiwit 0.9 / CR Stage rekomendasi pungkasane umur
Ringkesan, disiapake dening WG, kanggo ngganti fitur utawa fungsi wiwit spesifikasi 0.9 / CR (yen ana)
Ringkesan, disiapake dening BARB, babagan keprihatinan sing diunggahake dening anggota BARB manawa spesifikasi sing digawe dening WG ngluwihi jangkauan piagam sing disetujoni dening BoD (yen ana)
Dhaptar masalah hukum sing isih durung bisa diselesaikan saka re legalview (yen ana)
Suite Tes sing disetujoni BTI, uga ringkesan tes sing disetujoni WG saka spesifikasi Draf Voting. Yen fungsi sing mentas ditambahake utawa diowahi tanpa jangkoan tes, dibutuhake pembenaran nulis kanggo ngilangi
ICS lan IXIT sing disetujoni BTI (yen dibutuhake spesifikasi)
TCRL disetujoni dening BTI lan BQRB
Laporan sing disiapake dening BSTS bebarengan karo BTI babagan status kesiapan alat (kayata PTS lan alat uji coba liyane, Bluetooth Launch Studio) kalebu manawa kasus uji coba ing TCRL ora didhukung karo alat uji coba
Ringkesan, disiapake dening WG, kanggo kabeh nomer sing dibutuhake
Daftar priksa adopsi sing disiapake dening BSTS lan WG sing nuduhake manawa kabeh pengiriman ing bagean iki kabeh wis rampung
Kabeh informasi liyane sing dijaluk BoD

Sajrone Tahap Adopsi / Persetujuan, WG kudu nggunakake sistem pelacakan masalah Bluetooth SIG kanggo njupuk masalah lan komentar nglawan draf spesifikasi lan dokumen tes supaya bisa dipertanggungjawabake ing finalisasi spesifikasi Voting Draft. Kanggo paningkatan spesifikasi, kabeh errata sing disetujoni sing relevan (yaiku errata sing disetujoni durung integral) kudu dilebokake, lan kudu diidentifikasi nggunakake pangowahan sing dilacak.

WG kudu ngirim spesifikasi rancangan pungkasan menyang BSTS kanggo re legalview. Kanggo spesifikasi anyar, re legalview bakal kalebu kabeh spesifikasi. Kanggo tambahan spesifikasi, review bakal fokus utamane ing bagean sing wis ditemtokake. Tujuane re legalview utamane kanggo ngenali risiko hukum sing kudu ditrapake lan kudu dirampungake WG. Umpan balik legal bakal dikategorikake adhedhasar keruwetan. Yen re legal opsionalview ditindakake ing 0.9 / CR Stage, versi sing diajukake kanggo re legalview kudu ditampilake, minangka pangowahan sing dilacak, kabeh pangowahan sing digawe wiwit versi kasebut (digawe dening WG utawa BSTS). Sawise rampung re legalview, WG lan BSTS bakal setuju babagan saran sing bakal dilebokake ing spesifikasi konsep. Yen ana komentar legal sing ora bisa diselesaikan saka re legalview babagan draf spesifikasi, Ketua WG bisa uga njaluk agenda agenda BoD supaya setuju babagan resolusi.

Ing salaras karo re legalview, WG kudu ngirim draf spesifikasi menyang BARB kanggo review. Sawise dikirim dhisik menyang BARB, BSTS bakal ngabari kabeh anggota manawa draf spesifikasi wis dikirim menyang BARB kanggoview lan uga kasedhiya kanggo Anggota Review. Yen WG ngirimake update spesifikasi konsep kanggo BARB re-review, BSTS bakal ngirim kabar tambahan kanggo kabeh anggota kanthi rutin.

Sawise rampung BARB review, WG lan BARB bakal setuju babagan saran sing bakal dilebokake ing spesifikasi konsep.

Yen re legalview asil pangowahan substansial, tambahan review dening BARB bisa uga dibutuhake. Kajaba, yen BARB review ngasilake pangowahan substansial, BSTS bakal nemtokake manawa re legal tambahanview pangowahan kasebut dibutuhake. Sawise rampung re legalview lan BARB review, BARB kudu nyetujoni utawa nolak Draft Voting.

Yen ana dokumen tes sing kudu dianyari, BSTS bakal ngewangi WG kanggo nganyari dokumen tes. BTI kudu nyetujoni utawa nolak dokumen tes. Yen disetujoni dening BTI, BTI bakal mbantu ngrampungake TCRL lan ngirim dokumen iki menyang BQRB bebarengan karo ICS, IXIT, lan Test Suite sing gegandhengan. BSTS bakal ngramal tanggal rapat BoD nalika BoD arep milih adopsi Voting Draft (Tanggal Adopsi) lan nyedhiyakake BTI kanggo digunakake ing TCRL. Persetujuan spesifikasi BARB, persetujuan BTI kanggo kabeh dokumen tes (kalebu Test Suite, TCRL, ICS, lan IXIT), lan persetujuan BQRB saka TCRL kudu kedadeyan ing utawa sadurunge Tanggal Adopsi.

BSTS bakal ngandhani kabeh anggota babagan finalisasi lan kasedhiyan Draft Voting lan Tanggal Adopsi. Tanggal Adopsi bakal ditemtokake ora luwih saka 60 dina sawise para anggota diwenehi kabar babagan spesifikasi 0.9 / CR sing disetujoni BoD, kajaba Anggota Review periode dicekak dening BoD sesuai karo Undhang-undhang, lan paling ora 14 dina sawise kabar Tanggal Adopsi diwenehake kanggo anggota miturut Undhang-undhang. Kanggo kasus ing pirang-pirang CR wis digabung dadi Voting Draft, wiwitan Anggota Review yaiku tanggal nalika anggota diwenehi kabar babagan CR sing paling anyar sing disetujoni BoD.

Sawise diwenehi kabar babagan Tanggal Adopsi diwenehake kanggo anggota, koreksi sing disetujoni BoD kanggo kesalahan tipografi ing Voting Draft diidini. Timeline Spesifikasi Adopsi digambarake ing Gambar 6.2.

6.2 Nomer sing ditugasake

Bluetooth SIG njaga set nomer sing ditugasake ing publik ing Nomer Ditugasake Bluetooth SIG websitus [7]. Nomer sing ditugasake diklumpukake ing macem-macem spasi (sawetara nomer sing gegandhengan tanpa duplikat). Nomer sing ditugasake bisa tumpang tindih karo nomer liyane sing ditugasake ing macem-macem spasi, nanging ora ana nomer ing papan nomer sing diidini digunakake maneh. Macem-macem ruang nomer ditetepake ing spesifikasi sing nemtokake panggunaan nomer sing wis ditemtokake.

Sawise BARB nyetujoni laporan tes IOP, WG bakal ngirim panjaluk menyang BARB kanggo menehi nomer anyar ing ruang nomer sing dibutuhake spesifikasi pungkasan. BARB bakal manehview panjaluk lan kerja karo BSTS kanggo nemtokake nomer sing wis ditemtokake. Sawise disetujoni BARB, BSTS bakal gawe jadwal publikasi nomer sing ditugasake supaya kasedhiya ing publik ing Nomer Ditugasake Bluetooth SIG websitus [7] sajrone seminggu wiwit nggunakake spesifikasi kasebut.

Sawise diterbitake nomer sing diwenehake ing Nomer Ditugasake Bluetooth SIG websitus utawa ing spesifikasi sing diadopsi, nomer sing ditetepake dimaksudake supaya ora bisa diowahi (ora bisa owah ing salah sawijining nilai utawa makna). Yen ora bisa digunakake amarga ana sebab, dheweke dadi nilai sing dilindhungi undhang-undhang lan ora diidini digunakake maneh.

6.3 Persyaratan metu Fase Adoption / Persetujuan

Tahap Persetujuan / Adopsi lengkap nalika BoD wis nggunakake spesifikasi lan kegiatan pasca adopsi ing ngisor iki wis rampung:

BSTS wis nyedhiyakake nomer pungkasan sing diwenehake ing publik ing SIG Bluetooth websitus.
BSTS wis nggawe spesifikasi sing kasedhiya ing publik ing SIG Bluetooth websitus
BSTS nggawe kabeh dokumen pendukung (kayata CSS, GSS, MDP) sing dibutuhake kanggo spesifikasi sing relevan sing kasedhiya ing publik ing SIG Bluetooth websitus.
BSTS nyedhiyakake dokumen tes sing gegandhengan kanggo kabeh anggota ing Bluetooth SIG websitus.
Kanggo paningkatan spesifikasi, BSTS wis nggawe versi sing dilacak kanthi informatif saka versi spesifikasi sing sadurunge digunakake karo kabeh pangowahan sing digawe karo versi sing mentas diadopsi lan kasedhiya kanggo kabeh anggota ing Bluetooth SIG websitus.
BSTS wis ngaktifake sistem kualifikasi.
BSTS wis ngabari kabeh anggota babagan spesifikasi adopsi lan kabeh dokumen pendukung.

Bluetooth SIG berencana ngrampungake kegiatan pasca adopsi kasebut sajrone seminggu sawise nggunakake spesifikasi kasebut.

7. Fase Pangopènan Spesifikasi

Fase Pangopènan Spesifikasi diwiwiti sawise Fase Adopsi / Persetujuan rampung. Yen ditemokake masalah (kayata, ambiguitas tembung utawa kesalahan teknis) kanthi spesifikasi utawa dokumen tes sing gegandhengan, dokumen kasebut kudu didokumentasikake kanthi nggawe proposal errata nggunakake alat Bluetooth SIG Errata. Usulan erratum spesifikasi bakal diproses, dikategorikake, lan disetujoni miturut EPD [3]. Erratum Test Suite diproses lan dikategorikake miturut TSTO [5]. Yen ana konflik antarane SMPD lan EPD utawa TSTO, SMPD dadi prioritas utama.

Erratum spesifikasi mung kudu digunakake kanggo mbenerake kesalahan teknis utawa editorial ing spesifikasi Bluetooth pungkasan. Tambahan, pangowahan menyang, lan ngilangi fungsi mung bisa ditindakake kanthi proses paningkatan spesifikasi sing wis ditemtokake sadurunge ing dokumen iki.

7.1 Proses erratum sing dipercepat

Nalika erratum disetujoni sawise proses sing ditemtokake ing EPD [3], WG, BARB, utawa BSTS bisa menehi saran supaya dianggep penting banget lan kudu disepetake. Yen kedadeyan kasebut, BSTS bebarengan karo WG utawa BARB bakal menehi rekomendasi kasebut menyang BoD. BoD bakal mutusake apa bakal nampa utawa nolak rekomendasi kasebut. Yen rekomendasi kasebut ditampa, BSTS bakal langsung nggabungake erratum sing wis disetujoni menyang template erratum [8] lan kerja bareng WG sing tanggung jawab kanggo ngrampungake Koreksi Errata sing Cepet kanggo diajukake menyang WGview lan persetujuan.

Lan liwatview proses erratum sing dipercepat digambarake ing Gambar 7.1.

Dokumen ing ngisor iki kudu lengkap lan kasedhiya ing BoD sadurunge Tanggal Adopsi:

Draf sing disetujoni BARB Disepetake Errata Koreksi.
Katrangan saka WG babagan syarat kompatibilitas mundur (kaya sing diandharake ing Bagean 3.3.2) sing durung bisa dipenuhi lan sabdhoning kanggo pengecualian.
Dhaptar masalah hukum sing isih durung bisa diselesaikan saka re legalview (yen ana).
Suite Test sing disetujoni BTI, ICS, lan IXIT (yen dibutuhake dening erratum).
TCRL sing disetujoni BTI- lan BQRB (yen dibutuhake dening erratum).
Laporan sing rampung dening BSTS bebarengan karo BTI babagan status kesiapan alat (kayata PTS lan alat uji coba liyane, Bluetooth Launch Studio) kalebu manawa kasus uji coba ing TCRL ora didhukung alat uji coba lan panjelasan (yen dibutuhake dening erratum ).
Daftar priksa adopsi sing dirampungake dening BSTS lan WG sing nuduhake manawa pengiriman ing bagean iki kabeh wis rampung.
Kabeh informasi liyane sing dijaluk BoD.

BSTS bakal bisa nggarap WG sing tanggung jawab kanggo ngrampungake draf Koreksi Errata Cepet lan nggawe versi kanggo dikirim menyang WG sing tanggung jawab.view lan persetujuan.

WG kudu ngirim Koreksi Errata Cepet menyang BSTS kanggo re legalview. Sawise rampung re legalview, WG lan BSTS bakal setuju babagan saran sing bakal dilebokake ing Koreksi Errata sing Cepet. Yen ana komentar legal sing ora bisa diselesaikan saka re legalview babagan Koreksi Errata sing Disepetake, Ketua WG bisa uga njaluk agenda agenda BoD kanggo njaluk input BoD babagan resolusi.

Ing salaras karo re legalview, WG kudu ngirim Koreksi Errata Cepet menyang BARB kanggo review. Sawise Koreksi Errata Cepet dikirim menyang BARB, BSTS bakal bisa diakses kabeh anggota bisa milih manehview lan ngabari kabeh anggota kasedhiyan kasebut. Sawise rampung BARB review, WG lan BARB bakal setuju babagan saran sing bakal dilebokake ing Koreksi Errata sing Disepetake.

Yen ana dokumen tes sing kudu dianyari, BSTS bakal ngewangi WG kanggo nganyari dokumen tes. Sawise disetujoni BTI saka dokumen tes, BTI bakal mbantu ngrampungake TCRL lan ngirim dokumen kasebut menyang BQRB bebarengan karo ICS, IXIT, lan Test Suite sing ana gandhengane. BSTS bakal ngramal Tanggal Adopsi lan diwenehake menyang BTI kanggo digunakake ing TCRL. Persetujuan BARB saka Koreksi Errata Cepet, persetujuan BTI kanggo kabeh dokumen tes (kalebu Suite Suite, TCRL, ICS, lan IXIT sing ditrapake), lan persetujuan BQRB saka TCRL kudu kedadeyan ing utawa sadurunge Tanggal Adopsi.

BSTS bakal ngandhani kabeh anggota babagan finalisasi lan kasedhiyan Koreksi Errata Cepet lan Tanggal Adopsi sing diusulake. Tanggal Adopsi bakal disetel lan dilaporake menyang kabeh anggota miturut Aturan [2] lan Tanggal Adopsi paling ora 14 dina sawise kabar kasebut diwenehake marang anggota. Sawise kabar babagan Tanggal Adopsi sing diusulake diwenehake kanggo para anggota, BoD bisa uga nyetujoni koreksi kesalahan tipografi ing Koreksi Errata sing Cepet tanpa menehi kabar tambahan babagan Tanggal Adopsi sing diusulake lan ngenteni 14 dina sing dibutuhake.

Bluetooth SIG bakal nyedhiyakake Koreksi Errata Cepet sing kasedhiya ing umum lan rencana ditindakake sajrone seminggu sawise diadopsi. Kabar babagan kasedhiyan bakal ditanggepi dening BSTS kanggo kabeh anggota.

Proses erratum sing dipercepat rampung nalika BoD wis nggunakake Koreksi Errata Cepet lan kegiyatan pasca adopsi ing ngisor iki wis rampung:

BSTS nggawe Koreksi Errata Cepet lan dokumen tes sing gegandhengan (yen dibutuhake dening erratum) kasedhiya ing publik ing SIG Bluetooth websitus.
BSTS wis ngaktifake sistem kualifikasi (yen dibutuhake dening erratum).
BSTS wis ngabari kabeh anggota babagan kasedhiya Koreksi Errata Cepet.

Sawise rampung kegiyatan kasebut, Koreksi Errata bakal dijadwalake integrasi menyang spesifikasi sing kena pengaruh minangka bagean saka spesifikasi spesifikasi sing direncanakake utawa rilis pangopènan mbesuk kaya sing diterangake ing Bagean 7.2

7.2 Proses rilis perawatan (.Z spesifikasi)

Kira-kira saben taun, BSTS bakal nemtokake manawa ana kesalahan sing disetujoni (diarani Koreksi Errata) sing diklasifikasikake dadi Teknis / Dhuwur utawa Teknis / Kritik lan sing durung dilebokake ing teks babagan spesifikasi aktif (yaiku, spesifikasi sing diadopsi sing durung uwal utawa ditarik maneh). Deleng Apendiks A kanggo definisi klasifikasi kesalahan. Pamilik Spesifikasi (bisa uga chartered WG kanggo njaga spesifikasi, utawa BARB yen ora ana WG sing dijadwalake kanggo njaga spesifikasi) uga njaluk rilis perawatan sing luwih dhisik saka spesifikasi aktif kanggo nggabungake errata sing wis disetujoni. Sawise ditemtokake ing BSTS, utawa panjaluk saka Pamilik Spesifikasi, proses peluncuran pangopènan bakal diwiwiti.

Lan liwatview proses rilis pangopènan digambarake ing Kesalahan! Sumber referensi ora ditemokake.

Ing wiwitan proses rilis pangopènan, BSTS bebarengan karo Pamilik Spesifikasi, BARB, lan BTI bakal nggawe lan menehi rencana menyang BoD kanggo nggabungake Koreksi Errata menyang versi spesifikasi sing diterbitake. Rencana sing diusulake kudu nuduhake manawa Koreksi Errata bakal dilebokake ing rilis perawatan spesifikasi (yaiku versi .Z) utawa peningkatan spesifikasi sing wis ditindakake (yaiku versi XY). Rencana sing diusulake kudu dipikirake manawa ana fitur wajib anyar sing ditambahake ing antarane versi spesifikasi sing diadopsi, perkiraan wektu nalika penambahan spesifikasi sabanjure direncanakake kanggo adopsi, lan faktor liyane.

Sawise disetujoni rencana dening BoD, BSTS lan Pemilik Spesifikasi bakal melu nggabungake kabeh Koreksi Teknis / Medium, Teknis / Dhuwur, lan Teknis / Kritik menyang rancangan spesifikasi sing diarani "Draft Rilis Pemeliharaan". Kanggo Koreksi Editorial utawa Teknis / Kurang Errata, yen Koreksi Errata ditrapake kanggo luwih saka siji versi spesifikasi, BSTS bakal, kajaba BoD nuduhake liya, nggabungake kesalahan kasebut dadi mung versi spesifikasi sing paling anyar sing paling anyar ing nganyari sabanjure versi kasebut . Ora ana pangowahan sing bisa dilebokake ing Draft Rilis Maintenance kajaba nggabungake Koreksi Errata. Saben Draft Rilis Maintenance kudu ngenali kabeh Koreksi Errata sing dilebokake nggunakake pelacakan pangowahan kanggo nuduhake perubahan sing diusulake menyang versi spesifikasi sing sadurunge diadopsi.

Wektu penggabungan sing diusulake kanggo saben Koreksi Errata ing Draf Rilis Pemeliharaan bakal gumantung karo pengaruh Suite Suite: kabeh Koreksi Errata sing ora duwe pengaruh Suite Suite bisa uga dilebokake, nanging Koreksi Errata sing kena pengaruh ing Suite Suite bakal diproses supaya wektu cocog karo nganyari TCRL.

BTI lan BSTS bakal nggawe tenggat wektu kanggo kalebu Koreksi Errata kanthi pengaruh Suite Suite ing Draft Rilis Maintenance. Tenggat wektu iki biasane 3 nganti 6 wulan sadurunge tanggal persetujuan sing direncanakake kanggo rilis TCRL utama sabanjure. Koreksi Errata kanthi dampak Test Suite sing ora kejawab deadline kanggo dilebokake bakal diproses minangka bagean saka rilis TCRL tahunan sabanjure. Mula, kajaba yen dijaluk rilis luwih dhisik, wektu maksimal kanggo Koreksi Errata Teknis / Dhuwur utawa Teknis / Kritik kalebu ing pembaruan spesifikasi udakara 15 nganti 18 wulan.

Pamilik Spesifikasi kudu ngirim Draft Rilis Maintenance sing wis disetujoni minangka final kanggo re legalview. Re sahview bakal fokus utamane ing bagean sing wis ditemtokake. Sawise rampung re legalview, Pamilik Spesifikasi lan BSTS bakal setuju babagan saran sing bakal dilebokake ing Draft Rilis Maintenance. Yen ana komentar legal sing ora bisa diselesaikan saka re legalview ing Draft Rilis Maintenance, Pemilik Spesifikasi bisa njaluk wektu ing agenda BoD kanggo njaluk input BoD babagan resolusi.

Ing salaras karo re legalview, pemilik Spesifikasi kudu ngirim Draft Rilis Maintenance menyang BARB kanggo review. Sawise Draft Rilis Maintenance dikirim menyang BARB, BSTS bakal bisa diakses kabeh anggota bisa milih manehview lan ngabari kabeh anggota kasedhiyan kasebut. Sawise rampung BARB review, Pamilik Spesifikasi lan BARB bakal setuju babagan saran sing bakal dilebokake ing spesifikasi konsep.

Kanggo Koreksi Errata sing nyebabake dokumen tes, lan ing endi kesalahan uji coba sing cocog bakal diproses ing wektu rilis TCRL mbesuk, BSTS bakal kerja bareng karo Pamilik Spesifikasi lan BTI kanggo nganyari dokumen tes. Sawise disetujoni BTI dokumen tes, BSTS bakal ngramal Tanggal Adopsi lan menehi Tanggal Adopsi sing diusulake menyang BTI kanggo digunakake ing TCRL. BTI bakal ngirim TCRL menyang BQRB bebarengan karo ICS, IXIT, lan Test Suite sing gegandhengan kaya sing ditrapake. Persetujuan BARB kanggo spesifikasi, persetujuan BTI kanggo kabeh dokumen tes (kalebu Test Suite, TCRL, ICS, lan IXIT sing ditrapake), lan persetujuan BQRB saka TCRL kudu kedadeyan ing utawa sadurunge Tanggal Adopsi.

BSTS bakal ngandhani kabeh anggota babagan finalisasi lan kasedhiyan Draft Voting lan Tanggal Adopsi sing diusulake. Tanggal Adopsi bakal disetel lan dilaporake menyang kabeh anggota miturut Undhang-undhang lan Tanggal Adopsi paling ora 14 dina sawise kabar kasebut diwenehake menyang anggota. Sawise kabar babagan Tanggal Adopsi sing diusulake diwenehake kanggo para anggota, BoD bisa uga nyetujoni koreksi kesalahan tipografi ing Voting Draft tanpa menehi kabar tambahan babagan Tanggal Adopsi sing diusulake lan ngenteni 14 dina sing dibutuhake.

Dokumen ing ngisor iki kudu lengkap lan kasedhiya ing BoD sadurunge Tanggal Adopsi:

Draf Voting
Versi Voting Draft sing dilacak sing nuduhake kabeh pangowahan menyang versi spesifikasi sing duwe nilai XY sing padha (kayata, yen Voting Draft diusulake minangka versi 1.4.2, pangowahan bakal dilacak marang 1.4.1 versi spesifikasi)
Rekomendasi saka Pamilik Spesifikasi babagan panyusutan utawa penarikan versi sadurunge saka spesifikasi sing diadopsi bebarengan karo pembenaran
Dhaptar masalah hukum sing isih durung bisa diselesaikan saka re legalview (yen ana)
Suite Test sing disetujoni BTI, ICS, lan IXIT (yen dibutuhake rilis pangopènan)
TCRL sing disetujoni BTI- lan BQRB (yen dibutuhake rilis pangopènan)
Laporan sing rampung dening BSTS bebarengan karo BTI babagan status kesiapan alat (kayata PTS lan alat uji coba liyane, Bluetooth Launch Studio) kalebu kasus uji coba ing TCRL sing ora didhukung alat uji coba, lan panjelasan (yen dibutuhake pangopènan ngeculake)
Daftar priksa adopsi sing dirampungake dening BSTS lan Pemilik Spesifikasi sing nuduhake manawa pengiriman ing bagean iki kabeh wis rampung
Kabeh informasi liyane sing dijaluk BoD

Proses rilis pangopènan rampung nalika BoD nggunakake Draft Voting lan kegiatan pasca adopsi ing ngisor iki wis rampung:

BSTS wis nggawe spesifikasi adopsi lan dokumen tes sing gegandhengan (yen dibutuhake rilis pangopènan) kasedhiya ing publik ing SIG Bluetooth websitus.
BSTS wis nggawe versi sing dilacak pangowahan informatif saka versi spesifikasi sing sadurunge digunakake kanthi kabeh pangowahan sing tergabung ing versi sing nembe diadopsi sing kasedhiya kanggo kabeh anggota ing Bluetooth SIG websitus.
BSTS wis ngaktifake sistem kualifikasi.
BSTS wis ngabari kabeh anggota babagan kasedhiya spesifikasi lan dokumen dhukungan.

Bluetooth SIG berencana ngrampungake kegiatan pasca adopsi kasebut sajrone seminggu sawise nggunakake spesifikasi kasebut.

Sawise rampung kegiyatan kasebut, spesifikasi kasebut tetep ana ing fase Maintenance Spesifikasi nganti spesifikasi kasebut ora digunakake utawa ditarik maneh, kaya sing ditegesake ing Bagean 8.

8. Fase End-of-Life Spesifikasi

Spesifikasi bisa uga ora digunakake utawa ditarik maneh nalika diganti karo versi sing luwih anyar, sing ditemtokake ora cukup teknis, utawa amarga alasan liyane. Spesifikasi sing mundur lan ditarik wis diarsipake lan ora dianyari maneh. Spesifikasi sing mundur lan ditarik dianggep beda ing Program Kualifikasi Bluetooth.

Sembarang anggota, klompok, utawa panitia bisa ngirim rekomendasi supaya ora nggunakake utawa mbatalake spesifikasi, uga karo timeline sing gegandhengan karo BSTS (liwat email menyang

specification.manager@blu Bluetooth.com) sawayah-wayah. BSTS bisa uga menehi saran babagan penyusutan utawa penarikan spesifikasi lan timeline sing gegandhengan. BSTS bakal menehi rekomendasi menyang BARB lan klompok utawa panitia sing tanggung jawab njaga spesifikasi review lan umpan balik.

BARB lan klompok utawa panitia sing tanggung jawab bakal ngevaluasi rekomendasi kanggo nyuda utawa mbatalake spesifikasi lan nimbang kriteria ing ngisor iki (ora lengkap):

Apa ana fungsi ing versi spesifikasi sadurunge sing wis uwal utawa ora digunakake?
Apa fungsi wajib anyar wis ditambahake menyang versi sing luwih anyar?
Apa ana kekurangan ing versi sadurunge sing ngganggu operasi utawa interoperabilitas sing wis didandani ing versi sabanjure lan dibutuhake kanggo ningkatake skenario pangguna sing wis ana?
Apa ana fungsi tambahan ing versi sabanjure sing dibutuhake kanggo ningkatake skenario pangguna anyar?
Apa ana panggunaan lan interoperabilitas sing luwih apik ing versi sabanjure?
Apa ana perbaikan keamanan ing versi sabanjure?

BARB lan klompok utawa panitia sing tanggung jawab bisa ngusulake rekomendasi alternatif.

Sawise nampa umpan balik saka BARB utawa klompok utawa panitia sing tanggung jawab njaga spesifikasi kasebut, BSTS bakal ngirim rekomendasi lan umpan balik menyang BoD kanggo dipertimbangkan. BoD bisa ngundang klompok utawa panitia sing tanggung jawab njaga spesifikasi sing kena pengaruh kanggo ketemu lan ngrembug babagan rekomendasi kasebut. BoD bakal nimbang rekomendasi lan saran lan bisa setuju utawa ngowahi proposal kasebut. BoD bakal njaluk supaya BSTS ngabari kabeh anggota usulan-usulan supaya ora nggunakake utawa mbatalake spesifikasi lan timeline sing gegandhengan kanggo regane 30 dinaview wektu kanggo ngidini kabeh anggota menehi saran tambahan sadurunge njupuk keputusan pungkasan.

BoD bakal nimbang saran sing ditampa saka anggota. Sawise BoD nyetujoni penyusutan utawa penarikan spesifikasi, BSTS bakal ngabari kabeh anggota keputusan lan timeline sing gegandhengan.

8.1 Ngeculake

Sawise spesifikasi dihentikan, ing ngisor iki bakal kedadeyan:

Spesifikasi kasebut ora bakal dianyari maneh.
WG sing tanggung jawab bakal manehview kabeh errata pinunjul sing ditulis nglawan spesifikasi sing ora digunakake maneh kanggo nemtokake manawa ditrapake kanggo spesifikasi liyane. Errata bisa ditolak ing sistem errata lan ditulis maneh marang spesifikasi sing ditrapake.
WG utawa BSTS bakal nggawe errata kanggo nganyari referensi sing dibutuhake kanggo spesifikasi sing wis ilang ing spesifikasi liyane.
BTI bakal nganyari dokumen tes sing ditrapake kanggo nuduhake spesifikasi sing kurang.
BSTS bakal nganyari SIG Bluetooth websitus kanthi pandhuan babagan spesifikasi alternatif sing bakal digunakake.
Kesalahan anyar ora bisa diajukake maneh karo spesifikasi sing wis udan.
Spesifikasi kasebut ora bakal dirujuk ing spesifikasi mbesuk.
BSTS bakal arsip versi spesifikasi sing ditandhani ora nggunakake anggota kanggo ngakses sejarah.

8.2 Penarikan

Sawise spesifikasi ditarik, saliyane kanggo langkah-langkah sing ora ditrapake, ing ngisor iki bakal kedadeyan:

BTI bakal nganyari dokumen tes sing ditrapake kanggo nunjukake penarikan spesifikasi kasebut.
BSTS bakal nganyari SIG Bluetooth websitus kanthi pandhuan babagan spesifikasi alternatif sing bakal digunakake.
BSTS bakal arsip versi spesifikasi sing ditandhani minangka ditarik kanggo anggota supaya bisa diakses kanthi tujuan sejarah.

BoD bisa milih mbatalake spesifikasi kanthi cepet tanpa nyuda spesifikasi kasebut.

9. Proses kertas putih

Kertas putih digawe mung kanggo informasi. Proses kertas putih ing ngisor iki ditrapake kanggo kabeh WG Bluetooth, EG, SG, lan komite. Bagean iki ora ditrapake kanggo dokumen informasi sing mung digunakake ing Bluetooth SIG.

Proses iki digambarake ing Gambar 9.1 ing ngisor iki.

Sadurunge klompok utawa panitia miwiti makarya ing kertas putih sing dienggo diterbitake dening Bluetooth SIG, klompok utawa panitia kasebut bakal nyiapake pembaruan charter sing diusulake kanthi jelas nemtokake isi proposal kertas putih lan presentasi proposal kertas putih.

Presentasi proposal kertas putih kudu kalebu paling ora:

Kebutuhan kertas putih
Ringkesan isi proposal kertas putih sing diusulake
Katrangan kenapa konten ora disaranake kalebu ing spesifikasi
Pamirsa sing dituju
Apa wae rencana pangopènan (yaiku, kira-kira wektu sadurunge rilis kertas putih sabanjure dibutuhake)
Rekomendasi cara ngatasi versi kertas putih sadurunge, yen ana (contone, pengarsipan)

Nganyari piagam lan presentasi proposal kertas putih kudu dikirim menyang BARB review. Nalika review lan disetujoni nganyari charter dening BARB, BSTS bakal ngirim pembaruan charter menyang BoD kanggo disetujoni lan uga presentasi proposal kertas putih.

Yen BoD nyetujoni pembaruan charter, klompok utawa panitia bisa nerusake nggawe kertas putih.

Yen klompok utawa panitia ngrampungake pangembangan kertas putih, BSTS bakal nindakake editorial review kanggo konsistensi karo Pedoman Panyusunan Bluetooth.

Sawise resolusi komentar BSTS, grup kudu ngirim kertas putih menyang BSTS kanggo re legalview. Sawise rampung re legalview, klompok lan BSTS bakal setuju babagan saran sing bakal dilebokake ing kertas putih. Yen ana komentar legal sing ora bisa diselesaikan saka re legalview ing kertas putih, ketua klompok bisa uga njaluk agenda agenda BoD kanggo njaluk input BoD babagan resolusi.

Ing salaras karo re legalview, klompok kasebut kudu ngirim kertas putih menyang BARB kanggo review. Minangka bagéan saka re singview, BARB bisa menehi saran apa bagean saka kertas putih kasebut kudu dicopot saka kertas putih lan dilebokake ing spesifikasi sawise proses ing Babagan 3. BARB uga bisa mutusake ngirim kertas putih menyang klompok utawa komite liyane.view. Sawise rampung BARB review, grup lan BARB bakal setuju babagan saran sing bakal dilebokake ing kertas putih.

Sawise BARB nyetujoni kertas putih, kertas putih sing disetujoni BARB bakal diwenehake dening klompok panulis utawa panitia menyang BoD kanggo disetujoni.

Proses kertas putih rampung nalika BoD wis nyetujoni kertas putih lan kegiatan pasca-persetujuan ing ngisor iki wis rampung:

BSTS nggawe kertas putih sing disetujoni kasedhiya ing publik ing SIG Bluetooth websitus.
BSTS ngabari kabeh anggota kertas putih sing disetujoni.
Yen kertas putih minangka tambahan saka kertas putih sing wis ana, BSTS bakal arsip versi kertas putih kanggo akses para anggota kanggo tujuan sejarah.

Bluetooth SIG berencana ngrampungake kegiatan pasca-persetujuan sajrone seminggu sawise disetujoni kertas putih.

10. Referensi

Dokumen Bluetooth sing dirujuk kasedhiya saka Bluetooth websitus http://www.bluetooth.com.

Pedoman Panyusunan Bluetooth (kasedhiya ing kaca Cithakan & Dokumen Kelompok Pakaryan, ing https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Undhang-undhang Bluetooth SIG, Inc. (kasedhiya ing kaca Dokumen Pimpinan, ing https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Dokumen Proses Errata Spesifikasi Bluetooth (kasedhiya ing kaca Cithakan & Dokumen Grup Makarya, ing https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Dokumen Proses Grup Makarya (kasedhiya ing kaca Cithakan & Dokumen Grup Makarya, ing https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Strategi Tes lan Terminologi Liwatview dokumen (kasedhiya ing kaca Kebutuhan Tes Kualifikasi, ing https://www.bluetooth.com/specifications/qualification-test-requirements)
Spesifikasi BTI Review Dhaptar Priksa Proses (kasedhiya ing kaca Cithakan & Dokumen Kelompok Kerja, ing https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Nomer Ditugasake Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Cithakan lan Dokumen Kelompok Kerja (kasedhiya ing kaca Cithakan & Dokumen Kelompok Kerja, ing https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Suplemen Spesifikasi GATT (GSS) (kasedhiya ing kaca Spesifikasi GATT, ing https://www.bluetooth.com/specifications/gatt)
Kirim Idea kanggo Spesifikasi anyar https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Akronim lan singkatan

Tabel A: Akronim lan singkatan

Apendiks A - Klasifikasi keruwetan Erratum

Lampiran iki ngringkes pedoman klasifikasi keruwetan kanggo erratum spesifikasi. Tabel iki bakal ditambahake ing revisi EPD mbesuk, lan banjur bagean iki bakal dibusak.

Waca Liyane Babagan Manual Iki & Unduh PDF:

Dokumen Proses Manajemen Spesifikasi (SMPD) - PDF sing dioptimalake
Dokumen Proses Manajemen Spesifikasi (SMPD) - PDF Asli

Pitakonan babagan Manual sampeyan? Kirim ing komentar!

Referensi

Manual pangguna