Dokumen Proses Pengurusan Spesifikasi (SMPD)

Dokumen ini, tanpa mengira tajuk atau kandungannya, bukan Spesifikasi Bluetooth yang tertakluk kepada lesen yang diberikan oleh Bluetooth SIG Inc. (“Bluetooth SIG”) dan anggotanya di bawah Perjanjian Lesen Paten / Hak Cipta Bluetooth dan Perjanjian Lesen Tanda Dagangan Bluetooth.

DOKUMEN INI DISEDIAKAN "SEBAGAIMANA ADANYA" DAN BLUETOOTH SIG, AHLI, DAN SEKUTU MEREKA TIDAK PERWAKILAN ATAU WARANTI DAN MENAFIKAN SEMUA WARANTI, YANG NYATA ATAU TERSIRAT, TERMASUK SEBARANG WARANTI KEBOLEHDAGANGAN, HAK MILIK, BUKAN PELANGGARAN, KESESUAIAN UNTUK TUJUAN TERTENTU, BAHAWA KANDUNGAN DOKUMEN INI TIDAK ADA KESALAHAN.

KEPADA LUAR BIASA YANG TIDAK DILARANG OLEH UNDANG-UNDANG, BLUETOOTH SIG, ANGGOTANYA, DAN ANGGOTA MEREKA MENAFIKAN SEMUA TANGGUNGJAWAB YANG TELAH ATAU BERKAITAN DENGAN PENGGUNAAN DOKUMEN INI DAN SEBARANG MAKLUMAT YANG TERLIBAT DALAM DOKUMEN INI, TERMASUK, HILANG, ATAU PRODUK YANG HILANG, PROFIT GANGGUAN, ATAU UNTUK KEROSAKAN KHUSUS, TIDAK LANGSUNG, BERSEPADU, INSIDEN ATAU PUNITIF, BAGAIMANA YANG MENYEBABKAN DAN TIDAK BERKAITAN TEORI TANGGUNGJAWAB, DAN BAHKAN JIKA TANDA BLUETOOTH, ANGGOTANYA, ATAU AFFILIATE MEREKA ADA.

Dokumen ini adalah hak milik Bluetooth SIG. Dokumen ini mungkin mengandungi atau merangkumi perkara yang menjadi hak intelektual Bluetooth SIG dan ahlinya. Penyediaan dokumen ini tidak memberikan lesen kepada harta intelek Bluetooth SIG atau ahli-ahlinya.

Dokumen ini tertakluk kepada perubahan tanpa notis.

1. Pengenalan

Dokumen Proses Pengurusan Spesifikasi (SMPD) menerangkan proses yang penulis dan re spesifikasiviewMereka harus mengikuti untuk mengembangkan spesifikasi baru dan untuk meningkatkan spesifikasi yang ada (iaitu, untuk menambah atau menghapus fungsi atau untuk mengubah fungsi tertentu dalam spesifikasi yang diadopsi), untuk mengekalkan spesifikasi yang diadopsi, dan untuk mengatur akhir hayat spesifikasi yang diadopsi. Sebagai tambahan, dokumen ini menerangkan proses untuk membuat, semulaviewdan meluluskan kertas putih.

Terdapat perbezaan dalam proses pengembangan spesifikasi antara mengembangkan spesifikasi baru dan meningkatkan spesifikasi yang ada kerana perbezaan yang melekat dalam ruang lingkup tugas-tugas tersebut; perbezaan tersebut diserlahkan dalam dokumen ini.

Proses pengembangan spesifikasi merangkumi:

Fasa Keperluan (dijelaskan dalam Bahagian 3) untuk menentukan keperluan fungsional

Fasa Pembangunan (dijelaskan dalam Bahagian 4) untuk dikembangkan dan dikembangkan kembaliview spesifikasi
Fasa Pengesahan (dijelaskan dalam Bahagian 5) untuk mengesahkan spesifikasi dengan menggunakan ujian Prototaip Beroperasi (IOP)

Fasa Adopsi / Persetujuan (dijelaskan dalam Bahagian 6) untuk menyampaikan spesifikasi kepada Lembaga Pengarah Bluetooth (Direksi) untuk adopsi / persetujuan

Dokumen Spesifikasi Proses Errata (EPD) [3] menerangkan proses untuk mencadangkan dan mengulangviewspesifikasi errata, dan menyetujuinya sebagai Errata Corrections (seperti yang ditentukan dalam Peraturan [2]) untuk menggunakan spesifikasi. Kecuali dinyatakan sebaliknya, semua rujukan ke errata dalam SMPD ini bermaksud errata spesifikasi.

1.1 Keutamaan

The Bylaws of Bluetooth SIG, Inc. (Bylaws) dan perjanjian keahlian [2] diutamakan daripada kandungan yang bertentangan dalam dokumen tersebut dan SMPD. Walau apa pun yang terdapat dalam dokumen ini, Direksi mempunyai budi bicara dan wewenang utama untuk mengambil tindakan dan membuat keputusan walaupun tindakan dan keputusan tersebut tidak mengikuti, atau bertentangan dengan, apa pun dalam dokumen ini, dan tidak ada apa-apa dalam dokumen ini yang membatasi atau menyekat pihak berkuasa bebas dan budi bicara.

Sekiranya terdapat percanggahan antara teks dalam SMPD dan angka, teks itu diutamakan.

1.2 Kumpulan dan jawatankuasa yang dirujuk

Jenis kumpulan berikut dirujuk dalam dokumen ini: Kumpulan Kajian (SG), Kumpulan Pakar (EG), dan Kumpulan Kerja (WG). WG mungkin juga mempunyai subkumpulan yang melaporkan kepada WG. Begitu juga, jenis jawatankuasa berikut dirujuk dalam dokumen ini: Bluetooth Architectural Review Board (BARB), Uji dan Interoperabiliti Bluetooth (BTI), dan Kelayakan Bluetooth Review Dewan (BQRB). Dokumen ini juga merujuk kepada Staf Teknikal Bluetooth SIG (BSTS), dan Lembaga Pengarah.

1.3 Jawatankuasa semulaviews dan kelulusan

Sebuah jawatankuasa semulaview adalah review yang dijalankan oleh anggota jawatankuasa (biasanya 3 anggota) untuk memberikan maklum balas dalam masa yang ditentukan (biasanya 2-3 minggu), namunview masa mungkin berbeza bergantung pada panjang dan kerumitan bahan dan keutamaan lain dalam jawatankuasa. Kumpulan yang meminta semulaview dan jawatankuasa yang menjalankan review masing-masing bersetuju dengan tempoh semulaview. Kumpulan dan ahli jawatankuasa menggunakan alat Bluetooth SIG untuk memberitahu dan merekodkan permulaan dan akhir review. Kumpulan biasanya akan memproses maklum balas jawatankuasa apabila ia diterima. Apabila jawatankuasa semulaview masa tamat, kumpulan selesai menjawab maklum balas jawatankuasa, dan juga harus mempertimbangkan kembali yang lambat datangview maklum balas yang diingat bahawa bahan tersebut mungkin akan dipersetujui oleh jawatankuasa berikutnya.

Kelulusan jawatankuasa diperoleh dengan suara ahli jawatankuasa yang mematuhi Dokumen Proses Kumpulan Kerja [4].

1.4 Pemberitahuan kepada anggota dan kebolehcapaian bahan

Semua pemberitahuan yang diberikan kepada ahli menurut dokumen ini mungkin diberikan melalui e-mel, seperti kemas kini teknikal berkala. Pemberitahuan yang akan diberikan kepada semua anggota akan dikirimkan kepada semua anggota yang aktif (iaitu, di mana keanggotaan belum ditangguhkan, diberhentikan, atau ditarik balik). Apabila pemberitahuan diemail, mereka akan dihantar ke alamat e-mel yang terakhir (seperti yang ditunjukkan dalam rekod Bluetooth SIG ketika ini) setiap individu yang telah mendaftar di bawah akaun keahlian syarikat ahli dan yang tidak memilih untuk tidak menerima pemberitahuan e-mel. Tidak ada apa-apa dalam dokumen ini yang mengubah kewajiban atau syarat Bluetooth SIG berkenaan dengan pemberitahuan di bawah Peraturan tersebut atau perjanjian lain antara Bluetooth SIG dan mana-mana ahli.

Di mana sahaja dokumen ini merujuk kepada a weblaman web yang boleh diakses oleh semua ahli, ini merujuk kepada kebolehcapaian kepada individu yang mempunyai akaun Bluetooth SIG yang aktif. Ahli yang tidak mempunyai akaun aktif boleh membuat akaun melalui Bluetooth SIG webtapak.

1.5 Templat

Untuk setiap jenis dokumen (contohnya, spesifikasi, kertas putih, dokumen ujian) yang disebut dalam SMPD ini, Bluetooth SIG menyediakan templat. Templat mesti digunakan sebagai asas untuk setiap dokumen yang dihasilkan sesuai dengan SMPD ini. Kegagalan menggunakan templat yang betul boleh mengakibatkan dokumen tersebut tidak diluluskan. Templat boleh didapati di Bluetooth SIG weblaman web [8].

1.6 Jenis Spesifikasi

Terdapat beberapa jenis spesifikasi Bluetooth SIG. Secara hierarki, semua spesifikasi bergantung pada Spesifikasi Teras Bluetooth. Spesifikasi seperti pro tradisionalfiles; protokol tradisional; dan pro berasaskan GATTfiles, perkhidmatan berasaskan GATT, dan protokol berasaskan GATT semuanya bergantung pada ciri-ciri dalam Spesifikasi Teras. Spesifikasi lain, seperti spesifikasi Model Mesh, bergantung pada Mesh Profile spesifikasi yang bergantung pada Spesifikasi Teras.

Spesifikasi Core Spesifikasi Tambahan (CSS) menentukan jenis data, format data, dan pro umumfile dan kod ralat perkhidmatan yang digunakan oleh Spesifikasi Teras dan spesifikasi lain dan tidak mentakrifkan sendiri sebarang tingkah laku.

Spesifikasi GATT Specification Supplement (GSS) menentukan format ciri dan deskriptor yang digunakan oleh Profiles dan Perkhidmatan dan tidak mentakrifkan sendiri sebarang tingkah laku.
Spesifikasi Mesh Device Properties (MDP) menentukan sifat mesh yang digunakan oleh Mesh Profile dan spesifikasi Model Mesh dan tidak mentakrifkan sendiri sebarang tingkah laku.

2. Lebihview

Bahagian ini memberikan overview proses dan tidak bertujuan untuk merangkumi semua butiran.

Rajah 2.1 menunjukkan enam fasa utama yang membentuk Proses Pengurusan Spesifikasi.

Empat fasa pertama berlaku semasa proses pengembangan spesifikasi dan terdiri dari Fasa Keperluan (Bahagian 3), Fasa Pengembangan (Bahagian 4), Fasa Pengesahan (Bahagian 5), dan Fasa Penerapan / Persetujuan (Bahagian 6). Ini diikuti oleh dua fasa pasca-adopsi: Fasa Pemeliharaan Spesifikasi (Bahagian 7) dan Fasa Akhir Kehidupan Spesifikasi (Bahagian 8).

Gambar 2.2 menggambarkan perincian empat fasa dalam proses pengembangan spesifikasi. Kotak kelabu menunjukkan penyampaian utama untuk setiap fasa. Kotak oren merangkum tonggak proses.

Dalam Tahap Keperluan (dijelaskan dalam Bagian 3), proposal untuk memulai pekerjaan baru (Proposal Kerja Baru (NWP)) memulai proses pengembangan spesifikasi dengan menentukan senario pengguna yang akan diaktifkan jika pekerjaan baru tersebut dilanjutkan. Sekiranya NWP diluluskan, kumpulan yang ditugaskan membuat Dokumen Keperluan Fungsional (FRD). Setelah FRD diluluskan dan diberikan kepada kumpulan, Fasa Pembangunan akan bermula.

Selama Tahap Pembangunan (dijelaskan dalam Bahagian 4), pengembangan spesifikasi berlangsung melalui urutan stages (0.5 / DIPD hingga 0.9 / CR) memuncak dalam rancangan lengkap spesifikasi. Spesifikasi 0.9 / CR disediakan untuk semua anggota, kemudian diserahkan kepada Direksi yang mempertimbangkan spesifikasi tersebut untuk disetujui. Setelah diluluskan, Fasa Pengesahan bermula.

Selama Tahap Pengesahan pengembangan spesifikasi (dijelaskan dalam Bahagian 5), spesifikasi 0.9 / CR yang disetujui oleh Direksi disediakan untuk semua anggota untuk kembaliview dan mengesahkan, dan Ahli Review dimulakan. Pengesahan dilakukan melalui ujian interoperabiliti (IOP) antara prototaip yang dibina oleh anggota. Setelah ujian IOP selesai (jika diperlukan untuk spesifikasi) dan BARB menyetujui laporan ujian IOP, maka Fasa Adopsi / Persetujuan akan dimulakan.

Selama Tahap Adopsi / Persetujuan (dijelaskan dalam Bahagian 6), spesifikasi dan dokumen ujian yang berkaitan diselesaikan; Kelulusan BARB, BQRB, dan BTI diterima; dan pakej spesifikasi akhir diserahkan kepada Direksi yang mempertimbangkan spesifikasi untuk diadopsi (iaitu, persetujuan akhir).

Spesifikasi mungkin perlu kembali ke fasa sebelumnyatage sekiranya perubahan ketara dilakukan. Dalam beberapa kasus, juga mungkin untuk melepaskan sebahagian fasa seperti yang dijelaskan dalam Bahagian 4.4.

Fasa Pemeliharaan Spesifikasi (dijelaskan dalam Bahagian 7) dimulai setelah suatu spesifikasi diadopsi oleh Direksi. Selama fasa ini kesalahan yang mungkin ditemukan dalam spesifikasi yang diadopsi dilaporkan dan dinilai, dan (jika diperlukan) Pembetulan Kesalahan dibuat terhadap spesifikasi. Fasa Pemeliharaan Spesifikasi berlanjutan hingga spesifikasi tidak digunakan lagi atau ditarik balik (lihat Fasa Akhir Kehidupan Spesifikasi pada paragraf berikut).

Fasa Akhir Kehidupan Spesifikasi (dijelaskan dalam Bahagian 8) menjelaskan proses penghentian dan penarikan spesifikasi yang diterima pakai.

3. Fasa Keperluan

Fasa Keperluan bermula sama ada dengan NWP (yang menyatakan keinginan untuk memulakan kerja pada satu atau lebih senario pengguna) atau setelah penentuan bahawa karya baru yang diinginkan sudah dilindungi oleh piagam WG mereka. Sekiranya WG ingin memulakan pekerjaan baru yang diyakini sudah berada dalam ruang lingkup piagam WGnya, WG mesti mengikuti proses yang ditentukan dalam Bahagian 3.1 untuk terus mengembangkan FRD. Untuk semua item kerja lain, WG mesti mengikuti proses yang ditentukan dalam Bahagian 3.2. FRD menentukan skop keperluan fungsional yang digunakan untuk membina spesifikasi dalam Fasa Pembangunan. Fasa Keperluan digambarkan dalam Rajah 3.1.

3.1 Kerja baru yang diliputi oleh piagam WG

Apabila WG ingin memulakan kerja baru dan secara munasabah percaya bahawa fungsi yang ingin ditambahkannya sudah berada dalam ruang lingkup piagam WGnya, WG dapat mulai bekerja pada FRD, dengan syarat mereka segera memberitahu BARB. WG akan memasukkan dalam pemberitahuannya kepada BARB penerangan mengenai karya baru yang dicadangkan dan salinan piagam WG dengan bahasa yang disorot yang memberi wewenang kepada mereka untuk memulakan karya baru.

Sekiranya BARB menolak analisis WG, WG mesti berhenti bekerja pada FRD dan meneruskan proses NWP yang digariskan dalam Bahagian 3.2. Sekiranya BARB menyetujui analisis WG, WG akan segera memberitahu BSTS (melalui e-mel ke specification.manager@bluetooth.com) dan BSTS akan menambahkan item tersebut ke agenda BoD berikutnya.

WG akan memasukkan dalam pemberitahuannya kepada BSTS maklumat yang sama yang diberikannya kepada BARB. Sekiranya Lembaga Pengarah menolak analisis WG, WG mesti berhenti bekerja pada FRD dan meneruskan proses NWP yang digariskan dalam Bahagian 3.2. Sekiranya Lembaga Pengarah menyetujui analisis WG, WG dapat terus mengerjakan FRD seperti yang digariskan dalam Bahagian 3.3.

3.2 Cadangan Kerja Baru (NWP)

Mana-mana ahli, WG, SG, atau EG boleh membuat dan menyerahkan NWP (melalui Bluetooth SIG weblaman web [10]). NWP mesti memasukkan, sekurang-kurangnya, maklumat mengenai perkara berikut menggunakan templat rasmi yang disediakan dalam [8]:

Senario pengguna
Komitmen anggota untuk mengembangkan FRD dan di bidang apa (misalnya, Penyumbang, Pengarang, Reviewer, Prototaip)
Cadangan kepemimpinan kerja FRD
Cadangan tugasan kumpulan untuk kerja FRD
Alamat e-mel pengarang utama

Nota: Panduan mengenai proses NWP terdapat di Bluetooth SIG weblaman web [10].

BSTS akan melaksanakan tugas-tugas berikut semasa pengembangan NWP:

Berikan pengakuan penerimaan kepada penulis (biasanya dalam masa tujuh hari kalendar sejak penerimaan) dan gariskan langkah-langkah seterusnya.
Sekiranya perlu, bekerjasama dengan pengarang supaya NWP jelas dan lengkap. Ini mungkin memerlukan beberapa lelaran NWP.
Sekiranya NWP mengandungi pernyataan mengenai kesalahan dalam spesifikasi Bluetooth yang diadopsi, bekerjasama dengan penulis untuk file kemasukan ke dalam sistem errata.
Sekiranya diperhatikan bahawa NWP berpotensi menggandakan karya yang sudah dijalankan atau sudah selesai, beritahu penulis karya lain untuk penilaian mereka.
Kirim NWP ke NWP weblaman web boleh diakses oleh semua ahli.

Maklumkan kepada semua ahli bahawa NWP ada untuk digunakan semulaview dan adakah komitmen anggota tambahan untuk mengembangkan FRD diperlukan.

Anggota boleh menghubungi penulis untuk mengemukakan pertanyaan atau memberi maklum balas mengenai NWP.

Sekurang-kurangnya tiga syarikat anggota mesti berkomitmen untuk berpartisipasi dalam penyelesaian FRD yang dihasilkan agar NWP menjadi calon persetujuan Direksi, dan sekurang-kurangnya satu syarikat anggota mesti menjadi anggota Bersekutu atau Promoter. Setelah mendapat persetujuan NWP, BoD akan menyerahkan NWP kepada subkumpulan WG atau SG yang ada untuk bekerja di FRD (dijelaskan dalam Bahagian 3.3). Sekiranya subkumpulan WG atau SG yang sesuai tidak wujud, satu kumpulan mungkin dibuat.

Untuk NWP yang mempunyai komitmen anggota yang mencukupi, BSTS akan melakukan tugas tambahan berikut:

Sekurang-kurangnya 13 hari sebelum NWP diusulkan untuk disetujui oleh Direksi, beri tahu BARB, dan kumpulan yang disarankan NWP untuk penugasan, mengenai persetujuan NWP yang sedang menunggu keputusan. Ini dilakukan untuk memberi peluang untuk maklum balas dalam bidang seperti kumpulan yang dicadangkan, sama ada NWP sudah dilindungi oleh pekerjaan yang ada, dll.
Serahkan NWP yang telah dilengkapkan ke Lembaga Pengarah.

Sekiranya NWP diserahkan oleh anggota yang tidak berkaitan dengan kumpulan, aturlah salah seorang anggota untuk membentangkan NWP kepada Lembaga Pengarah.

Sekiranya NWP diserahkan oleh kumpulan, atur ketua kumpulan untuk menyampaikan NWP kepada Lembaga Pengarah.
Jemput ketua BARB dan ketua kumpulan, yang disarankan oleh NWP untuk ditugaskan, ke mesyuarat Lembaga Pengarah.
Sekiranya NWP diluluskan dan ditugaskan oleh Lembaga Pengarah, beritahu kumpulan yang ditugaskannya; penulis); anggota yang dikenalpasti di NWP berkomitmen untuk membangun FRD yang sesuai; dan jika NWP dicadangkan oleh satu kumpulan, kumpulan hasilnya dan langkah seterusnya.

Setelah NWP diluluskan oleh Lembaga Pengarah, kemas kini status di NWP webtapak.

Sebarang NWP boleh ditolak oleh Lembaga Pengarah mengikut budi bicaranya, untuk bekasampOleh kerana keterbatasan sumber daya, jika pekerjaan tersebut sudah selesai sepenuhnya, pekerjaan tersebut berada di luar ruang lingkup dokumen yang mengatur Bluetooth SIG (mis., Antaramuka Pengaturcaraan Aplikasi (API)) [2], atau jika karya yang diusulkan harus filed sebagai erratum. Sekiranya NWP ditolak, BSTS akan memberitahu penulis, anggota yang dikenal pasti di NWP berkomitmen untuk mengembangkan FRD yang sesuai, dan, jika NWP diusulkan oleh kumpulan, kumpulan tersebut. Pemberitahuan akan merangkumi sebab penolakan. Pengarang, anggota yang berkomitmen, atau kelompok dapat meminta waktu dalam agenda Dewan Direksi untuk mengajukan banding atas penolakan tersebut.

Sekiranya ahli atau kumpulan ingin mencadangkan penghapusan ciri dari spesifikasi yang diterima pakai, kumpulan atau ahli mesti menyediakan NWP. NWP mesti merangkumi analisis mengenai kesan yang akan dilakukan oleh penyingkiran terhadap keserasian dan interoperabilitas ke belakang, termasuk analisis mengenai kesan pada kes ujian.

NWP tidak diperlukan untuk penambahbaikan pada spesifikasi CSS, GSS, atau MDP: biasanya, kemas kini pada spesifikasi CSS, GSS, atau MDP dihasilkan daripada kemas kini ke spesifikasi lain yang mempunyai NWP mereka sendiri.

3.3 Dokumen Keperluan Fungsional (FRD)

FRD menentukan keperluan fungsional untuk membolehkan senario pengguna. FRD mesti memasukkan, sekurang-kurangnya, maklumat mengenai perkara berikut menggunakan templat rasmi yang disediakan dalam [8]:

Senario pengguna
Keperluan fungsional berdasarkan senario pengguna
Komitmen anggota untuk mengembangkan spesifikasi yang dihasilkan
Sokongan prototaip pilihan oleh ahli untuk peranan yang diharapkan
Disarankan WG untuk mengembangkan spesifikasi yang dihasilkan

Pembangunan FRD

FRD dibuat oleh subkumpulan WG semua anggota atau anggota SG yang ditugaskan dengan sokongan editorial dari BSTS. Mana-mana ahli yang berminat untuk menyertai pembangunan FRD boleh menyertai kumpulan ini.

FRD mesti menunjukkan komitmen dari sekurang-kurangnya dua (walaupun tiga digalakkan) syarikat anggota peringkat Bersekutu atau Promoter untuk turut serta dalam pengembangan spesifikasi yang dihasilkan. WG atau SG yang mengirimkan FRD harus berusaha untuk mendapatkan sokongan luas dari syarikat anggota kumpulan yang mewakili segmen industri sasaran yang dimaksudkan yang dikenal pasti dalam FRD.

Fungsi baharu yang dicadangkan dalam FRD harus disokong pada seberapa banyak pengangkutan dan peranti sedia ada yang mungkin. Ini termasuk, contohnyaample, menyokong pro berasaskan GATTfiles dan perkhidmatan pada pengangkutan Kadar Asas / Kadar Data Lanjutan (BR / EDR) dan pengangkutan Tenaga Rendah Bluetooth (LE). Sekiranya fungsi baru tidak mempunyai sokongan anggota yang mencukupi untuk pengangkutan, misalnyaampOleh kerana kurangnya komitmen anggota untuk menentukan penggunaan pengangkutan atau sejumlah platform ujian IOP yang berpotensi tidak mencukupi untuk satu atau lebih peranan, sokongan untuk pengangkutan tersebut mungkin dikeluarkan dari FRD.

Melainkan dibenarkan sebaliknya, fungsi baharu, profiles, dan perkhidmatan mesti mematuhi syarat keserasian mundur yang dijelaskan dalam Bahagian 3.3.2.

WG atau SG mesti menyerahkan FRD ke BARB untuk diulangview dan kelulusan. BARB mesti meluluskan atau menolak FRD berdasarkan penilaian kejuruteraannya. Sekiranya diluluskan oleh BARB, FRD akan disediakan untuk semua anggota dan pemberitahuan mengenai ketersediaannya akan dikeluarkan oleh BSTS.

FRD tidak diperlukan untuk penambahbaikan pada spesifikasi CSS, GSS, atau MDP: biasanya, kemas kini ke spesifikasi CSS, GSS, atau MDP dihasilkan dari kemas kini ke spesifikasi lain yang mempunyai FRD mereka sendiri.

Keperluan keserasian ke belakang

Keserasian ke belakang untuk BR / EDR

Untuk operasi BR / EDR, keperluan keserasian ke belakang ditakrifkan sebagai interoperasi dengan bahagian BR / EDR dari Spesifikasi Teras Bluetooth v1.1 dan yang lebih baru.

Keserasian ke belakang untuk Tenaga Rendah Bluetooth

Untuk operasi LE, keperluan keserasian ke belakang ditakrifkan sebagai interoperasi dengan bahagian LE dari Spesifikasi Teras Bluetooth v4.0 dan yang lebih baru.

Keserasian ke belakang untuk spesifikasi selain daripada Spesifikasi Teras

Untuk spesifikasi selain daripada Spesifikasi Teras Bluetooth, keserasian versi yang diberikan mesti dikekalkan dengan semua versi sebelumnya yang mempunyai nombor versi utama yang sama. Untuk bekasample, versi 1.3 mesti serasi dengan versi 1.2, 1.1, dan 1.0, tetapi versi 2.0 mungkin tidak sesuai dengan versi 1.0, 1.1, 1.2, dan 1.3. Perhatikan bahawa kenaikan nombor versi utama Spesifikasi Teras tidak menunjukkan kekurangan keserasian ke belakang dengan versi sebelumnya.

Pengecualian dari syarat keserasian ke belakang

WG atau SG mungkin mengusulkan untuk mengecualikan fungsi tertentu dari keperluan keserasian ke belakang jika justifikasi diberikan. Untuk bekasampJika fungsi tersebut menunjukkan kadar penggunaan pasaran yang rendah atau, kerana masalah interoperabilitas, lebih baik menghapus atau mengganti fungsi daripada mengubah fungsi. WG atau SG mesti memasukkan pengecualian keserasian ke belakang dalam FRD, yang disetujui oleh BARB setelah mendapat persetujuan FRD. Sebarang pengecualian yang disetujui oleh BARB akan dikemukakan kepada Dewan untuk mendapat persetujuan di 0.9 / CR Stage.

3.4 Piagam Kumpulan Kerja

Apabila BARB menyetujui FRD yang diusulkan untuk ditugaskan ke WG yang ada, WG mesti menyiapkan draf kemas kini piagamnya untuk menambahkan fungsi baru ke ruang lingkup (kecuali jika BoD sebelumnya telah menyetujui analisis WG bahawa kemas kini piagam WG adalah tidak dikehendaki). Namun, ketika BARB menyetujui FRD yang diusulkan untuk ditugaskan ke WG baru, BARB dan anggota yang berminat untuk mengembangkan fungsi yang digariskan dalam FRD mesti menyiapkan draf piagam untuk WG baru dengan fungsi baru yang termasuk dalam skop piagam .

Setelah piagam WG yang baru atau yang dikemas kini disiapkan, ia mesti diserahkan kepada BARB untuk disusun semulaview dan kelulusan. Setelah BARB menyetujui piagam tersebut, draf piagam WG baru atau yang dikemas kini akan diserahkan kepada Direksi untuk persetujuan.

Setelah Lembaga Pengarah menyetujui piagam tersebut, WG yang menjadi tugas pengembangan spesifikasi yang ditugaskan oleh Direksi mesti bekerjasama rapat dengan kumpulan yang menyiapkan FRD sekiranya diperlukan pembaruan atau penjelasan yang diperlukan untuk FRD tersebut. Sekiranya kemas kini FRD diperlukan semasa Fasa Pembangunan, proses yang digariskan dalam Bahagian 3.3 dan bahagian ini mesti diikuti; namun, pengembangan spesifikasi mungkin berlaku selari dengan kemas kini piagam FRD dan WG.

3.5 Keperluan Keperluan keluar fasa

Fasa Keperluan selesai dan Fasa Pembangunan bermula apabila piagam WG dengan skop yang diperlukan untuk FRD sama ada disahkan atau diluluskan oleh Lembaga Pengarah dan syarat-syarat berikut telah dipenuhi:

NWP telah disetujui oleh Direksi, atau Dewan telah bersetuju bahawa NWP tidak diperlukan.
Piagam FRD dan WG yang sesuai telah disetujui oleh BARB.

4. Fasa Pembangunan

Selama Tahap Pembangunan, WG yang ditugaskan membuat spesifikasi baru dan / atau meningkatkan spesifikasi yang ada. FRD menentukan keperluan spesifikasi Bluetooth baru atau dipertingkatkan. Tidak ada fungsi yang dibenarkan dalam spesifikasi yang tidak beralasan dengan keperluan dalam FRD. Objektifnya adalah untuk membuat spesifikasi 0.9 / CR yang siap untuk Fasa Pengesahan (dijelaskan dalam Bahagian 5) pada akhir Tahap Pembangunan.
Semasa Tahap Pembangunan, spesifikasi (atau peningkatan spesifikasi) maju melalui tiga stages.

Untuk spesifikasi baru, ketiga stages ialah:

0.5 Stage
0.7 Stage
0.9 Stage

Untuk peningkatan spesifikasi, ketiga stages ialah:

Dokumen Cadangan Penambahbaikan Draf (DIPD) Stage
Dokumen Cadangan Penambahbaikan Akhir (FIPD) Stage
Permintaan Perubahan (CR) Stage

Setiap stage dijelaskan lebih lanjut dalam bahagian-bahagian berikut. Gambar 4.1 di bawah menunjukkan pelbagai dokumen yang akan disediakan oleh WG pada setiap detiktage.

Gambar 4.1: Lebihview dari spesifikasi stagyang berlaku semasa Fasa Pembangunan

Peranan BARB sepanjang proses pengembangan spesifikasi adalah memberi nasihat dan bantuan teknikal kepada WG. WG dapat, pada bila-bila masa, membuat permintaan kepada BARB untuk mendapatkan nasihat teknikal mengenai pengembangan spesifikasi dan konsep seni bina untuk digunakan dalam suatu spesifikasi. WG sangat digalakkan untuk meminta maklum balas awal dari BARB untuk ciri yang mempunyai pertimbangan seni bina yang lebih kompleks.

4.1 0.5 / DIPD Stage

Semasa 0.5 / DIPD Stage, WG akan mengembangkan yang berikut menggunakan templat rasmi yang disediakan di [8]:

Untuk spesifikasi baru, draf spesifikasi 0.5, yang mesti memasukkan, sekurang-kurangnya, maklumat mengenai yang berikut:

Senibina untuk memenuhi keperluan seperti yang dinyatakan dalam FRD
Untuk protokol, titik akses perkhidmatan ditentukan
Untuk perkhidmatan, data dan tingkah laku yang terdedah
Untuk profiles, protokol yang dikenal pasti dan fungsi ditentukan

2. Untuk penambahbaikan spesifikasi, draf DIPD, yang harus memuat, minimal, informasi mengenai hal berikut:

latar belakang: Skop kerja, objektif membimbing kerja, dan bagaimana cadangan khusus ini sesuai dengan skop

Berakhirview cadangan: Ringkasan fungsi yang diperluas (fleksibiliti tambahan, peningkatan prestasi, dll.) Yang disediakan oleh DIPD termasuk penerangan yang jelas mengenai bagaimana fungsi baru sesuai dengan versi spesifikasi semasa. Sekiranya WG telah menilai beberapa cadangan, cadangan ini harus disertakan untuk memberi peluang kepada BARB untuk menentukan apakah usaha wajar dibuat dalam pemilihan cadangan yang disukai.
Perlindungan syarat: Ringkasan liputan keperluan fungsional yang diberikan oleh proposal, dengan merujuk kepada keperluan sistem dan senario penggunaan yang sesuai yang diberikan dalam FRD terkait
Definisi masalah: Penyataan masalah yang diselesaikan oleh cadangan

Kriteria pemilihan: Pernyataan mengenai pemilihan / kriteria prestasi dari metrik penilaian yang berkaitan yang telah memandu proses pemilihan
Justifikasi pilihan: Pemeriksaan metrik penilaian yang membenarkan pilihan antara cadangan dan mengungkapkan pertukaran
Penerangan: Penerangan mengenai fungsi dan protokol tambahan. Bahagian ini dapat menyesuaikan diri dengan keperluan yang berbeza dengan menambahkan sub-bahagian yang relevan.

3. Strategi Ujian: Gambaran fungsi yang dicadangkan untuk diuji (atau tidak diuji) sebagai sebahagian daripada Program Kelayakan Bluetooth dan bagaimana fungsi yang dicadangkan untuk diuji (misalnya, jangkaan pada Penguji Bawah atau Penguji Atas, dan jika ujian akan dikaitkan sebagai ujian kesesuaian atau interoperabiliti atau gabungan kedua-duanya). Ini mungkin terdapat dalam dokumen berasingan atau bahagian terpisah dalam spesifikasi 0.5 / DIPD. Konvensyen yang akan digunakan dalam Strategi Uji dijelaskan dalam Strategi Uji dan Terminologi Lebihview dokumen (TSTO) [5].

Penonton utama dokumen di s initage adalah ahli WG dan BARB yang kembaliview cadangan seni bina dan liputan keperluan, dan BTI yang semulaviews Strategi Ujian. Dalam kebanyakan kes, dokumen di s initage tidak dimaksudkan untuk memuat teks yang direncanakan untuk dimasukkan dalam spesifikasi akhir.

BSTS mesti kembaliview semua dokumen untuk konsisten dengan Garis Panduan Penggubalan Bluetooth [1] dan mengenal pasti isu untuk ditangani oleh WG. BARB mesti semulaview spesifikasi 0.5 / DIPD. Untuk peningkatan spesifikasi, BARB juga mesti kembaliview DIPD untuk pematuhan dengan keperluan keserasian mundur yang dijelaskan dalam Bahagian 3.3.2. BTI mesti kembaliview Strategi Ujian.

BARB mesti meluluskan atau menolak spesifikasi 0.5 / DIPD berdasarkan penilaian kejuruteraannya. Sekiranya diluluskan oleh BARB, spesifikasi 0.5 / DIPD akan tersedia di Bluetooth SIG weblaman web kepada semua anggota Bersekutu dan Promotor dan pemberitahuan ketersediaannya akan dikeluarkan oleh BSTS. Pada 0.5 / DIPD Stage, persetujuan Strategi Ujian tidak diperlukan.
The 0.5 / DIPD Stage tidak diperlukan untuk peningkatan pada spesifikasi CSS, GSS, atau MDP

0.5 / DIPD Stagsyarat keluar

The 0.5 / DIPD Stage lengkap dan 0.7 / FIPD Stage bermula apabila syarat keluar berikut dipenuhi:

BSTS telah menyelesaikan semulaviewmenggunakan spesifikasi dan Strategi Ujian 0.5 / DIPD.

BARB telah meluluskan spesifikasi 0.5 / DIPD.
BTI telah menyelesaikan semulaview Strategi Ujian.
BSTS telah membuat spesifikasi 0.5 / DIPD yang diluluskan tersedia untuk semua anggota Associate dan Promoter.

4.2 0.7 / FIPD Stage

Semasa 0.7 / FIPD Stage, WG akan mengembangkan yang berikut menggunakan templat rasmi yang disediakan di [8]:

Untuk spesifikasi baru, draf spesifikasi 0.7, yang mesti memasukkan, sekurang-kurangnya, maklumat mengenai yang berikut:

Penjelasan mengenai semua perubahan yang dibuat sejak BARB disetujui 0.5, termasuk cadangan baru atau diubah, kriteria pemilihan, dan pembenaran pilihan. Perubahan mesti dijelaskan pada tahap perincian yang sama seperti yang diperlukan dalam 0.5 Stage.
Semua keperluan berfungsi dari FRD ditangani.

2. Untuk penambahbaikan spesifikasi, draf FIPD, yang harus memuat, minimal, informasi mengenai hal berikut:

Penjelasan mengenai semua perubahan yang dilakukan sejak DIPD yang disetujui oleh BARB, termasuk proposal baru atau diubah, kriteria pemilihan, dan pembenaran pilihan. Perubahan mesti dijelaskan pada tahap perincian yang sama seperti yang diperlukan dalam DIPD Stage.

Sekiranya perlu, kawasan yang dikembangkan lebih lanjut yang dijelaskan dalam Bahagian 4.1 mengenai DIPD.
Penerangan lengkap mengenai penambahbaikan.
Huraian seni bina yang dikemas kini.
Semua keperluan berfungsi dari FRD ditangani.

3. Dokumen ujian 0.7 / FIPD, yang mesti mengandungi, sekurang-kurangnya, maklumat mengenai perkara berikut:

Suatu Test Suite, yang terdiri daripada senarai Tujuan Ujian seperti yang dijelaskan dalam TSTO [5].

Pernyataan Kesesuaian Pelaksanaan (ICS), seperti yang dijelaskan dalam TSTO [5].

Untuk peningkatan spesifikasi, Test Suite dan ICS dapat disediakan sama ada sebagai dokumen berasingan atau sebagai bahagian tambahan dalam FIPD.

Penonton utama dokumen yang dihasilkan di s initage adalah ahli WG dan BARB yang kembaliview penerangan lengkap mengenai ciri atau peningkatan termasuk beberapa teks yang dirancang untuk dimasukkan dalam spesifikasi akhir. BTI adalah penonton untuk semulaview dokumen ujian.

BSTS akan kembaliview bahagian baru atau yang diubah dari spesifikasi dan dokumen ujian 0.7 / FIPD untuk kesesuaian dengan Garis Panduan Penggubalan Bluetooth, termasuk konvensyen bahasa yang dibentuk oleh Bluetooth SIG. BARB akan kembaliview spesifikasi 0.7 / FIPD.

BSTS akan membantu WG dalam menyediakan dokumen ujian 0.7 / FIPD sesuai dengan TSTO [5].

BTI mesti kembaliview dokumen ujian 0.7/FIPD. WG mesti memberikan spesifikasi 0.7 / FIPD kepada BTI sebagai rujukan ketika kembaliviewdalam dokumen ujian 0.7/FIPD, yang akan BTI semulaview sesuai dengan Spesifikasi BTI Review Senarai Semak Proses [6].

Setelah BARB selesai semulaview dari spesifikasi 0.7 / FIPD dan BTI telah menyelesaikannya semulaview dari dokumen ujian 0.7 / FIPD, BSTS akan membuat reviewed 0.7/FIPD spesifikasi tersedia untuk semua ahli Bersekutu dan Promoter.

The 0.7 / FIPD Stage tidak diperlukan untuk peningkatan spesifikasi CSS, GSS, atau MDP.

0.7 / FIPD Stagsyarat keluar

The 0.7 / FIPD Stage lengkap dan 0.9 / CR Stage bermula apabila syarat keluar berikut dipenuhi:

BSTS telah menyelesaikan semulaviewdengan spesifikasi dan dokumen ujian 0.7 / FIPD.
BARB telah menyelesaikan semulaviewdengan spesifikasi 0.7 / FIPD.
BTI telah menyelesaikan semulaviewdalam Suite Ujian 0.7/FIPD (Tujuan Ujian) dan 0.7/FIPD ICS.
BSTS telah membuat reviewed 0.7/FIPD spesifikasi tersedia untuk semua ahli Bersekutu dan Promoter.

4.3 0.9 / CR Stage

Terdapat dua jenis CR: CR Bersepadu, yang merupakan dokumen pelacakan perubahan dari seluruh spesifikasi yang diguna pakai yang menunjukkan semua perubahan sejak versi sebelumnya, dan CR Singkatan, yang merupakan dokumen yang memberikan arahan untuk mengubah hanya bahagian yang terkena versi spesifikasi yang berdasarkan CR.

Semasa 0.9 / CR Stage, WG akan mengembangkan yang berikut menggunakan templat rasmi yang disediakan di [8]:

Untuk spesifikasi baru, draf lengkap kandungan spesifikasi 0.9, yang mesti merangkumi, sekurang-kurangnya, maklumat mengenai perkara berikut:

Penerangan mengenai semua perubahan yang dilakukan sejak BARB-reviewedisi 0.7 spesifikasi (atau kerana spesifikasi 0.5 jika menghasilkan spesifikasi 0.7 telah diketepikan), termasuk baru atau
cadangan yang diubah suai, kriteria pemilihan, dan justifikasi pilihan. Perubahan mesti diterangkan pada tahap perincian yang sama seperti yang diperlukan dalam 0.5 Stage dan 0.7 Stage.

2. Untuk peningkatan spesifikasi:

Sama ada CR Bersepadu, yang mesti memasukkan, sekurang-kurangnya, maklumat mengenai perkara berikut:

Penerangan mengenai semua perubahan yang dilakukan sejak BARB-reviewed FIPD (atau sejak DIPD jika FIPD telah diketepikan) termasuk cadangan baru atau diubah suai, kriteria pemilihan, dan justifikasi pilihan. Perubahan mesti dijelaskan pada tahap perincian yang sama seperti yang diperlukan dalam DIPD Stage dan FIPD Stage.
Semua perubahan yang dicadangkan pada spesifikasi yang diadopsi sebelumnya menggunakan pelacakan perubahan.
Semua errata teknikal yang diluluskan (dengan setiap erratum dirujuk dengan nombor erratum), ditunjukkan menggunakan penjejakan perubahan, yang masih belum dimasukkan ke dalam versi spesifikasi yang diadopsi sebelumnya, dan teks impak yang dikaitkan dengan peningkatan spesifikasi; atau yang memberi kesan kepada ujian IOP.

3. Atau CR Singkatan, yang mesti memasukkan, sekurang-kurangnya, maklumat mengenai perkara berikut:

Penerangan mengenai semua perubahan yang dilakukan sejak BARB-reviewed FIPD (atau sejak DIPD jika FIPD telah diketepikan) termasuk cadangan baru atau diubah suai, kriteria pemilihan, dan justifikasi pilihan. Perubahan mesti dijelaskan pada tahap perincian yang sama seperti yang diperlukan dalam DIPD Stage dan FIPD Stage.
Semua perubahan dicadangkan ke setiap bagian dan perenggan spesifikasi yang dipengaruhi oleh CR untuk diubah.
Semua errata teknikal yang diluluskan (dengan setiap erratum dirujuk dengan nombor erratum), ditunjukkan menggunakan markup, yang masih belum dimasukkan ke dalam versi spesifikasi yang diadopsi sebelumnya, dan teks impak yang dikaitkan dengan peningkatan spesifikasi; atau yang memberi kesan kepada ujian IOP.

4. CSS CR (jika entri baru diperlukan oleh spesifikasi), yang mungkin disertakan dalam CR Singkatan dari spesifikasi.
5. CR GSS (jika entri baru diperlukan oleh spesifikasi), yang mungkin disertakan dalam CR Singkatan dari spesifikasi.
6. CR MDP (jika entri baru diperlukan oleh spesifikasi), yang mungkin disertakan dalam CR Singkatan dari spesifikasi.
7. Dokumen ujian 0.9 / CR, yang mesti merangkumi, sekurang-kurangnya, maklumat mengenai perkara berikut menggunakan templat rasmi yang disediakan dalam [8]:

The 0.9 / CR Test Suite, yang merangkumi kes ujian lengkap kandungan dan Jadual Pemetaan Kes Ujian (TCMT) yang berkaitan, seperti yang dijelaskan dalam TSTO [5].
ICS 0.9 / CR, seperti yang dijelaskan dalam TSTO [5].
Sekiranya mengkonfigurasi ujian memerlukan parameter khusus untuk Implementasi Under Test (IUT), 0.9 / CR Implementasi eXtra Information for Testing (IXIT).

Senarai Rujukan Kes Ujian 0.9 / CR (TCRL) (pilihan untuk kemas kini Spesifikasi Teras).

8. Analisis liputan ujian yang menunjukkan syarat spesifikasi mana yang diuji atau tidak diuji dalam 0.9 / CR Test Suite (untuk peningkatan spesifikasi, analisis liputan ujian hanya perlu memasukkan fungsi yang baru ditambahkan dan terpengaruh, dan bukan kawasan yang tidak terkena dampak spesifikasi asal).
9. Pelan ujian IOP.

Untuk peningkatan spesifikasi, Test Suite, ICS, dan IXIT dapat dibekalkan sama ada sebagai dokumen berasingan atau sebagai bahagian tambahan dalam Singkatan CR.

Dalam kebanyakan kes, CR Bersepadu atau Singkatan harus berdasarkan versi spesifikasi yang telah diadopsi sebelumnya, tetapi mungkin juga berdasarkan draf perantaraan terbaru. Nombor versi spesifikasi draf pertengahan terkini mestilah nombor versi yang dikaitkan dengan versi dokumen yang dibekukan dan yang tidak akan berubah dari masa ke masa. Jika tidak, maklumat pengenalan tambahan (seperti tarikh dokumen dan a URL ke lokasi tetap) mesti disediakan untuk mengenal pasti versi "garis dasar" tertentu. Sekiranya draf perantaraan digunakan, setiap perubahan yang tidak berkaitan langsung dengan CR dalam bagian tertentu yang diubahsuai oleh CR harus disertakan, tetapi tidak diperlukan untuk ditunjukkan menggunakan markup. Sekiranya bahagian draf perantaraan yang relevan kemudian dikemas kini, CR mesti dikemas kini untuk menggambarkan kemas kini pada draf perantaraan.

Sebaik-baiknya, bahan CR Singkatan disatukan ke dalam draf spesifikasi lengkap dan dokumen ujian lengkap masing-masing, sebelum Fasa Pengesahan, tetapi mungkin juga disatukan pada awal Fasa Pengesahan. Sekiranya banyak ciri sedang dikembangkan untuk spesifikasi (misalnya, Spesifikasi Inti), mungkin diinginkan untuk menyatukan ciri ke dalam satu draf setelah pengujian IOP selesai.

BSTS akan kembaliview dokumen spesifikasi dan ujian 0.9 / CR untuk kesesuaian dengan Garis Panduan Penggubalan Bluetooth. Kemudian BARB akan kembaliview spesifikasi 0.9 / CR diikuti kemudian oleh rancangan ujian IOP (seperti yang dijelaskan dalam Bahagian 4.3.1). Setelah spesifikasi 0.9 / CR diserahkan oleh WG ke BARB untuk review, BSTS akan menjadikannya mudah diakses oleh semua ahliview dan memberitahu semua anggota mengenai ketersediaannya. Mulai saat ini dalam proses pengembangan spesifikasi, BSTS akan membuat draf spesifikasi yang diserahkan kepada BARB tersedia untuk semua anggota dengan pemberitahuan berkala yang dikirimkan kepada semua anggota.

Untuk peningkatan spesifikasi, WG akan mengesyorkan kepada Direksi sama ada versi spesifikasi sebelumnya harus ditamatkan atau ditarik balik, termasuk alasan teknikal untuk cadangan tersebut.

BARB akan kembaliview analisis WG tentang pematuhan spesifikasi 0.9 / CR dengan syarat yang diberikan dalam FRD, masalah keselamatan yang berpotensi, masalah regulasi, kesesuaian dengan seni bina Bluetooth, dan, untuk peningkatan spesifikasi, pematuhan dengan keperluan keserasian mundur yang dijelaskan dalam Bahagian 3.3.2 .XNUMX. Sekiranya BARB mengenal pasti sebarang kemungkinan masalah keselamatan, BARB akan memberitahu BSTS untuk kembaliview dan koordinasi dengan Kumpulan Pakar Keselamatan; dan jika BARB mengenal pasti implikasi peraturan, BARB akan memberitahu BSTS untuk kembaliview dan berkoordinasi dengan Jawatankuasa Peraturan dan penasihat undang-undang Bluetooth SIG. BARB mesti menyetujui atau menolak spesifikasi 0.9 / CR berdasarkan penilaian kejuruteraannya dan pertimbangan faktor-faktor yang dijelaskan dalam perenggan ini.

BTI akan kembaliview dokumen ujian 0.9 / CR dengan mengambil kira analisis liputan ujian. BTI mesti meluluskan atau menolak dokumen ujian 0.9 / CR.

Setelah BARB menyetujui spesifikasi 0.9 / CR, WG menyerahkan rancangan ujian IOP kepada BARB untuk kembaliview.

Spesifikasi 0.9 / CR yang disetujui BARB disampaikan kepada Dewan untuk menyetujui permulaan pengujian IOP dan penerbitan spesifikasi 0.9 / CR kepada semua anggota.

Untuk menyoroti kemungkinan masalah hukum, WG dapat meminta spesifikasi kembaliview oleh penasihat undang-undang Bluetooth SIG (legal review) sebelum undang-undang wajib semulaview berlaku semasa Fasa Adopsi / Persetujuan. Namun, untuk peningkatan spesifikasi, hukumnya kembaliview harus dilakukan pada CR Terpadu (sebagai lawan dari CR Singkatan) dan ini harus diprogramkan sejauh mungkin sebelum sumber daya tersedia.

Pelan ujian IOP

WG akan mengembangkan rancangan ujian IOP bertulis yang mesti memenuhi semua syarat yang ditentukan di bawah untuk digunakan semasa Fasa Pengesahan pada acara ujian IOP. WG mesti menyerahkan rancangan ujian IOP kepada BARB untuk diulangview sebelum acara ujian IOP dimulakan. Untuk peningkatan spesifikasi sederhana (terutama yang tidak memerlukan pengubahsuaian atau penambahan kes ujian di Test Suite), pengujian IOP mungkin tidak diperlukan, dan WG dapat mengajukan permintaan kepada BARB untuk pengecualian dari pengujian IOP dengan menggunakan proses yang ditentukan dalam Bahagian 4.4.

Pelan ujian IOP mesti merangkumi:

Uji kes untuk mengesahkan semua ciri wajib, pilihan, dan bersyarat baru
Sekurang-kurangnya satu kes ujian untuk setiap kod op
Sekurang-kurangnya satu kes ujian untuk setiap parameter
Sekurang-kurangnya satu kes ujian untuk setiap jenis paket
Kes ujian keserasian ke belakang untuk peningkatan spesifikasi sehingga keperluan yang disenaraikan dalam Bahagian 3.3.2 dipenuhi untuk semua fungsi yang ditingkatkan (juga lihat Bahagian 4.3.1.1).

Kes ujian di mana IUT terdedah kepada nilai di luar julat yang ditentukan atau aspek tingkah laku yang dianggap tidak sah atau tidak dijangka (kes ujian Tingkah Laku Tidak Sah). Perhatikan bahawa diharapkan penguji seperti PTS atau alat ujian lain akan menjadi pemula bagi sebarang tingkah laku yang tidak sah.
Sebarang nombor sementara yang ditetapkan (dipilih bersama dengan BSTS untuk mengelakkan pertindihan pada acara ujian IOP akan datang) untuk digunakan pada acara ujian IOP, seperti yang dijelaskan dalam Bahagian 4.3.1.2.
Pengenalpastian jumlah pelaksanaan independen yang diperlukan yang harus lulus setiap kes ujian, dengan mengambil kira syarat liputan yang dijelaskan dalam Bahagian 4.3.1.3

Pengenalpastian kes ujian di Test Suite yang dipercayai oleh WG harus dikecualikan dan justifikasi pengecualiannya. Ini biasanya merangkumi: • Kes ujian Proofing Masa Depan (contohnya, ujian biasa sehingga kemungkinan penambahan masa depan dapat ditampung, seperti ciri tambahan, ciri pemanjangan, atau penggunaan bit atau bidang Reserved for Future Use (RFU))
• Kes ujian yang merupakan sebahagian daripada ujian lain yang disertakan
• Kes ujian generik yang hampir sama dengan ujian yang dijalankan untuk beberapa spesifikasi lain (contohnya, mencetuskan kod ralat biasa)
• Uji kes dengan tujuan ujian yang sama dengan kes ujian yang berjalan di atas pengangkutan lain (contohnya, kes ujian BR / EDR yang serupa dengan kes ujian LE)
• Kekukuhan atau ujian tekanan pelaksanaan

Rancangan ujian IOP juga boleh merangkumi ujian yang unik untuk ujian IOP seperti kes ujian ujung ke ujung yang merangkai urutan yang lebih kompleks yang mungkin menyerupai senario pengguna biasa.

Walaupun persetujuan BARB terhadap rancangan ujian IOP tidak diperlukan (berdasarkan pemahaman bahawa rancangan ujian IOP akan terus dimodifikasi dan diperbaiki dengan setiap peristiwa ujian IOP), persetujuan BARB untuk laporan ujian IOP diperlukan (lihat Bahagian 5.1.1) . Sekiranya rancangan ujian IOP tidak memenuhi semua syarat yang ditentukan dalam Bahagian 4.3.1, WG harus menunjukkan ringkasan dari setiap variasi yang diketahui dan alasan untuk setiap variasi ke BARB sebelum acara ujian IOP dimulakan.

Rancangan ujian IOP dan kes ujian harus berdasarkan pada kandungan dalam dokumen ujian spesifikasi yang berkaitan.

Untuk menjadikan acara ujian IOP cekap, WG harus mempunyai rancangan ujian IOP dan semua kes ujian yang berkaitan selesai dan tersedia untuk pelaksana dengan idealnya sekurang-kurangnya satu bulan sebelum acara ujian IOP pertama.

Merancang untuk ujian keserasian ke belakang
Untuk penambahbaikan spesifikasi, pengujian IOP keserasian ke belakang mesti mempertimbangkan pengesahan terhadap semua versi spesifikasi yang aktif dan tidak digunakan kerana spesifikasi dan fungsi yang biasanya terdapat dalam produk Bluetooth mungkin mempunyai jangka hayat yang sangat lama (misalnya, kenderaan). WG mesti menganalisis tahap pengujian keserasian ke belakang yang sesuai (jika ada) termasuk versi mana yang akan diuji dan ujian yang akan dilakukan, dan memberikan analisis ini kepada BARB. BARB mesti kembaliview analisis dan mengesyorkan perubahan (jika ada) agar WG dimasukkan ke dalam rancangan ujian IOP.

Anggota yang mengambil bahagian dalam ujian keserasian ke belakang digalakkan untuk membawa peranti lama yang telah memenuhi syarat daripada versi spesifikasi sebelumnya. WG mesti melaporkan sebarang kegagalan keserasian ke belakang dalam laporan ujian IOP. Syarikat anggota juga digalakkan untuk melakukan ujian keserasian ke belakang di makmal mereka sendiri di luar lokasi acara ujian IOP dan melaporkan sebarang masalah yang berkaitan dengan spesifikasi kepada WG.

Nombor Ditetapkan Sementara yang digunakan dalam ujian IOP
BSTS dan BARB mesti dimaklumkan untuk menyelaraskan penugasan sementara bagi nombor yang diberikan yang akan digunakan pada acara ujian IOP agar tidak ada pertindihan atau pertembungan dengan spesifikasi lain. Nilai sementara ini mesti dimasukkan dalam rancangan ujian IOP dan tidak akan digunakan untuk digunakan oleh spesifikasi yang diterima pakai.

Untuk ujian IOP di mana satu atau lebih nilai UUID 16-bit baru dicadangkan, nilai dalam julat 0x7F00 hingga 0x7FFF dikhaskan untuk ujian IOP.

Untuk pengujian IOP di mana satu atau lebih nilai Fixed Protocol Service Multiplexer (PSM) baru sedang diusulkan, nilai mulai dari akhir julat yang sah dari 0x0000 hingga 0x007F, seperti yang ditentukan dalam Spesifikasi Teras, akan digunakan.

Keperluan liputan
WG mesti memberikan bukti kepada BARB bahawa nombor yang diperlukan (seperti yang dijelaskan dalam bahagian yang berikut) pelaksanaan bebas telah lulus setiap kes ujian. Sebarang permintaan WG untuk pengecualian terhadap jumlah pelaksanaan bebas yang diperlukan mesti ditunjukkan dalam rancangan ujian IOP yang diserahkan kepada BARB.

Pelaksanaan dianggap bebas antara satu sama lain selagi semua bahagian yang berkaitan dengan pengesahan telah dikembangkan secara bebas, iaitu, oleh pasukan yang berbeza (yang tidak semestinya berasal dari syarikat yang berbeza). BSTS dapat membantu dalam menilai sama ada prototaip boleh dianggap bebas antara satu sama lain untuk menjaga kerahsiaan dan kerahsiaan perincian pelaksanaan.

Perhatikan bahawa alat ujian, termasuk PTS, tidak dianggap sebagai pelaksanaan bebas.

Keperluan liputan IOP Spesifikasi Teras
Ciri Spesifikasi Teras biasanya menentukan satu atau lebih peranan di mana setiap peranan dirancang untuk beroperasi dengan satu atau lebih peranan lain atau mungkin dengan dirinya sendiri.

Untuk setiap pasangan peranan yang dirancang untuk saling beroperasi antara satu sama lain, sekurang-kurangnya tiga pelaksanaan bebas dari setiap peranan mesti ditunjukkan untuk beroperasi dengan tiga pelaksanaan bebas dari peranan pelengkap.

Untuk setiap peranan yang boleh beroperasi dengan peranti lain dalam peranan yang sama, sekurang-kurangnya tiga pelaksanaan bebas dari peranan itu mesti menunjukkan bahawa mereka dapat berinteraksi satu sama lain dalam peranan tersebut.

Keperluan liputan IOP spesifikasi perkhidmatan
Sekurang-kurangnya tiga pelaksanaan perkhidmatan bebas mesti menunjukkan bahawa mereka beroperasi dengan sekurang-kurangnya satu pelaksanaan klien, yang mungkin PTS.

Profile dan spesifikasi protokol keperluan liputan IOP
Profile dan spesifikasi protokol biasanya menentukan satu atau lebih peranan di mana setiap peranan dirancang untuk beroperasi dengan satu atau lebih peranan lain, atau mungkin dengan dirinya sendiri.

Untuk setiap pasangan peranan yang dirancang untuk saling beroperasi antara satu sama lain, sekurang-kurangnya dua pelaksanaan bebas dari setiap peranan mesti menunjukkan bahawa mereka saling beroperasi dengan dua pelaksanaan bebas dari peranan pelengkap.

Spesifikasi model keperluan liputan IOP
Sekurang-kurangnya tiga model pelayan bebas atau implementasi model kawalan mesti menunjukkan bahawa mereka beroperasi dengan sekurang-kurangnya satu pelaksanaan klien (yang mungkin PTS), dan sekurang-kurangnya satu pelaksanaan model klien mesti menunjukkan bahawa ia beroperasi dengan sekurang-kurangnya satu pelaksanaan model pelayan dan PTS.

Penomboran versi spesifikasi

Semasa 0.9 / CR Stage, WG harus menyiapkan saranan untuk disampaikan kepada Direksi mengenai nomor versi yang akan diterapkan pada spesifikasi ketika diadopsi.

Versi spesifikasi termasuk dalam dua jenis: versi pelepasan penuh, yang merangkumi ciri baru atau kemas kini, dan versi pelepasan penyelenggaraan (juga dikenali sebagai "versi dot-Z"), yang mengintegrasikan errata teknikal dan editorial, tetapi tidak termasuk yang baru atau yang dikemas kini ciri-ciri. Versi pelepasan penuh mempunyai nombor dua bahagian dalam bentuk XY, seperti 2.1 atau 5.0, sementara versi pelepasan penyelenggaraan mempunyai nombor tiga bahagian dalam bentuk XYZ, seperti 2.1.2. Nilai Z tidak boleh 0.

Untuk dua versi, satu disebut sebagai "versi lebih tinggi" dan yang lain adalah "versi lebih rendah". Ini ditentukan mengikut peraturan berikut:

Sekiranya komponen X berbeza, yang mempunyai nilai X yang lebih tinggi adalah "versi yang lebih tinggi".
Sekiranya komponen X sama, tetapi komponen Y berbeza, yang mempunyai nilai Y yang lebih tinggi adalah "versi yang lebih tinggi".
Sekiranya komponen XY sama, tetapi komponen Z berbeza, yang mempunyai nilai Z yang lebih tinggi adalah "versi yang lebih tinggi". Nombor dua bahagian XY, untuk tujuan ini, dianggap sebagai nombor tiga bahagian XY0.

Untuk exampOleh itu, nombor versi berikut akan mengikut urutan dari versi terendah hingga versi tertinggi: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Untuk CSS, setiap kemas kini hanya menambah komponen X pada nombor versi.

Prasyarat kelulusan Lembaga Pengarah
Pada akhir fasa Pengembangan Spesifikasi, syarat-syarat berikut harus dipenuhi sebelum spesifikasi 0.9 / CR diserahkan kepada Dewan untuk persetujuan:

WG telah menyelesaikan analisis liputan ujian.
BSTS telah menyelesaikan semulaviewdengan spesifikasi dan dokumen ujian 0.9 / CR.
BARB telah meluluskan spesifikasi 0.9 / CR.
BARB telah menyetujui CSS CR (jika entri baru diperlukan oleh spesifikasi) yang mungkin disertakan dalam CR Singkatan dari spesifikasi.
BARB telah meluluskan CR GSS dan MDP CR (jika penyertaan baru diperlukan oleh spesifikasi).
BTI telah menyetujui 0.9 / CR Test Suite, ICS, dan TCRL, bersama dengan IXIT (dengan syarat bahawa IXIT diperlukan untuk melakukan ujian di Test Suite). TCRL adalah pilihan pada s initage untuk kemas kini kepada Spesifikasi Teras.
WG telah menyerahkan rancangan ujian IOP kepada BARB untuk diulangview (jika ujian tidak diketepikan oleh BARB).

Dokumen-dokumen yang diserahkan kepada Direksi harus menyertakan spesifikasi 0.9 / CR yang disetujui BARB, dan penyampaian kepada Direksi yang mesti meliputi:

Segala permintaan yang diketahui untuk mengetepikan ujian IOP atau mana-mana syarat yang ditentukan dalam Bahagian 4.3.1
Senarai pengangkutan yang disokong oleh spesifikasi (misalnya, BR / EDR, LE dll.)
Untuk peningkatan spesifikasi, setiap pengecualian dari syarat keserasian mundur (dijelaskan dalam Bahagian 3.3.2) yang diminta oleh WG
Untuk peningkatan spesifikasi, saran dari WG agar nombor versi berlaku untuk spesifikasi yang diterima pakai
Untuk peningkatan spesifikasi, cadangan akhir hayat WG untuk versi sebelumnya dari spesifikasi yang diadopsi, termasuk alasan teknikal mengapa penghentian atau penarikan versi spesifikasi sebelumnya atau tidak disarankan, dan justifikasi untuk cadangan
Segala kebimbangan serius yang tidak dapat diselesaikan dari anggota BARB atau BTI (misalnya, alasan untuk tidak ada suara semasa persetujuan, kebimbangan yang timbul daripadaview dokumen ujian, atau kebimbangan bahawa spesifikasi 0.9 / CR berada di luar ruang lingkup FRD atau piagam)
Status persiapan Profile Tuning Suite (PTS) atau alat lain yang diperlukan yang berkaitan dengan penggunaan yang disiapkan oleh BSTS

Lembaga Pengarah boleh memilih untuk menyetujui spesifikasi 0.9 / CR untuk pengujian IOP seperti yang dikehendaki oleh Peraturan [2], sebelum BTI menyetujui dokumen ujian 0.9 / CR dan sebelum WG mengesahkan bahawa rancangan ujian IOP memenuhi syarat yang ditentukan dalam Bahagian 4.3.1. 0.9. Lembaga Pengarah juga dapat menetapkan persetujuannya terhadap spesifikasi 0.9 / CR untuk pengujian IOP setelah persetujuan BTI terhadap dokumen ujian XNUMX / CR.

0.9 / CR Stagsyarat keluar
0.9 / CR Stage selesai dan Fasa Pengesahan bermula apabila BoD meluluskan permulaan ujian IOP.

4.4 Pengecualian Proses Pembangunan Spesifikasi

WG mungkin meminta untuk mengetepikan satu atau lebih langkah proses berikut:

The 0.5 / DIPD Stage
The 0.7 / FIPD Stage
Ujian IOP dalam Fasa Pengesahan

Untuk meminta pengabaian, WG mesti menggunakan templat pengabaian proses yang disediakan oleh Bluetooth SIG [8] dan menyerahkan permintaan pengabaian kepada setiap jawatankuasa (iaitu, BARB atau BTI) yang diperlukan untukview atau meluluskan draf spesifikasi atau dokumen ujian yang berkaitan di stage bahawa WG bercadang untuk mengetepikan, dan setiap jawatankuasa tersebut mesti meluluskan permintaan penepian.

Permintaan pengecualian mesti merangkumi perkara berikut:

Pengenalan stage bahawa WG mahu mengetepikan
Alasan mengapa stage harus diketepikan
Pengenalan setiap jawatankuasa (iaitu, BTI dan / atau BARB) yang diperlukan untuk kembaliview dan meluluskan permintaan pengabaian

Jawatankuasa yang mempertimbangkan pengecualian mungkin meminta wakil WG membuat pembentangan untuk membenarkan pengecualian proses SMPD sebelum memutuskan permintaan pengabaian.

Sekiranya pengabaian meminta untuk mengetepikan beberapa langkah dan sebahagian dari pengabaian ditolak dan sebahagiannya disetujui, tindak balas jawatankuasa mesti menunjukkan langkah-langkah dalam permintaan pengabaian yang disetujui dan yang ditolak. Sekiranya permintaan pengabaian ditolak, pemberitahuan penolakan mesti menyertakan alasan penolakan.

5. Fasa Pengesahan

Semasa Fasa Pengesahan, WG akan melakukan pengujian IOP pada spesifikasi 0.9 / CR dengan objektif untuk menyampaikan laporan ujian IOP untuk BARB review dan kelulusan. Sekiranya boleh, pengujian IOP peningkatan spesifikasi harus dilakukan terhadap spesifikasi draf bersepadu. Di samping itu, Anggota Review, seperti yang dikehendaki oleh Undang-Undang [2], bermula selama fasa ini.

Sekiranya spesifikasi (atau peningkatan) tidak memerlukan pengujian IOP, maka pengujian IOP dalam Fasa Pengesahan dapat diketepikan menggunakan proses yang dijelaskan dalam Bahagian 4.4.

Sepanjang pengujian IOP (yang mungkin satu atau lebih peristiwa), WG harus mengesan masalah menggunakan sistem pelacakan masalah Bluetooth SIG dan berulang-ulang untuk memasukkan kemas kini draf spesifikasi, dokumen ujian, dan rencana ujian IOP. Setelah ujian IOP berakhir, WG mesti melengkapkan kemas kini draf spesifikasi dan dokumen ujian untuk mengatasi semua masalah, dan menyediakan dan menyerahkan laporan ujian IOP kepada BARB untukview dan kelulusan. Ini digambarkan dalam Rajah 5.1.

Semasa Fasa Pengesahan terdapat beberapa aktiviti yang mungkin bermula. Kegiatan ini mungkin berlaku secara selari dan merangkumi perkara berikut:

Spesifikasi 0.9 / CR yang disetujui oleh Direksi disediakan untuk semua ahli oleh BSTS dengan pemberitahuan mengenai permulaan Anggota Review tempoh yang diperlukan oleh Undang-Undang.
Sebarang kemas kini yang diperlukan dimasukkan ke dalam CSS (yang mungkin disertakan dalam CR Singkatan dari spesifikasi).
Definisi ciri atau deskriptor dimasukkan ke dalam spesifikasi GSS dan juga PTS untuk ujian IOP.
Definisi harta Mesh dimasukkan ke dalam spesifikasi MDP dan juga PTS untuk ujian IOP.
BSTS membolehkan pendaftaran platform IOP dan alat kemasukan hasil sebagai persediaan untuk ujian IOP.
Pengujian IOP, jika diperlukan (lihat Bahagian 5.1).
Review komen dan masalah, termasuk yang dikemukakan sebagai hasil pengujian IOP, diproses dan perubahan dimasukkan ke dalam draf spesifikasi.

5.1 Ujian IOP

Objektif utama pengujian IOP adalah untuk mengesahkan spesifikasi oleh, untuk example, memeriksa ketepatan dan kekaburan dalam teks, semulaviewuntuk sebarang kesalahan dan kelalaian reka bentuk asas, dan memberikan pengesahan terhadap keperluan yang telah ditetapkan sebelumnya yang dikembangkan lebih awal dalam proses pengembangan spesifikasi. Pengujian IOP boleh mengakibatkan perubahan pada spesifikasi draf dan beberapa peristiwa ujian IOP mungkin diperlukan untuk menyelesaikan semua pengujian yang diperlukan.

Penting untuk memberi peluang kepada anggota di luar WG untuk mengambil bahagian dalam ujian IOP kerana mereka memberikan kebebasan view spesifikasi dan dapat mengungkap bidang kekaburan dalam spesifikasi yang mungkin tidak dapat dilihat oleh anggota WG yang menyusun draf tersebut. Sebelum setiap acara ujian IOP, BSTS akan menyediakan perincian acara, spesifikasi draf terbaru, Test Suite, dan rancangan ujian IOP tersedia dan akan memberitahu semua anggota dengan ideal satu bulan sebelum setiap acara. Spesifikasi draf yang diperbaharui, Test Suite, dan rancangan ujian IOP yang digunakan pada acara ujian IOP harus tersedia sekurang-kurangnya satu minggu sebelum setiap acara.

Semasa ujian IOP, gabungan platform berpasangan akan berusaha untuk melaksanakan ujian dan peserta ujian IOP akan mencatat keputusan lulus / gagal setiap ujian dan komen. Ringkasan hasil tanpa nama dari hasil ini (merujuk pada contoh, "Platform A", "Platform B", dan lain-lain) dan sebarang komen, akan dikumpulkan semasa acara ujian IOP dan disediakan untuk anggota WG semasa dan selepas IOP acara ujian. Sekiranya maklumat tambahan diperlukan untuk mendapatkan pemahaman yang lebih baik mengenai sebarang komen atau kegagalan yang berlaku semasa ujian IOP, BSTS dapat bertindak sebagai perantara untuk mengumpulkan maklumat lebih lanjut dari anggota pengirim.

Sekiranya mungkin, PTS harus dikemas kini untuk menyokong pengujian IOP dengan platform di semua lapisan di atas Host Controller Interface (HCI), dan hadir di acara ujian IOP untuk lapisan tersebut. Alat ujian lain juga mungkin ada di acara ujian IOP. Ringkasan hasil pengujian dengan PTS atau alat ujian lain (jika ada) harus disertakan dalam laporan ujian IOP.

Pengujian IOP akan terbuka untuk semua anggota yang ingin memberikan pelaksanaan prototaip, namun Bluetooth SIG boleh menetapkan penyertaan pada penerimaan perjanjian dengan Bluetooth SIG (termasuk perjanjian penyertaan dan kerahsiaan). WG bertanggungjawab untuk memproses dan menyelesaikan masalah yang ditemui semasa ujian IOP, dan mengemas kini dokumen yang terjejas; Perubahan yang disetujui WG mesti dimasukkan sebagai kemas kini draf spesifikasi dan dokumen ujian untuk digunakan pada setiap acara ujian IOP.

Sebelum Tahap Pengesahan, WG mungkin melakukan ujian IOP awal pada acara yang hanya terbuka untuk anggota WG, namun hasil ujian tidak formal mungkin tidak termasuk dalam hasil ujian IOP.

Mungkin berlaku bahawa semua langkah menjelang acara ujian IOP pertama diikuti, termasuk tanggal dan lokasi IOP yang diumumkan dengan niat untuk memulakan pengujian IOP, tetapi persetujuan Direksi belum dijamin sebelum dimulainya acara ujian. Dalam hal ini, Dewan Komisaris dapat mengizinkan penyertaan hasil ujian yang dikumpulkan sebelum persetujuan Direksi untuk memulai pengujian IOP, dengan syarat hasil yang dikumpulkan berdasarkan pada spesifikasi yang sama dan Test Suite yang disetujui oleh Direksi.

Ujian IOP tidak diperlukan untuk peningkatan pada spesifikasi CSS, GSS, atau MDP.

Laporan ujian IOP
Setelah ujian IOP selesai, WG mesti menyerahkan laporan ujian IOP kepada BARB dengan objektif untuk menunjukkan bahawa bilangan platform bebas yang diperlukan telah lulus ujian yang diperlukan. BARB mesti kembaliview dan meluluskan atau menolak laporan ujian IOP dan akan memberitahu WG jika ujian IOP tambahan diperlukan sebelum menyerahkan pakej spesifikasi Draf Pengundian ke Dewan Pengarah. BSTS dan WG mesti memastikan bahawa tidak ada maklumat pengenalan anggota yang muncul dalam laporan ujian IOP sebelum menyerahkan laporan tersebut ke BARB.

Laporan ujian IOP mesti merangkumi:

Senarai semua peristiwa ujian IOP yang berlaku semasa Fasa Pengesahan termasuk tarikh dan lokasinya.
Bilangan syarikat ahli dan platform bebas yang mengambil bahagian dalam setiap acara IOP termasuk sama ada PTS digunakan.
Senarai versi rancangan spesifikasi, Test Suite, dan IOP yang digunakan pada setiap acara.
Ringkasan eksekutif yang menyatakan sama ada semua kes ujian memenuhi kriteria lulus minimum atau tidak.
Ringkasan setiap variasi dari keperluan rancangan ujian IOP yang ditentukan dalam Bahagian 4.3.1 dan alasan untuk setiap varians.
Ringkasan liputan PTS untuk kes ujian di Test Suite.
Senarai semua kes ujian (termasuk ujian keserasian ke belakang) dari rancangan ujian IOP, jumlah lulus ujian, jumlah kegagalan ujian, dan sama ada kriteria minimum dipenuhi setiap kes ujian termasuk penjelasan mengapa sebarang syarat tidak bertemu.
Ringkasan isu, ulasan dan soalan pada setiap acara (termasuk yang filed terhadap spesifikasi semasa ujian IOP) dan kesan terhadap spesifikasi dan dokumen ujian.

5.2 Keperluan keluar Fasa Pengesahan

Fasa Pengesahan selesai dan Fasa Persetujuan / Adopsi bermula apabila BARB telah meluluskan laporan ujian IOP (kecuali pengujian dibebaskan oleh BARB) dan semua syarat berikut telah dipenuhi:

BSTS telah menyediakan spesifikasi 0.9/CR yang diluluskan kepada semua ahli untuk Ahli Review seperti yang dikehendaki oleh Peraturan dan memberitahu semua anggota mengenai ketersediaannya.
Semua masalah yang dikenal pasti semasa ujian IOP, dan yang mempunyai kesan ujian, telah disatukan dan diuji.
WG telah menyelesaikan ujian IOP (kecuali pengujian diketepikan oleh BARB).

6. Fasa Adopsi / Kelulusan

Semasa Tahap Adopsi / Persetujuan, spesifikasi dan dokumen ujian yang berkaitan diselesaikan, persetujuan BARB, BQRB, dan BTI diterima, pemberitahuan mengenai Tarikh Pengadopsian yang dicadangkan dikeluarkan bersama dengan versi akhir draf spesifikasi yang diserahkan kepada Dewan untuk diterima pakai ( Draf Pengundian), dan pakej spesifikasi akhir diserahkan kepada Dewan. Selepas tempoh minimum Anggota Review yang dikehendaki oleh Undang-Undang [2]) telah dipenuhi, Lembaga Pengarah akan mempertimbangkan spesifikasi untuk diadopsi pada Tarikh Adopsi. Setelah diterima pakai, spesifikasi diterbitkan dan sistem kelayakan diaktifkan. Fasa Adopsi / Persetujuan digambarkan dalam Rajah 6.1.

6.1 Draf Pengundian

Draf Pengundian dibuat dengan memasukkan kemas kini (disediakan dalam Fasa Pengesahan) ke dalam dokumen spesifikasi yang diperlukan, dan menyiapkan draf akhir spesifikasi baru. Untuk peningkatan spesifikasi, BSTS akan membuat spesifikasi terpadu dengan mengintegrasikan satu atau lebih CR ke dalam versi spesifikasi yang lebih tinggi yang telah diadopsi sebelumnya (lihat Bahagian 4.3.2) jika belum selesai sebelum Fasa Pengesahan.

Sekiranya perubahan dibuat pada spesifikasi selama fasa ini dan WG, BARB, atau BTI menentukan bahawa sebarang perubahan memerlukan pengujian IOP tambahan, spesifikasi akan kembali ke bahagian pengujian IOP Fasa Pengesahan agar WG melakukan ujian tambahan. Semasa Fasa Adopsi / Persetujuan, dokumen-dokumen berikut akan dilengkapkan dan disediakan kepada Lembaga Pengarah sebelum Tarikh Adopsi:

Draf Pengundian
Semua spesifikasi sokongan (iaitu, CSS, GSS, MDP) seperti yang diperlukan untuk jenis spesifikasi (atau peningkatan) yang relevan, jika tidak diadopsi sebelumnya
Untuk peningkatan spesifikasi, versi pelacakan perubahan dari versi spesifikasi yang diadopsi menunjukkan perubahan yang dicadangkan dalam Draf Pengundian
Penjelasan dari WG mengenai syarat-syarat keserasian kebelakang (seperti yang dijelaskan dalam Bahagian 3.3.2) yang belum dipenuhi dan justifikasi pengecualian apa pun
Penerangan dari WG mengenai sebarang keperluan rancangan ujian IOP (seperti yang dijelaskan dalam Bahagian 4.3.1) yang belum dipenuhi dan justifikasi untuk penyimpangan bersama dengan laporan ujian IOP (yang mungkin diberikan dengan memberikan pautan ke salinan di SIG Bluetooth webtapak)
Saranan dari WG untuk penghentian atau penarikan versi sebelumnya dari spesifikasi yang diadopsi bersama dengan pembenaran, yang menyoroti perubahan sejak 0.9 / CR Stage cadangan akhir hayat
Ringkasan, yang disiapkan oleh WG, mengenai perubahan ciri atau fungsi sejak spesifikasi 0.9 / CR (jika ada)
Ringkasan, yang disiapkan oleh BARB, mengenai keprihatinan yang ditimbulkan oleh anggota BARB bahawa spesifikasi yang dihasilkan oleh WG berada di luar skop piagam yang disetujui oleh Lembaga Pengarah (jika ada)
Senarai masalah undang-undang yang belum dapat diselesaikan dari undang-undang semulaview (jika ada)
The Test Suite yang diluluskan oleh BTI, bersama dengan ringkasan yang diluluskan oleh WG mengenai liputan ujian spesifikasi Draf Mengundi. Sekiranya fungsi yang baru ditambahkan atau diubah tanpa liputan ujian, diperlukan justifikasi bertulis untuk peninggalan tersebut
ICS dan IXIT yang diluluskan oleh BTI (jika diperlukan mengikut spesifikasi)
TCRL yang diluluskan oleh BTI dan BQRB
Laporan yang disiapkan oleh BSTS bersama dengan BTI mengenai status kesediaan alat (misalnya, PTS dan alat ujian lain, Bluetooth Launch Studio) termasuk jika ada kes ujian di TCRL tidak disokong oleh alat ujian
Ringkasan, yang disiapkan oleh WG, dari semua nombor yang diperlukan
Senarai semak penggunaan yang disiapkan oleh BSTS dan WG menunjukkan bahawa semua penyampaian di bahagian ini semuanya telah selesai
Semua maklumat lain yang diminta oleh Lembaga Pengarah

Selama Fasa Adopsi / Persetujuan, WG harus menggunakan sistem pelacakan masalah Bluetooth SIG untuk menangkap masalah dan komen terhadap draf spesifikasi dan dokumen uji sehingga mereka dipertanggungjawabkan dalam pemuktamadan spesifikasi Draf Pengundian. Untuk peningkatan spesifikasi, semua errata yang disetujui yang relevan (iaitu errata yang diluluskan yang belum disatukan) mesti disatukan, dan mesti dikenal pasti menggunakan perubahan yang dilacak.

WG mesti menyerahkan draf spesifikasi akhir kepada BSTS untuk mendapatkan perundanganview. Untuk spesifikasi baru, undang-undang semulaview akan merangkumi keseluruhan spesifikasi. Untuk peningkatan spesifikasi, review akan memberi tumpuan terutamanya pada bahagian spesifikasi yang diubah. Tujuan perundangan semulaview terutamanya untuk mengenal pasti risiko undang-undang yang harus dipertimbangkan dan berusaha diselesaikan oleh WG. Maklum balas undang-undang akan dikategorikan berdasarkan tahap keparahan. Sekiranya undang-undang pilihan semulaview dilakukan pada 0.9 / CR Stage, versi yang diserahkan untuk perundangan semulaview mesti menunjukkan, seperti perubahan yang dilacak, semua perubahan yang dibuat sejak versi tersebut (dihasilkan sama ada oleh WG atau BSTS). Setelah selesai re undang-undangview, WG dan BSTS akan bersetuju dengan maklum balas yang akan dimasukkan ke dalam draf spesifikasi. Sekiranya ada komen undang-undang yang tidak dapat diselesaikan dari undang-undang semulaview Pada draf spesifikasi, Ketua WG dapat meminta waktu dalam agenda Direksi untuk menyetujui penyelesaian.

Selari dengan re undang-undangview, WG harus menyerahkan draf spesifikasi kepada BARB untuk diulangview. Setelah pengiriman awal ke BARB, BSTS akan memberitahu semua anggota bahawa draf spesifikasi telah diserahkan kepada BARB untuk kembaliview dan bahawa ia juga tersedia untuk Anggota Review. Sekiranya WG mengemukakan kemas kini draf spesifikasi untuk BARB re-review, BSTS akan menghantar pemberitahuan tambahan kepada semua ahli secara berkala.

Setelah selesai BARB review, WG dan BARB akan menyetujui maklum balas yang akan dimasukkan ke dalam draf spesifikasi.

Sekiranya undang-undang semulaview menghasilkan perubahan substansial, tambahan lagiview oleh BARB mungkin diperlukan. Begitu juga jika BARB kembaliview mengakibatkan sebarang perubahan substantif, BSTS akan menentukan sama ada penambahan undang-undang semulaview perubahan tersebut diperlukan. Setelah selesai re undang-undangview dan BARB review, BARB mesti menyetujui atau menolak Draf Pengundian.

Sekiranya ada dokumen ujian yang memerlukan pengemaskinian, BSTS akan membantu WG dalam mengemas kini dokumen ujian. BTI mesti meluluskan atau menolak dokumen ujian. Sekiranya diluluskan oleh BTI, BTI akan membantu menyelesaikan TCRL dan menyampaikan dokumen ini ke BQRB bersama dengan ICS, IXIT, dan Test Suite yang berkaitan. BSTS akan menganggarkan tarikh mesyuarat Lembaga Pengarah apabila Lembaga Pengarah berhasrat untuk memilih mengenai Draf Pengundian (Tarikh Pengambilan) dan memberikannya BTI untuk digunakan dalam TCRL. BARB persetujuan spesifikasi, persetujuan BTI untuk semua dokumen ujian (termasuk Test Suite, TCRL, ICS, dan IXIT), dan persetujuan BQRB dari TCRL mesti berlaku pada atau sebelum Tarikh Adopsi.

BSTS akan memaklumkan kepada semua ahli mengenai pemuktamadan dan ketersediaan Draf Pengundian dan Tarikh Pengambilan. Tarikh Adopsi akan ditetapkan tidak lebih awal dari 60 hari setelah anggota diberitahu tentang spesifikasi 0.9 / CR yang disetujui oleh Dewan, kecuali Anggotaview tempoh dipendekkan oleh Direksi sesuai dengan Peraturan, dan sekurang-kurangnya 14 hari setelah pemberitahuan Tarikh Penerimaan diberikan kepada anggota sesuai dengan Peraturan tersebut. Untuk kes di mana beberapa CR telah disatukan ke dalam Draf Pengundian, permulaan Anggota Review adalah tarikh di mana anggota diberitahu mengenai CR yang diluluskan oleh Lembaga Pengarah paling baru.

Setelah pemberitahuan Tarikh Adopsi diberikan kepada anggota, pembetulan yang disetujui oleh Lembaga Pengarah terhadap kesalahan tipografi dalam Draf Pengundian dibenarkan. Garis masa Penerapan Spesifikasi digambarkan dalam Rajah 6.2.

6.2 Nombor yang diberi

Bluetooth SIG menyimpan sekumpulan nombor yang ditetapkan untuk umum pada Bluetooth SIG Assigned Numbers weblaman web [7]. Nombor yang diberikan ini dikumpulkan dalam pelbagai ruang nombor (sekumpulan nombor yang berkaitan tanpa pendua). Nombor yang ditugaskan mungkin bertindih dengan nombor lain yang diberikan dalam ruang nombor yang berbeza, tetapi tidak ada nombor dalam ruang nombor yang dibenarkan untuk digunakan kembali. Berbagai ruang nombor ditentukan dalam spesifikasi yang menentukan penggunaan nombor yang diberikan.

Setelah BARB menyetujui laporan ujian IOP, WG akan mengemukakan permintaan kepada BARB untuk penugasan nombor baru dalam ruang nombor yang diperlukan oleh spesifikasi akhir. BARB akan kembaliview permintaan dan bekerjasama dengan BSTS untuk menentukan nombor yang diberikan. Setelah mendapat persetujuan BARB, BSTS akan menjadualkan penerbitan nombor yang diberikan untuk dibuat secara terbuka di Bluetooth SIG Assigned Numbers webtapak [7] dalam masa satu minggu dari penggunaan spesifikasi.

Sebaik sahaja penerbitan nombor yang diberikan pada Bluetooth SIG Assigned Numbers weblaman web atau dalam spesifikasi yang diadopsi berlaku, nombor yang ditentukan dimaksudkan untuk tidak berubah (tidak berubah sama ada dalam nilai atau makna). Sekiranya ia tidak dapat digunakan untuk beberapa sebab, mereka menjadi nilai terpelihara dan tidak dibenarkan untuk digunakan kembali.

6.3 Keperluan keluar Fasa Adopsi / Kelulusan

Fasa Persetujuan / Adopsi selesai ketika Dewan Direksi telah mengadopsi spesifikasi dan kegiatan pasca adopsi berikut telah selesai:

BSTS telah membuat nombor akhir yang diberikan secara terbuka di Bluetooth SIG webtapak.
BSTS telah membuat spesifikasi yang diterima tersedia untuk umum di Bluetooth SIG webtapak
BSTS telah membuat semua dokumen sokongan (misalnya, CSS, GSS, MDP) yang diperlukan untuk spesifikasi yang relevan tersedia untuk umum di Bluetooth SIG webtapak.
BSTS telah menyediakan dokumen ujian yang berkaitan kepada semua ahli pada Bluetooth SIG webtapak.
Untuk penambahbaikan spesifikasi, BSTS telah membuat versi pelacakan perubahan yang informatif dari versi spesifikasi yang diadopsi sebelumnya dengan semua perubahan yang dibuat oleh versi yang baru diterima dan membuatnya tersedia untuk semua anggota di Bluetooth SIG webtapak.
BSTS telah mengaktifkan sistem kelayakan.
BSTS telah memberitahu semua anggota mengenai ketersediaan spesifikasi dan semua dokumen sokongan.

Bluetooth SIG merancang untuk menyelesaikan aktiviti pasca adopsi ini dalam satu minggu setelah penerapan spesifikasi.

7. Fasa Penyelenggaraan Spesifikasi

Fasa Penyelenggaraan Spesifikasi bermula setelah Fasa Adopsi / Persetujuan selesai. Sekiranya masalah dijumpai (misalnya, kesamaran kata atau kesilapan teknikal) dengan spesifikasi atau dokumen ujian yang berkaitan, mereka mesti didokumentasikan dengan membuat cadangan errata menggunakan alat Bluetooth SIG Errata. Cadangan erratum spesifikasi akan diproses, dikategorikan, dan diluluskan menurut EPD [3]. Erratum Test Suite diproses dan dikategorikan mengikut TSTO [5]. Sekiranya terdapat konflik antara SMPD dan EPD atau TSTO, SMPD diutamakan.

Erratum spesifikasi hanya boleh digunakan untuk membetulkan kesilapan teknikal atau editorial dalam spesifikasi Bluetooth yang diterima pakai akhir. Penambahan, perubahan, dan penghapusan fungsi hanya dapat dilakukan melalui proses peningkatan spesifikasi yang ditentukan sebelumnya dalam dokumen ini.

7.1 Proses erratum yang dipercepat

Apabila erratum disetujui mengikuti proses yang ditentukan dalam EPD [3], WG, BARB, atau BSTS mungkin mengesyorkan agar dianggap sebagai mendesak dan harus dipercepat. Apabila ini berlaku, BSTS bersama dengan WG atau BARB akan mengemukakan cadangan kepada Lembaga Pengarah. Lembaga Pengarah akan memutuskan sama ada untuk menerima atau menolak cadangan tersebut. Sekiranya cadangan itu diterima, BSTS akan segera memasukkan erratum yang diluluskan ke dalam templat erratum [8] dan bekerjasama dengan WG yang bertanggungjawab untuk menyelesaikan Pembetulan Errata yang Dipercepat untuk diserahkan kepada WG untuk kembaliview dan kelulusan.

Berakhirview proses erratum yang dipercepat digambarkan dalam Rajah 7.1.

Dokumen-dokumen berikut mesti dilengkapkan dan disediakan kepada Lembaga Pengarah sebelum Tarikh Adopsi:

Draf yang diluluskan oleh BARB Mempercepat Pembetulan Errata.
Penjelasan dari WG mengenai syarat-syarat keserasian ke belakang (seperti yang dijelaskan dalam Bahagian 3.3.2) yang belum dipenuhi dan justifikasi pengecualian apa pun.
Senarai masalah undang-undang yang belum dapat diselesaikan dari undang-undang semulaview (jika ada).
Test Suite, ICS, dan IXIT yang diluluskan oleh BTI (jika diperlukan oleh erratum).
TCRL yang diluluskan oleh BTI- dan BQRB (jika diperlukan oleh erratum).
Laporan yang disiapkan oleh BSTS bersama-sama dengan BTI mengenai status kesediaan alat (contohnya, PTS dan alat ujian lain, Bluetooth Launch Studio) termasuk jika ada kes ujian di TCRL tidak disokong oleh alat ujian dan penjelasan (jika diperlukan oleh erratum ).
Senarai semak penerimaan yang dilengkapkan oleh BSTS dan WG yang menunjukkan bahawa penyampaian di bahagian ini semuanya telah selesai.
Semua maklumat lain yang diminta oleh Lembaga Pengarah.

BSTS akan bekerjasama dengan WG yang bertanggungjawab untuk menyelesaikan draf Pembetulan Errata yang dipercepat dan membuat versi untuk diserahkan kepada WG yang bertanggungjawab untukview dan kelulusan.

WG mesti menyerahkan Pembetulan Ralat Terpantas kepada BSTS untuk mendapatkan semula undang-undangview. Setelah selesai re undang-undangview, WG dan BSTS akan bersetuju dengan maklum balas yang akan dimasukkan ke dalam Pembetulan Errata yang Dipercepat. Sekiranya ada komen undang-undang yang tidak dapat diselesaikan dari undang-undang semulaview pada Pembetulan Errata yang Dipercepat, Ketua WG dapat meminta waktu dalam agenda Dewan Direksi untuk mendapatkan masukan dari Dewan Pengarah mengenai penyelesaian.

Selari dengan re undang-undangview, WG mesti menyerahkan Pembetulan Errata yang Dipercepat ke BARB untuk kembaliview. Setelah Pembetulan Errata yang Dipercepat diserahkan ke BARB, BSTS akan membuatnya dapat diakses oleh semua anggotaview dan memberitahu semua anggota mengenai ketersediaannya. Setelah selesai BARB review, WG dan BARB akan bersetuju dengan maklum balas yang akan dimasukkan ke dalam Pembetulan Errata yang dipercepat.

Sekiranya ada dokumen ujian yang memerlukan pengemaskinian, BSTS akan membantu WG dalam mengemas kini dokumen ujian. Setelah BTI menyetujui dokumen ujian, BTI akan membantu menyelesaikan TCRL dan mengirimkan dokumen tersebut ke BQRB bersama dengan ICS, IXIT, dan Test Suite yang berkaitan sebagaimana yang berlaku. BSTS akan menganggarkan Tarikh Adopsi dan memberikannya kepada BTI untuk digunakan dalam TCRL. Kelulusan BARB untuk Pembetulan Errata yang Dipercepat, persetujuan BTI untuk semua dokumen ujian (termasuk Test Suite, TCRL, ICS, dan IXIT sebagaimana yang berlaku), dan persetujuan BQRB terhadap TCRL mesti berlaku pada atau sebelum Tarikh Penerimaan.

BSTS akan memaklumkan kepada semua anggota mengenai penyelesaian dan ketersediaan Pembetulan Errata yang Dipercepat dan Tarikh Penggunaan yang dicadangkan. Tarikh Adopsi akan ditetapkan dan diberitahu kepada semua anggota sesuai dengan Peraturan [2] dan Tarikh Pengangkatan hendaklah sekurang-kurangnya 14 hari setelah notis diberikan kepada anggota. Setelah pemberitahuan mengenai Tarikh Adopsi yang dicadangkan diberikan kepada anggota, Dewan Pengarah dapat menyetujui pembetulan kesalahan tipografi dalam Pembetulan Kesalahan yang Dipercepat tanpa memberikan pemberitahuan tambahan mengenai Tarikh Penggunaan yang dicadangkan dan menunggu 14 hari yang diperlukan.

Bluetooth SIG akan membuat Pembetulan Errata yang Dipercepat yang diterima pakai untuk umum dan merancang untuk melakukannya dalam masa satu minggu setelah penggunaan. Pemberitahuan mengenai ketersediaannya akan dikeluarkan oleh BSTS kepada semua ahli.

Proses erratum yang dipercepat akan selesai apabila Lembaga Pengarah telah mengadaptasi Pembetulan Errata yang dipercepat dan aktiviti pasca-adopsi berikut telah selesai:

BSTS telah menjadikan Pembetulan Errata Terpantas yang diterima pakai dan dokumen ujian yang berkaitan (jika diperlukan oleh erratum) tersedia secara terbuka pada Bluetooth SIG webtapak.
BSTS telah mengaktifkan sistem kelayakan (jika diperlukan oleh erratum).
BSTS telah memberitahu semua anggota mengenai ketersediaan Pembetulan Errata yang Dipercepat.

Setelah menyelesaikan kegiatan-kegiatan ini, Pembetulan Errata akan dijadwalkan untuk disatukan ke spesifikasi yang terjejas baik sebagai bagian dari peningkatan spesifikasi yang dirancang atau dalam pelepasan penyelenggaraan yang akan datang seperti yang dijelaskan dalam Bahagian 7.2.

7.2 Proses pelepasan penyelenggaraan (spesifikasi .Z)

Pada kira-kira tahunan, BSTS akan menentukan apakah ada errata yang disetujui (disebut sebagai Pembetulan Errata) yang diklasifikasikan sebagai Teknikal / Tinggi atau Teknikal / Kritikal dan yang masih belum dimasukkan ke dalam teks spesifikasi aktif (iaitu, spesifikasi yang diguna pakai yang belum digunakan atau ditarik balik). Lihat Lampiran A untuk definisi pengelasan errata. Pemilik Spesifikasi (baik WG disewa untuk mempertahankan spesifikasi, atau BARB jika tidak ada WG yang disewa untuk mempertahankan spesifikasi) juga dapat meminta pelepasan penyelenggaraan spesifikasi aktif yang lebih awal untuk memasukkan kesalahan yang disetujui. Atas penentuan BSTS, atau permintaan Pemilik Spesifikasi, proses pelepasan penyelenggaraan akan dimulakan.

Berakhirview proses pembebasan penyelenggaraan digambarkan dalam Ralat! Sumber rujukan tidak dijumpai.

Pada awal proses pelepasan pemeliharaan, BSTS bersama dengan Pemilik Spesifikasi, BARB, dan BTI akan mengembangkan dan menyampaikan rencana kepada Dewan Direksi untuk memasukkan Pembetulan Errata ke dalam versi spesifikasi yang diterbitkan. Rancangan yang dicadangkan mesti menunjukkan sama ada Errata Corrections akan dimasukkan ke dalam pemeliharaan pelepasan spesifikasi (iaitu, versi .Z) atau peningkatan spesifikasi yang sudah berjalan (iaitu, versi XY). Rencana yang dicadangkan harus mempertimbangkan apakah ada fitur wajib baru yang telah ditambahkan antara versi spesifikasi yang diadopsi, perkiraan waktu ketika peningkatan spesifikasi berikutnya direncanakan untuk diadopsi, dan faktor-faktor lain.

Setelah mendapat persetujuan rencana oleh Direksi, BSTS bersama dengan Pemilik Spesifikasi akan terus memasukkan semua Pembetulan Kesalahan Teknikal / Menengah, Teknikal / Tinggi, dan Teknis / Kritikal ke dalam draf spesifikasi yang disebut sebagai "Draf Pelepasan Penyelenggaraan". Untuk Pembetulan Errata Editorial atau Teknikal / Rendah, jika Pembetulan Errata berlaku untuk lebih dari satu versi spesifikasi, BSTS akan, kecuali jika BoD menunjukkan sebaliknya, mengintegrasikan kesalahan tersebut ke dalam versi spesifikasi yang paling tinggi hanya pada kemas kini seterusnya versi tersebut . Tidak ada perubahan yang dapat disertakan dalam Draf Pelepasan Penyelenggaraan selain daripada memasukkan Errata Corrections. Setiap Draf Pelepasan Penyelenggaraan mesti mengenal pasti semua Pembetulan Errata yang digabungkan menggunakan pelacakan perubahan untuk menunjukkan perubahan yang dicadangkan pada versi spesifikasi yang diterbitkan sebelumnya.

Masa penggabungan yang dicadangkan untuk setiap Pembetulan Errata dalam Draf Pelepasan Penyelenggaraan akan bergantung pada impak Test Suite: semua Pembetulan Errata yang tidak mempunyai impak Test Suite dapat digabungkan dengan segera, tetapi Pembetulan Errata yang memberi kesan pada Suite Uji akan diproses sehingga masanya bertepatan dengan kemas kini ke TCRL.

BTI dan BSTS akan menetapkan tarikh akhir untuk memasukkan Errata Corrections dengan kesan Test Suite dalam Draf Pelepasan Penyelenggaraan. Tarikh akhir ini biasanya 3 hingga 6 bulan sebelum tarikh kelulusan yang dirancang untuk pelepasan TCRL utama seterusnya. Pembetulan Errata dengan kesan Test Suite yang melepasi tarikh akhir penyertaan akan diproses sebagai sebahagian daripada pengeluaran TCRL tahunan seterusnya. Oleh itu, melainkan jika pelepasan lebih awal diminta, waktu maksimum untuk Pembetulan Kesalahan Teknikal / Tinggi atau Teknikal / Kritikal untuk disertakan dalam kemas kini spesifikasi adalah sekitar 15 hingga 18 bulan.

Pemilik Spesifikasi mesti menyerahkan Draf Pelepasan Penyelenggaraan yang telah disetujui sebagai final untuk perundangan semulaview. Undang-undang semulaview akan memberi tumpuan terutamanya pada bahagian spesifikasi yang berubah. Setelah selesai re undang-undangview, Pemilik Spesifikasi dan BSTS akan bersetuju dengan maklum balas yang akan dimasukkan ke dalam Draf Pelepasan Penyelenggaraan. Sekiranya ada komen undang-undang yang tidak dapat diselesaikan dari undang-undang semulaview pada Draf Pelepasan Penyelenggaraan, Pemilik Spesifikasi dapat meminta waktu dalam agenda Dewan Direksi untuk meminta masukan Direksi mengenai penyelesaian.

Selari dengan re undang-undangview, pemilik Spesifikasi mesti menyerahkan Draf Pelepasan Penyelenggaraan ke BARB untuk diulangview. Setelah Draf Pelepasan Penyelenggaraan diserahkan ke BARB, BSTS akan membuatnya dapat diakses oleh semua ahliview dan memberitahu semua anggota mengenai ketersediaannya. Setelah selesai BARB review, Pemilik Spesifikasi dan BARB akan bersetuju dengan maklum balas yang akan dimasukkan ke dalam spesifikasi draf.

Untuk Pembetulan Errata yang mempengaruhi dokumen ujian, dan di mana errata ujian yang sesuai akan diproses tepat pada masanya untuk pelepasan TCRL yang akan datang, BSTS akan bekerjasama dengan Pemilik Spesifikasi dan BTI untuk mengemas kini dokumen ujian. Setelah BTI meluluskan dokumen ujian, BSTS akan menganggarkan Tarikh Adopsi dan memberikan Tarikh Penggunaan yang dicadangkan kepada BTI untuk digunakan dalam TCRL. BTI akan mengirimkan TCRL ke BQRB bersama dengan ICS, IXIT, dan Test Suite yang berkaitan sebagaimana yang berlaku. BARB persetujuan spesifikasi, persetujuan BTI untuk semua dokumen ujian (termasuk Test Suite, TCRL, ICS, dan IXIT sebagaimana yang berlaku), dan persetujuan BQRB dari TCRL mesti berlaku pada atau sebelum Tarikh Adopsi.

BSTS akan memaklumkan kepada semua anggota mengenai pemuktamadan dan ketersediaan Draf Pengundian dan Tarikh Pengambilan yang dicadangkan. Tarikh Pengangkatan akan ditetapkan dan diberitahu kepada semua anggota mengikut Peraturan dan Tarikh Pengangkatan hendaklah sekurang-kurangnya 14 hari selepas pemberitahuan pemberitahuan diberikan kepada anggota. Setelah pemberitahuan mengenai Tarikh Adopsi yang dicadangkan diberikan kepada anggota, Dewan Pengarah dapat menyetujui pembetulan kesalahan tipografi dalam Draf Pengundian tanpa memberikan pemberitahuan tambahan mengenai Tarikh Pengadopsian yang dicadangkan dan menunggu 14 hari yang diperlukan.

Dokumen-dokumen berikut mesti dilengkapkan dan disediakan kepada Lembaga Pengarah sebelum Tarikh Adopsi:

Draf Pengundian
Versi Draf Pengundian yang dilacak perubahan yang menunjukkan semua perubahan pada versi spesifikasi yang diadopsi yang memiliki nilai XY yang sama (misalnya, jika Draf Pengundian diusulkan sebagai versi 1.4.2, perubahan akan dilacak terhadap 1.4.1 versi spesifikasi)
Saranan dari Pemilik Spesifikasi untuk penghentian atau penarikan versi sebelumnya dari spesifikasi yang diadopsi bersama dengan pembenaran
Senarai masalah undang-undang yang belum dapat diselesaikan dari undang-undang semulaview (jika ada)
Test Suite, ICS, dan IXIT yang diluluskan oleh BTI (jika diperlukan oleh siaran penyelenggaraan)
TCRL yang diluluskan oleh BTI- dan BQRB (jika diperlukan oleh pelepasan penyelenggaraan)
Laporan yang disiapkan oleh BSTS bersama-sama dengan BTI mengenai status kesediaan alat (misalnya, PTS dan alat ujian lain, Bluetooth Launch Studio) termasuk kes ujian dalam TCRL yang tidak disokong oleh alat ujian, dan penjelasan (jika diperlukan oleh penyelenggaraan pelepasan)
Senarai semak penerimaan yang dilengkapkan oleh BSTS dan Pemilik Spesifikasi yang menunjukkan bahawa penyampaian di bahagian ini semuanya telah selesai
Semua maklumat lain yang diminta oleh Lembaga Pengarah

Proses pelepasan penyelenggaraan selesai apabila Direksi telah mengadopsi Draf Pengundian dan kegiatan pasca-adopsi berikut telah selesai:

BSTS telah membuat spesifikasi yang diadopsi dan dokumen ujian yang berkaitan (jika diperlukan oleh siaran penyelenggaraan) tersedia untuk umum di Bluetooth SIG webtapak.
BSTS telah membuat versi pelacakan yang informatif dari versi spesifikasi yang diadopsi sebelumnya dengan semua perubahan yang disertakan dalam versi yang baru diterima tersedia untuk semua anggota di Bluetooth SIG webtapak.
BSTS telah mengaktifkan sistem kelayakan.
BSTS telah memberitahu semua anggota mengenai ketersediaan spesifikasi dan dokumen sokongan yang diterima pakai.

Bluetooth SIG merancang untuk menyelesaikan aktiviti pasca adopsi ini dalam satu minggu setelah penerapan spesifikasi.

Setelah menyelesaikan kegiatan ini, spesifikasi tetap dalam fasa Pemeliharaan Spesifikasi sampai spesifikasi tersebut tidak digunakan lagi atau ditarik, seperti yang ditentukan dalam Bagian 8.

8. Spesifikasi Fasa Akhir Hayat

Spesifikasi mungkin tidak digunakan lagi atau ditarik ketika digantikan oleh versi yang lebih baru, ditentukan secara teknis tidak mencukupi, atau untuk alasan lain. Spesifikasi yang tidak digunakan lagi dan ditarik balik diarkibkan dan tidak lagi dikemas kini. Spesifikasi yang tidak digunakan lagi dan ditarik diperlakukan secara berbeza dalam Program Kelayakan Bluetooth.

Mana-mana ahli, kumpulan, atau jawatankuasa boleh mengemukakan cadangan untuk menghentikan atau menarik balik spesifikasi bersama dengan garis masa yang berkaitan ke BSTS (melalui e-mel ke

specification.manager@bluetooth.com) pada bila-bila masa. BSTS juga boleh mengesyorkan penamatan atau penarikan balik spesifikasi dan garis masa yang berkaitan. BSTS akan merujuk cadangan kepada BARB dan kumpulan atau jawatankuasa yang bertanggungjawab untuk mengekalkan spesifikasi untuk semulaview dan maklum balas.

BARB dan kumpulan atau jawatankuasa yang bertanggungjawab akan menilai cadangan untuk menghentikan atau menarik balik spesifikasi dan mempertimbangkan kriteria berikut (tidak lengkap):

Adakah terdapat fungsi dalam spesifikasi versi sebelumnya yang sudah usang atau tidak boleh digunakan?
Adakah fungsi wajib baru telah ditambahkan ke versi yang lebih baru?
Adakah terdapat kekurangan pada versi sebelumnya yang mengganggu operasi atau interoperabilitas yang telah diperbaiki pada versi yang lebih baru dan diperlukan untuk memajukan senario pengguna yang ada?
Adakah fungsi tambahan dalam versi yang lebih baru diperlukan untuk memajukan senario pengguna baru?
Adakah peningkatan kebolehgunaan dan interoperabiliti dalam versi yang lebih baru?
Adakah terdapat peningkatan keselamatan pada versi yang lebih baru?

BARB dan kumpulan atau jawatankuasa yang bertanggungjawab boleh mengemukakan cadangan alternatif.

Setelah mendapat maklum balas dari BARB atau kumpulan atau jawatankuasa yang bertanggungjawab untuk menjaga spesifikasi, BSTS akan menyerahkan cadangan dan maklum balas kepada Dewan untuk pertimbangan. Lembaga Pengarah boleh mengundang kumpulan atau jawatankuasa yang bertanggungjawab untuk menjaga spesifikasi yang terlibat untuk bertemu dan membincangkan cadangan. Lembaga Pengarah akan mempertimbangkan cadangan dan maklum balas dan mungkin menyetujui atau mengubah cadangan tersebut. Lembaga Pengarah akan meminta agar BSTS memberitahu semua anggota cadangan untuk menghentikan atau menarik kembali spesifikasi dan garis masa yang berkaitan selama 30 hariview tempoh untuk membolehkan semua ahli memberikan maklum balas tambahan sebelum membuat keputusan akhir.

Lembaga Pengarah akan mempertimbangkan maklum balas yang diterima daripada ahli. Setelah Lembaga Pengarah menyetujui penghentian atau penarikan spesifikasi, BSTS akan memberitahu semua anggota keputusan dan garis masa yang berkaitan.

8.1 Penurunan

Setelah spesifikasi tidak digunakan lagi, berikut akan berlaku:

Spesifikasi tidak akan dikemas kini lagi.
WG yang bertanggungjawab akan kembaliview semua kesalahan tertulis yang ditulis berdasarkan spesifikasi yang tidak digunakan untuk menentukan sama ada ia berlaku untuk spesifikasi lain. Errata boleh ditolak dalam sistem errata dan ditulis semula terhadap spesifikasi yang berkenaan.
WG atau BSTS akan membuat errata untuk mengemas kini sebarang rujukan yang diperlukan untuk spesifikasi yang tidak digunakan dalam spesifikasi lain.
BTI akan mengemas kini dokumen ujian yang berlaku untuk menunjukkan penghentian spesifikasi.
BSTS akan mengemas kini Bluetooth SIG weblaman web dengan panduan mengenai spesifikasi alternatif untuk digunakan.
Errata baru tidak lagi dapat dikirimkan berdasarkan spesifikasi yang tidak digunakan lagi.
Spesifikasi tidak akan dirujuk dalam spesifikasi masa depan.
BSTS akan mengarkibkan versi spesifikasi yang ditandai sebagai tidak digunakan untuk diakses oleh ahli untuk tujuan sejarah.

8.2 Pengeluaran

Setelah spesifikasi ditarik, selain langkah-langkah yang berlaku untuk penghentian penggunaan, hal berikut akan terjadi:

BTI akan mengemas kini dokumen ujian yang berlaku untuk menunjukkan penarikan spesifikasi.
BSTS akan mengemas kini Bluetooth SIG weblaman web dengan panduan mengenai spesifikasi alternatif untuk digunakan.
BSTS akan mengarkibkan versi spesifikasi yang ditandai sebagai ditarik untuk diakses oleh ahli untuk tujuan sejarah.

Lembaga Pengarah dapat memilih untuk menarik spesifikasi dengan segera tanpa terlebih dahulu menghentikan spesifikasi tersebut.

9. Proses kertas putih

Kertas putih dibuat untuk tujuan maklumat sahaja. Proses kertas putih berikut berlaku untuk semua Bluetooth WG, EG, SG, dan jawatankuasa. Bahagian ini tidak berlaku untuk dokumen maklumat untuk digunakan hanya dalam Bluetooth SIG.

Proses ini digambarkan dalam Rajah 9.1 di bawah.

Sebelum mana-mana kumpulan atau jawatankuasa memulakan kerja pada kertas putih yang mereka ingin diterbitkan oleh Bluetooth SIG, kumpulan atau jawatankuasa akan menyiapkan cadangan kemas kini piagam yang secara jelas menentukan kandungan cadangan kertas putih dan pembentangan cadangan kertas putih.

Pembentangan cadangan kertas putih mesti merangkumi minimum:

Keperluan untuk kertas putih
Ringkasan kandungan cadangan kertas putih
Penjelasan mengapa kandungan tidak digalakkan dimasukkan sebagai sebahagian daripada spesifikasi
Penonton yang dimaksudkan
Sebarang rancangan penyelenggaraan (iaitu, anggaran masa sebelum pengeluaran kertas putih ini mungkin diperlukan)
Cadangan untuk menangani versi sebelumnya dari kertas putih, jika ada (contohnya, mengarkibkan)

Pembaharuan piagam dan pembentangan cadangan kertas putih mesti dihantar untuk BARB review. Setelah kembaliview dan kelulusan pengemaskinian piagam oleh BARB, BSTS akan menyerahkan kemas kini piagam tersebut kepada Lembaga Pengarah untuk persetujuan bersama dengan pembentangan cadangan kertas putih yang menyokong.

Sekiranya Lembaga Pengarah menyetujui kemas kini piagam, kumpulan atau jawatankuasa boleh meneruskan penyusunan kertas putih.

Apabila kumpulan atau jawatankuasa telah menyelesaikan pengembangan kertas putih, BSTS akan melakukan penyuntingan semulaview untuk konsisten dengan Garis Panduan Penggubalan Bluetooth.

Selepas penyelesaian komen BSTS, kumpulan mesti menyerahkan kertas putih kepada BSTS untuk mendapatkan perundanganview. Setelah selesai re undang-undangview, kumpulan dan BSTS akan bersetuju dengan maklum balas yang akan dimasukkan ke dalam kertas putih. Sekiranya ada komen undang-undang yang tidak dapat diselesaikan dari undang-undang semulaview di kertas putih, ketua kumpulan boleh meminta waktu dalam agenda Dewan Pengarah untuk mendapatkan masukan daripada keputusan resolusi.

Selari dengan re undang-undangview, kumpulan mesti menyerahkan kertas putih kepada BARB untuk diulangview. Sebagai sebahagian daripada merekaview, BARB dapat mengesyorkan apakah ada bagian dari kertas putih yang harus dikeluarkan dari kertas putih dan dimasukkan ke dalam spesifikasi mengikuti proses dalam Bagian 3. BARB juga dapat memutuskan untuk menyerahkan kertas putih itu kepada kelompok atau komite lain untukview. Setelah selesai BARB review, kumpulan dan BARB akan bersetuju dengan maklum balas yang akan dimasukkan ke dalam kertas putih.

Setelah BARB meluluskan kertas putih, kertas putih yang disetujui BARB akan diserahkan oleh kumpulan pengarang atau jawatankuasa kepada Lembaga Pengarah untuk mendapat persetujuan.

Proses kertas putih selesai apabila Lembaga Pengarah telah meluluskan kertas putih dan aktiviti pasca persetujuan berikut telah selesai:

BSTS telah menyediakan kertas putih yang diluluskan untuk umum di Bluetooth SIG webtapak.
BSTS memberitahu semua ahli kertas putih yang diluluskan.
Sekiranya kertas putih adalah penambahbaikan daripada kertas putih yang ada, BSTS akan mengarkibkan versi kertas putih untuk diakses oleh ahli untuk tujuan sejarah.

Bluetooth SIG merancang untuk menyelesaikan aktiviti pasca persetujuan dalam masa satu minggu setelah kelulusan kertas putih itu.

10. Rujukan

Dokumen Bluetooth yang dirujuk boleh didapati dari Bluetooth webtapak http://www.bluetooth.com.

Garis Panduan Penggubalan Bluetooth (tersedia di halaman Templat & Dokumen Kumpulan Kerja, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Peraturan-Peraturan Bluetooth SIG, Inc. (tersedia di halaman Dokumen Pemerintahan, di https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Dokumen Proses Errata Spesifikasi Bluetooth (tersedia di halaman Templat & Dokumen Kumpulan Kerja, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Dokumen Proses Kumpulan Kerja (tersedia di halaman Templat & Dokumen Kumpulan Kerja, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Strategi dan Terminologi Ujian Selesaiview dokumen (tersedia di halaman Syarat Ujian Kelayakan, di https://www.bluetooth.com/specifications/qualification-test-requirements)
Spesifikasi BTI Review Senarai Semak Proses (tersedia pada halaman Templat & Dokumen Kumpulan Kerja, di https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Nombor Bluetooth SIG yang Ditugaskan (https://www.bluetooth.com/specifications/assigned-numbers)
Templat dan Dokumen Kumpulan Kerja (tersedia di halaman Templat & Dokumen Kumpulan Kerja, di https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Tambahan Spesifikasi GATT (GSS) (tersedia di halaman Spesifikasi GATT, di https://www.bluetooth.com/specifications/gatt)
Kirim Idea untuk Spesifikasi baru https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Akronim dan singkatan

Jadual A: Akronim dan singkatan

Lampiran A - Klasifikasi keparahan Erratum

Lampiran ini merangkum garis panduan klasifikasi keparahan untuk erratum spesifikasi. Jadual ini akan ditambahkan ke semakan EPD yang akan datang, dan kemudian bahagian ini akan dihapuskan.

Baca Lebih Lanjut Mengenai Manual Ini & Muat Turun PDF:

Dokumen Proses Pengurusan Spesifikasi (SMPD) - PDF yang dioptimumkan
Dokumen Proses Pengurusan Spesifikasi (SMPD) - PDF asal

Soalan tentang Manual anda? Siarkan dalam komen!

Rujukan

Manual Pengguna