Документ за управување со спецификации (SMPD)

Овој документ, без оглед на неговиот наслов или содржина, не е спецификации за Bluetooth што подлежат на лиценците доделени од Bluetooth SIG Inc. („Bluetooth SIG“) и неговите членови според Договорот за лиценца за патент/авторско право на Bluetooth и Договорот за лиценца за заштитен знак Bluetooth.

ОВОЈ ДОКУМЕНТ Е ДОБИВЕН „КАКО ШТО Е“ И НЕГОВИТЕ ЧЛЕНОВИ И НИВНИТЕ ПОДРУЖНИЦИ НЕ ПРАВУВААТ ИЛИ ГАРАНЦИИ И СЕ ОДГОВОРУВААТ СИТЕ ГАРАНЦИИ, ИЗРАЗНИ ИЛИ ИМПЛИЦИРАНИ, ВКЛУЧУВАЈЌИ БИЛО БИЛО БИЛО, , ФИТНЕС ЗА СЕКОЈА ПОСЕБЕНА НАМЕ, ДЕКА СОДРЖИНАТА НА ОВОЈ ДОКУМЕНТ Е БЕЗ ГРЕШКИ.

ВО СТЕМЕН КОЈ НЕ Е ЗАБРАНЕТ СО ЗАКОН, BLUETOOTH SIG, НЕГОВИТЕ ЧЛЕНОВИ И НИВНИТЕ ПОДРУЖНИЦИ СЕ ОДГОВОРУВААТ ОД ЦЕКАТА ОДГОВОРНОСТ КОЈА ПРОИЗЛЕГУВА ИЛИ ОД КОРИСТЕЊЕТО НА ОВОЈ ДОКУМЕНТ И СЕКОЈА ИНФОРМАЦИЈА ИНФОРМАЦИИ, ИНФОРМАЦИИ , ПОДАТОЦИ ИЛИ ПРОГРАМИ ИЛИ БИЗНИС ПРЕКИН, ИЛИ ЗА ПОСЕБНИ, ИНДИРЕКТНИ, СОСЛЕДНИЧКИ, СЛУЧАЈНИ ИЛИ КАЗНЕНИ ШТЕТИ, СЕПАК ПРИЧИНИЦА И БЕЗ РАЗЛИКА ОД ТЕОРИЈАТА НА ОДГОВОРНОСТА, И ДУРИ И АКО БЛУТОТ ГО ЗГОЛЕМУВА МОЖНОСТ НА ВАКВИ ШТЕТИ.

Овој документ е сопственост на Bluetooth SIG. Овој документ може да содржи или покрива тема која е интелектуална сопственост на Bluetooth SIG и неговите членови. Доставувањето на овој документ не дава никаква лиценца за каква било интелектуална сопственост на Bluetooth SIG или на неговите членови.

Овој документ е предмет на промена без претходна најава.

Авторски права © 2004–2019 од Bluetooth SIG, Inc. Зборовниот знак и логоата на Bluetooth се во сопственост на Bluetooth SIG, Inc. Другите брендови и имиња од трети страни се сопственост на нивните соодветни сопственици.

1. Вовед

Документот за процесот на управување со спецификациите (SMPD) ги опишува процесите што ги создаваат спецификацијата и повторноviewТие мора да следат за да развијат нови спецификации и да ги подобрат постоечките спецификации (т.е. да додаваат или отстрануваат функционалност или да променат специфична функционалност во усвоена спецификација), да ги одржуваат усвоените спецификации и да управуваат со крајот на животниот век на усвоените спецификации. Дополнително, овој документ го опишува процесот за креирање, реviewИНГ, и одобрување на бели документи.

Постојат разлики во процесот на развој на спецификациите помеѓу развивањето нови спецификации и подобрувањето на постоечките спецификации поради вродените разлики во опсегот на тие задачи; тие разлики се нагласени во овој документ.

Процесот на развој на спецификација вклучува:

Фаза на барања (опишана во Дел 3) за дефинирање на функционалните барања
Развојна фаза (опишана во Дел 4) за развој и повторноview спецификации

Фаза на валидација (опишана во Дел 5) за потврдување на спецификациите со помош на тестирање за интероперабилен прототип (ИОП)
Фаза на усвојување/одобрување (опишана во Дел 6) за презентирање на спецификациите на Одборот на директори на Bluetooth SIG (BoD) за усвојување/одобрување

Документот Specification Errata Process (EPD) [3] го опишува процесот за предлагање и повторноviewвнесување грешни спецификации и нивно одобрување како корекции на погрешни (како што е дефинирано во подзаконските акти [2]) до усвоените спецификации. Освен ако не е поинаку наведено, сите референци на грешни во овој SMPD значат погрешни спецификации.

1.1 Предност

Подзаконските акти на Bluetooth SIG, Inc. (Подзаконски акти) и договорите за членство [2] имаат предност пред секоја спротивставена содржина во тие документи и SMPD. Без оглед на што било во овој документ, ОД ја задржува крајната дискреција и овластување да презема дејствија и да донесува одлуки дури и ако тие дејствија и одлуки не следат, или не се во спротивност со ништо во овој документ, и ништо во овој документ не ја ограничува или ограничува независната власт на ОД и дискреција.

Ако има некакви конфликти помеѓу текстот во SMPD и бројките, текстот има предност.

1.2 Референцирани групи и комисии

Следниве типови на групи се наведени во овој документ: студиски групи (СГ), експертски групи (Г) и работни групи (РГ). РГ исто така може да има подгрупа што поднесува извештај до РГ. Слично, во овој документ се референцирани следниве типови на комитети: Bluetooth Architectural Review Табла (BARB), Bluetooth тест и интероперабилност (BTI) и Bluetooth Qualification Review Одбор (BQRB). Овој документ се однесува и на техничкиот персонал на Bluetooth SIG (BSTS) и на ОО.

1.3 Комитетот реviewи одобренија

Комисија реview е реview што се спроведува од членови на комисија (обично 3 члена) за да се обезбеди повратна информација во одредено време (обично 2-3 недели), ноview времето може да варира во зависност од должината и сложеноста на материјалот и другите приоритети во рамките на комисијата. Групата која бара реview и комисијата што ја спроведува реview секој се согласува за времетраењето на реview. Групата и членовите на комисијата ги користат алатките Bluetooth SIG за да го известат и снимаат почетокот и крајот на повторнотоview. Групата генерално ќе ги обработува повратните информации од комисијата кога ќе бидат примени. Кога комисијата реview времето истекува, групата го завршува обраќањето до повратните информации на комисијата, а исто така треба да размисли за секое задоцнето пристигнувањеview повратни информации имајќи предвид дека материјалот може да биде предмет на последователно одобрување од страна на комисијата.

Одобрувањето од комисијата се добива со гласање на членовите на комисијата во согласност со Документот за процесот на работната група [4].

1.4 Известувања до членовите и пристапност до материјалите

Сите известувања доставени до членовите во согласност со овој документ може да се достават преку е-пошта, како што е периодично техничко ажурирање. Известувањата што треба да се достават до сите членови ќе бидат испратени до сите активни членови (т.е. каде членството не е суспендирано, прекинато или повлечено). Кога известувањата се испраќаат преку е-пошта, тие ќе бидат испратени на последната позната адреса на е-пошта (како што се гледа во тогашните записи на Bluetooth SIG) на секој поединец кој се регистрирал на сметката за членство на компанијата-членка и кој не се откажал од примање известувања по е-пошта. Ништо во овој документ не ги менува обврските или барањата на Bluetooth SIG во однос на обезбедувањето известување според подзаконските акти или кој било друг договор помеѓу Bluetooth SIG и кој било член.

Секаде каде што овој документ се однесува на а webстраница која е достапна за сите членови, ова се однесува на пристапност на поединци кои имаат активна сметка на Bluetooth SIG. Членовите кои немаат активна сметка може да креираат сметка преку Bluetooth SIG webсајт.

1.5 Шаблони

За секој тип на документ (на пр., спецификации, бели документи, тест документи) наведени во овој SMPD, Bluetooth SIG обезбедува образец. Шаблонот мора да се користи како основа за секој документ произведен во согласност со овој SMPD. Неуспехот да се користи точниот образец може да доведе до тоа документот да не биде одобрен. Шаблони се достапни на Bluetooth SIG webсајт [8].

1.6 Типови на спецификација

Постојат неколку типови на Bluetooth SIG спецификации. Хиерархиски, сите спецификации зависат од спецификациите за јадрото на Bluetooth. Спецификации како што се традиционалните проfiles; традиционални протоколи; и про-базирани на ГАТТfiles, услугите базирани на ГАТТ и протоколите базирани на ГАТТ зависат од карактеристиките во Основната спецификација. Другите спецификации, како што се спецификациите на Mesh Model, зависат од Mesh Profile спецификација која пак зависи од Основната спецификација.

Спецификациите за Додаток за основни спецификации (CSS) ги дефинираат типовите на податоци, форматите на податоци и заедничките проfile и шифрите за грешка на услугата што се користат од Основната спецификација и другите спецификации и самите не дефинираат никакви однесувања.

Спецификациите за додатокот за спецификација на ГАТТ (GSS) ги дефинираат форматите на карактеристични и дескриптори што се користат од Profiles и Services и самиот не дефинира никакво однесување.
Спецификацијата Mesh Device Properties (MDP) ги дефинира својствата на решетката што ги користи Mesh Profile и спецификациите на Mesh Model и самиот не дефинира никакви однесувања.

2. Во текотview

Овој дел обезбедува надview на процесите и не е наменет да ги вклучи сите детали.

Слика 2.1 ги прикажува шесте главни фази кои го сочинуваат Процесот за управување со спецификациите.

Првите четири фази се случуваат за време на процесот на развој на спецификацијата и се состојат од Фаза на барања (Дел 3), Фаза на развој (Дел 4), Фаза на валидација (Дел 5) и Фаза на усвојување/одобрување (Дел 6). Ова е проследено со две фази по усвојувањето: фаза на одржување на спецификација (Дел 7) и фаза на спецификации на крајот на животниот век (Дел 8).

Слика 2.2 илустрира детали за четирите фази во рамките на процесот на развој на спецификација. Сивите полиња ги означуваат главните испораки за секоја фаза. Портокаловите кутии ги сумираат процесните пресвртници.

Во фазата на барања (опишана во Дел 3), предлогот за започнување на нова работа (Нов работен предлог (NWP)) го започнува процесот на развој на спецификација со дефинирање на сценаријата на корисникот што треба да се овозможат доколку новата работа продолжи. Ако NWP е одобрен, доделената група создава Документ за функционални барања (FRD). Откако FRD е одобрен и доделен на група, започнува Развојната фаза.

За време на развојната фаза (опишана во Дел 4), развојот на спецификацијата напредува низ низа од stages (0.5/DIPD до 0.9/CR) што кулминира со комплетен нацрт на спецификацијата. Спецификацијата 0.9/CR се става на располагање на сите членови, а потоа се доставува до ОД кој ја разгледува спецификацијата за одобрување. Откако ќе се одобри, започнува фазата на валидација.

За време на фазата на валидација на развојот на спецификациите (опишана во Дел 5), спецификацијата 0.9/CR одобрена од ОД им е достапна на сите членови за повторноview и потврди, и Член Реview е започната. Валидацијата се остварува преку тестирање за интероперабилност (IOP) помеѓу прототипови кои се изградени од членовите. Откако ќе се заврши тестирањето на ИОП (ако е потребно за спецификацијата) и BARB ќе го одобри извештајот од тестот за ИОП, тогаш започнува Фазата на усвојување/одобрување.

За време на фазата на усвојување/одобрување (опишана во Дел 6), спецификацијата и поврзаните тест документи се финализирани; Се добиваат одобренија BARB, BQRB и ОТИ; а конечниот пакет на спецификација се доставува до ОД кој ја разгледува спецификацијата за усвојување (т.е. конечно одобрување).

Спецификацијата можеби ќе треба да се врати во претходната фаза или stagд доколку се направат значителни промени. Во некои случаи, исто така може да биде можно да се откаже од дел од фазата како што е опишано во Дел 4.4.

Фазата на одржување на спецификацијата (опишана во Дел 7) започнува по усвојувањето на спецификацијата од страна на Одборот на Одборот. Во текот на оваа фаза се пријавуваат и оценуваат потенцијалните грешки пронајдени во усвоената спецификација и (доколку е потребно) се прават погрешни корекции на спецификацијата. Фазата на одржување на спецификацијата продолжува сè додека спецификацијата не биде застарена или повлечена (видете Фаза на крајот на животниот век на спецификацијата во следниот параграф).

Фазата на крајот на животниот век на спецификацијата (опишана во Дел 8) го опишува процесот за отфрлање и повлекување на усвоените спецификации.

3. Фаза на барања

Фазата на барања започнува или со NWP (во која се наведува желбата да се иницира работа на едно или повеќе кориснички сценарија) или откако ќе се утврди дека посакуваната нова работа е веќе покриена со нивната повелба на WG. Ако РГ сака да започне нова работа за која верува дека е веќе во опсегот на нејзината повелба на РГ, РГ мора да го следи процесот дефиниран во Дел 3.1 за да продолжи директно кон развивање на FRD. За сите други работни ставки, РГ мора да го следи процесот дефиниран во Дел 3.2. FRD го дефинира опсегот на функционалните барања што се користат за градење спецификации во Развојната фаза. Фазата на барања е илустрирана на Слика 3.1.

3.1 Нова работа покриена со повелба на РГ

Кога WG сака да започне нова работа и разумно верува дека функционалноста што сака да ја додаде е веќе во опсегот на нејзината повелба на WG, WG може да започне со работа на FRD, под услов веднаш да го извести BARB. РГ ќе вклучи во своето известување до BARB опис на предложеното ново дело и копија од повелбата на РГ со нагласен јазик што ги овластува да започнат со новата работа.

Ако BARB ја отфрли анализата на WG, WG мора да ја прекине работата на FRD и да продолжи со процесот NWP наведен во Дел 3.2. Доколку BARB ја одобри анализата на РГ, РГ веднаш ќе го извести BSTS (преку е-пошта до specification.manager@bluetooth.com) и BSTS ќе ја додаде точката во следниот дневен ред на ОО.

РГ ќе ги вклучи во своето известување до BSTS истите информации што ги достави до BARB. Доколку одборот ја отфрли анализата на РГ, РГ мора да ја прекине работата на FRD и да продолжи со процесот на NWP наведен во Дел 3.2. Доколку ОД ја одобри анализата на РГ, РГ може да продолжи да работи на ФРР како што е наведено во Дел 3.3.

3.2 Нов работен предлог (NWP)

Секој член, WG, SG или EG може да создаде и поднесе NWP (преку Bluetooth SIG webсајт [10]). NWP мора да вклучува, минимум, информации за следново користејќи го официјалниот образец даден во [8]:

Кориснички сценарија
Посветеност на членовите за развој на FRD и во која област(и) (на пр. Соработник, автор, Reviewер, прототип)

Предложено раководство на работата на ФРД
Предложена групна задача за работата на ФРД
Адреса на е-пошта на примарниот(и) автор(и)

Забелешка: Насоките за процесот NWP се достапни на Bluetooth SIG webсајт [10].

BSTS ќе ги извршува следните задачи за време на развојот на NWP:

Обезбедете му на авторот(ите) потврда за прием (обично во рок од седум календарски дена од приемот) и наведете ги следните чекори.

Доколку е потребно, работете со авторот(ите) за NWP да биде јасен и целосен. Ова може да бара неколку повторувања на NWP.
Ако NWP содржи изјави за грешки во усвоените Bluetooth спецификации, соработувајте со авторот(ите) на file записи во системот за грешки.
Ако се забележи дека NWP потенцијално ја дуплира работата што е веќе во тек или е веќе завршена, известете го авторот(ите) на другото дело за нивна евалуација.

Објавете го NWP на NWP webстраница достапна за сите членови.
Известете ги сите членови дека NWP е достапен за повторноview и дали е потребна дополнителна посветеност на членовите за развој на FRD.

Членовите може да контактираат со авторот(ите) за да поставуваат прашања или да дадат повратни информации во врска со NWP.

Најмалку три компании-членки мора да се обврзат да учествуваат во завршувањето на добиениот FRD за NWP да стане кандидат за одобрување од ОО, а најмалку една компанија-членка мора да биде членка соработник или промотор. По одобрувањето на НВП од страна на Одборот, Одборот ќе го додели НВП на постоечка подгрупа на РГ или СГ за сите членови да работи на ФРР (опишано во Дел 3.3). Доколку не постои соодветна подгрупа на WG или SG, може да се создаде.

За NWP кои имаат доволно посветеност на членовите, BSTS ќе ги изврши следните дополнителни задачи:

Најмалку 13 дена пред НВП да биде предложено да биде одобрено од Одборот, известете ја BARB и групата на која се препорачува NWP за доделување, за очекуваното одобрување NWP. Ова е направено за да се обезбеди можност за повратни информации во области како што е предложената група, дали НВП е веќе покриена со постојната работа итн.

Доставете го пополнетиот НВП до ОД.

Ако NWP е поднесен од членови кои не се поврзани со група, договорете еден од членовите да го претстави NWP на Одборот.
Ако NWP е поднесена од група, организирајте претседавачот на групата да го претстави NWP на Одборот.

Поканете го претседавачот на BARB и претседавачите на групата, на кои им се препорачува NWP за задача, на состанокот на ОД.
Доколку НВП е одобрена и доделена од страна на ОД, известете ја групата на која и е доделена; авторот(ите); членовите идентификувани во NWP дека се обврзуваат да развијат соодветни FRD; и ако NWP е предложена од група, групата на исходот и следните чекори.

Откако ќе се одобри NWP од страна на Одборот, ажурирајте го статусот на NWP webсајт.

Секое NWP може да биде отфрлено од страна на ОД по своја дискреција, на прampLe, поради ограничувањата на ресурсите, ако работата е веќе целосно завршена, работата е надвор од опсегот на управувачките документи на Bluetooth SIG (на пр., Апликацискиот програмски интерфејс (API)) [2], или ако предложената работа треба да биде fileг како грешка. Ако NWP се одбие, BSTS ќе го извести авторот(ите), членовите идентификувани во NWP дека се обврзуваат да го развијат соодветниот FRD и, ако NWP е предложен од група, групата. Известувањето ќе ги содржи сите причини за одбивањето. Авторот(ите), посветените членови или групата може да побараат време на дневниот ред на ОО за жалба на одбивањето.

Ако некој член или група сака да предложи отстранување на карактеристика од усвоена спецификација, групата или членот мора да подготви NWP. NWP мора да вклучи анализа на влијанието што ќе го има отстранувањето врз компатибилноста и интероперабилноста наназад, вклучително и анализа на влијанието врз случаите на тестирање.

NWP не се потребни за подобрувања на спецификациите на CSS, GSS или MDP: обично, ажурирањата на спецификациите на CSS, GSS или MDP произлегуваат од ажурирања на други спецификации кои имаат свои NWP.

3.3 Документ за функционални барања (FRD)

FRD ги дефинираат функционалните барања за да се овозможат кориснички сценарија. FRD мора да вклучува, минимум, информации за следново користејќи го официјалниот образец даден во [8]:

Кориснички сценарија
Функционални барања врз основа на корисничките сценарија

Посветеност на членот за развивање на добиената спецификација(и)
Изборна поддршка за прототип од членовите за предвидените улоги
Препорачана WG да ја развие добиената спецификација(и)

Развој на FRD

FRD се креирани од назначената подгрупа на WG со сите членови или членови на SG со уредничка поддршка од BSTS. Секој член заинтересиран за учество во развојот на FRD може да се приклучи на групата.

FRD мора да наведат посветеност од најмалку две (иако три се охрабруваат) компании-членки на ниво на соработник или промотор да учествуваат во развојот на добиената спецификација. РГ или СГ кои поднесуваат FRD треба да се обидат да постигнат широка поддршка од компаниите-членки на групата кои го претставуваат наменетиот сегмент од индустријата за цел идентификуван во FRD.

Новата функционалност што е предложена во FRD треба да може да се поддржи на што е можно повеќе транспорти и постоечки уреди. Ова вклучува, на прample, поддржувајќи го про-базираниот ГАТТfiles и услуги за транспортот на основната стапка/проширена стапка на податоци (BR/EDR) и транспортот со Bluetooth ниска енергија (LE). Ако новата функционалност нема доволна поддршка од членовите за транспорт, на прampПоради недостаток на посветеност на членовите за дефинирање на употребата на транспортот или потенцијално недоволен број платформи за тестирање IOP за една или повеќе улоги, поддршката за тој транспорт може да биде исклучена од FRD.

Освен ако не е поинаку оправдано, нова функционалност, проfileи услугите мора да бидат усогласени со барањата за компатибилност наназад опишани во Дел 3.3.2.

WG или SG мора да го достават FRD до BARB за повторноview и одобрување. BARB мора или да го одобри или отфрли FRD врз основа на неговата инженерска проценка. Доколку биде одобрен од BARB, FRD ќе им биде достапен на сите членови и известување за неговата достапност ќе биде издадено од BSTS.

FRD не се потребни за подобрувања на спецификациите на CSS, GSS или MDP: обично, ажурирањата на спецификациите на CSS, GSS или MDP произлегуваат од ажурирања на други спецификации кои имаат свои FRD.

Барања за компатибилност наназад

Назад компатибилност за BR/EDR

За работа со BR/EDR, барањето за компатибилност наназад е дефинирано како интероперација со делот BR/EDR од спецификациите за јадрото на Bluetooth v1.1 и понова верзија.

Назад компатибилност за Bluetooth ниска енергија

За работа со LE, барањето за компатибилност наназад е дефинирано како интероперација со делот LE од спецификациите за јадрото на Bluetooth v4.0 и понова верзија.

Назад компатибилност за спецификации различни од Основната спецификација

За спецификации различни од спецификациите за јадрото на Bluetooth, наназад компатибилноста на дадената верзија мора да се одржува со сите претходни верзии што го имаат истиот број на главната верзија. За прample, верзијата 1.3 мора да биде компатибилна со верзиите 1.2, 1.1 и 1.0, но верзијата 2.0 може да не е компатибилна со верзиите 1.0, 1.1, 1.2 и 1.3. Забележете дека зголемувањето на бројот на главната верзија на Основната спецификација не значи недостаток на компатибилност наназад со претходните верзии.

Ослободување од барањата за компатибилност наназад

WG или SG може да предложат изземање на одредена функционалност од барањето за компатибилност наназад доколку се обезбеди оправдување. За прampLe, ако се покаже дека функционалноста има ниски стапки на усвојување на пазарот или, поради проблеми со интероперабилноста, подобро е да се отстрани или замени функционалноста отколку да се менува функционалноста. WG или SG мора да ги вклучат сите исклучоци за компатибилност наназад во FRD, кои се одобрени од BARB по одобрение од FRD. Сите исклучоци одобрени од BARB ќе бидат претставени на одобрување до Одборот за одобрување на 0.9/CR Stage.

3.4 Повелба на работната група

Кога BARB одобрува FRD што се предлага да се додели на постоечка WG, таа WG мора да подготви нацрт ажурирање на својата повелба за да ја додаде новата функционалност на опсегот (освен ако одборот претходно ја одобрил анализата на WG дека ажурирањето на повелбата на WG е Не е потребно). Меѓутоа, кога BARB одобрува FRD што се предлага да се додели на нова WG, BARB и членовите кои се заинтересирани за развивање на функционалноста наведена во FRD мора да подготват нацрт-повелба за нова WG со новата функционалност вклучена во опсегот на повелбата .

Откако ќе се подготви новата или ажурирана повелба на WG, таа мора да се достави до BARB за повторноview и одобрување. Откако БАРБ ќе ја одобри повелбата, нацртот на новата или ажурирана повелба на РГ ќе биде доставен до Управниот одбор на одобрување.

Штом Управниот одбор ќе ја одобри повелбата, РГ на која и е доделена работата за изработка на спецификации од Одборот мора тесно да соработува со групата која го подготви FRD во случај да бидат потребни какви било неопходни ажурирања или појаснувања на тој FRD. Доколку е потребно ажурирање на FRD за време на Развојната фаза, мора да се следат процесите наведени во Дел 3.3 и овој дел; сепак, развојот на спецификациите може да се случи паралелно со ажурирањата на повелбата на FRD и WG.

3.5 Барања Барања за излез од фазата

Фазата на барања е завршена и фазата на развој започнува кога повелбата на РГ со неопходен опсег за ФРР ќе биде потврдена или одобрена од страна на ОД и ќе бидат исполнети следните барања:

НВП е или одобрен од ОО, или ОД се согласи дека НВП е непотребен.

Повелбата на FRD и соодветната РГ е одобрена од BARB.

4. Развојна фаза

За време на Развојната фаза, доделените WG(и) ја креираат новата спецификација и/или ја подобруваат постоечката спецификација. FRD ги дефинира барањата на новата или подобрена Bluetooth спецификација. Ниту една функционалност не е дозволена во спецификацијата што не е разумно поврзана со барањата во FRD. Целта е да се создаде спецификација 0.9/CR која е подготвена за фазата на валидација (опишана во Дел 5) на крајот од Развојната фаза.
За време на Развојната фаза, спецификацијата (или подобрувањето на спецификацијата) напредува низ три секундиtagес.

За нова спецификација, трите сtagтие се:

0.5 Сtage
0.7 Сtage

0.9 Сtage

За подобрување на спецификациите, трите сtagтие се:

Нацрт-документ за предлог за подобрување (DIPD) Сtage

Документ за финален предлог за подобрување (FIPD) Сtage
Барање за промена (CR) Сtage

Секој сtage е опишано понатаму во потсекциите што следат. Слика 4.1 подолу ги илустрира различните документи што РГ ќе ги подготви на секој stage.

Слика 4.1: Готовоview на спецификацијата сtagшто се случуваат за време на Развојната фаза

Улогата на BARB во текот на процесот на развој на спецификацијата е да им дава совети и техничка помош на WG. РГ може, во секое време, да поднесат барања до BARB за технички совети во врска со развојот на спецификациите и архитектонските концепти што ќе се користат во спецификацијата. РГ се особено охрабрени да бараат рани повратни информации од BARB за карактеристики кои имаат посложени архитектонски размислувања.

4.1 0.5/DIPD Stage

Во текот на 0.5/DIPD Сtagд, WG ќе го развие следново користејќи ги официјалните шаблони дадени во [8]:

За нова спецификација, нацрт на спецификацијата 0.5, која мора да содржи, минимум, информации за следново:

Архитектура за покривање на барањата како што е наведено во FRD

За протоколи, дефинирани се сервисни пристапни точки
За услуги, изложени податоци и однесување
За проfiles, идентификувани протоколи и специфицирана функционалност

2. За подобрување на спецификациите, нацрт на DIPD, кој мора да содржи, минимум, информации за следново:

Позадина: Обемот на работа, целите што ја водат работата и како овој конкретен предлог се вклопува во опсегот
Во текот наview на предлог: Резиме на проширената функционалност (додадена флексибилност, подобрени перформанси итн.) обезбедени од DIPD, вклучувајќи јасен опис за тоа како новата функционалност се вклопува во тековната верзија на спецификацијата. Доколку РГ има оценето повеќе предлози, овие предлози треба да се вклучат за да ѝ се овозможи на BARB можност да утврди дали е направено доволно длабинско внимание при изборот на претпочитаниот предлог.

Покривање на барања: Резиме на покриеноста на функционалните барања дадена со предлогот, со упатување на соодветните системски барања и сценарија за користење дадени во поврзаниот FRD
Дефиниција на проблемот: Изјава за проблемите решени со предлогот(ите)
Критериуми за избор: Изјава во врска со критериумите за избор/перформанси од придружните метрики за евалуација кои го воделе процесот на селекција

Оправдување на изборот: Испитување на метриката за евалуација која го оправдува изборот помеѓу предлозите и открива компромиси
Опис: Опис на функционалноста и проширените протоколи. Овој дел може да се прилагоди на различни потреби со додавање на релевантни под-секции.

3. Тест стратегија: Опис на функционалноста која е предложена да се тестира (или не се тестира) како дел од Програмата за квалификација на Bluetooth и како функционалноста се предлага да се тестира (на пр. очекувања за долниот тестер или горниот тестер) и ако тестовите ќе се припишат како тестови за усогласеност или интероперабилност или комбинација од двете). Ова може да биде во посебен документ или посебен дел во спецификацијата 0.5/DIPD. Конвенциите што треба да се користат во Стратегијата за тестирање се опишани во Стратегијата за тестирање и Терминологијатаview документ (TSTO) [5].

Примарната публика на документите на овој сtagе членовите на РГ и БАРБ кои реview архитектонските предлози и барањата покриеност, и ОТИ кои реviewе Тест стратегијата. Во повеќето случаи документите кај овој сtage не се наменети да содржат текст што се планира да се вклучи во конечната спецификација.

BSTS мора повторноview сите документи за усогласеност со Упатствата за изработка на Bluetooth [1] и идентификување на проблемите што треба да ги реши РГ. BARB мора повторноview спецификацијата 0.5/DIPD. За подобрување на спецификациите, BARB исто така мора повторноview DIPD за усогласеност со барањата за компатибилност наназад опишани во Дел 3.3.2. ОТИ мора повторноview Тест стратегијата.

BARB мора или да ја одобри или отфрли спецификацијата 0.5/DIPD врз основа на неговата инженерска проценка. Доколку е одобрена од BARB, спецификацијата 0.5/DIPD ќе биде достапна на Bluetooth SIG webстраницата до сите членови на Асоцијација и Промотор и известувањето за неговата достапност ќе биде издадено од BSTS. На 0.5/DIPD Сtagд, не е потребно одобрување на Стратегијата за тестирање.
0.5/DIPD Stage не е потребно за подобрувања на спецификациите на CSS, GSS или MDP

0.5/DIPD Stagбарања за излез

0.5/DIPD Stage е завршена и 0.7/FIPD Stage започнува кога ќе се исполнат следните барања за излез:

BSTS го заврши повторнотоviewсо 0.5/DIPD спецификација и тест стратегија.

BARB ја одобри спецификацијата 0.5/DIPD.
ОТИ ја заврши својата реview на Стратегијата за тестирање.
BSTS ја направи одобрената спецификација 0.5/DIPD достапна за сите членови на соработници и промотори.

4.2 0.7/FIPD Stage

Во текот на 0.7/FIPD Сtagд, WG ќе го развие следново користејќи ги официјалните шаблони дадени во [8]:

За нова спецификација, нацрт на спецификацијата 0.7, која мора да содржи, минимум, информации за следново:

Опис на сите промени што беа направени од 0.5 одобрениот од BARB, вклучувајќи нови или изменети предлози, критериуми за избор и оправдување на изборот. Промените мора да се опишат на исто ниво на детали како што се бара во 0.5 Stage.

Решени се сите функционални барања од FRD.

2. За подобрување на спецификациите, нацрт на FIPD, кој мора да содржи, минимум, информации за следново:

Опис на сите промени што беа направени од DIPD одобрениот од BARB, вклучувајќи нови или изменети предлози, критериуми за избор и оправдување на изборот. Промените мора да се опишат на исто ниво на детали како што се бара во DIPD Stage.

По потреба, дополнително развиени области кои беа опишани во Дел 4.1 во врска со DIPD.
Завршен опис на подобрувањето.
Ажуриран архитектонски опис.
Решени се сите функционални барања од FRD.

3. 0.7/FIPD тест документи, кои мора да вклучуваат, минимум, информации за следново:

Тест пакет, кој се состои од листа на цели за тестирање како што е опишано во TSTO [5].
Изјава за усогласеност со имплементацијата (ICS), како што е опишано во TSTO [5].

За подобрување на спецификациите, пакетот за тестирање и ICS може да се достават или како посебни документи или како дополнителни делови во FIPD.

Примарната публика на документите произведени на овој сtagе членовите на РГ и БАРБ кои реview целосниот опис на карактеристиката или подобрувањето, вклучувајќи некој текст планиран за вклучување во конечната спецификација. ОТИ е публиката за реview на документите за тестирање.

BSTS ќе реview новите или изменетите делови од 0.7/FIPD спецификацијата и документите за тестирање за усогласеност со Упатствата за изработка на Bluetooth, вклучувајќи јазични конвенции воспоставени од Bluetooth SIG. BARB ќе реview спецификацијата 0.7/FIPD.

BSTS ќе му помогне на WG во подготовката на документите за тестирање 0.7/FIPD во согласност со TSTO [5].

ОТИ мора повторноview 0.7/FIPD тест документи. РГ мора да ја обезбеди спецификацијата 0.7/FIPD на ОТИ како референца кога повторноviewИНГ 0.7/FIPD тест документи, кои ОТИ ќе ги реview во согласност со ОТИ спецификација Review Список за проверка на процесот [6].

Откако BARB ќе го заврши своето повторноview од спецификацијата 0.7/FIPD и ОТИ ја заврши својата реview од 0.7/FIPD тест документите, BSTS ќе го направи реviewed 0.7/FIPD спецификација достапна за сите соработници и членови на промотори.

0.7/FIPD Stage не е потребно за подобрувања на спецификациите на CSS, GSS или MDP.

0.7/FIPD Stagбарања за излез

0.7/FIPD Stage е комплетен и 0.9/CR Stage започнува кога ќе се исполнат следните барања за излез:

BSTS го заврши повторнотоviewсо 0.7/FIPD спецификација и документи за тестирање.
BARB заврши повторноviewсо спецификацијата 0.7/FIPD.
ОТИ има завршено повторноviewсо 0.7/FIPD тест пакет (цели за тестирање) и 0.7/FIPD ICS.
BSTS го направи повторнотоviewed 0.7/FIPD спецификација достапна за сите соработници и членови на промотори.

4.3 0.9/CR Сtage

Постојат два типа на CR: Интегриран CR, кој е документ следен со промени на целата усвоена спецификација што ги прикажува сите промени од претходната верзија, и скратен CR, кој е документ кој обезбедува упатства за менување само на засегнатите делови од верзијата на спецификацијата на која се базира CR.

Во текот на 0.9/CR Сtagд, WG ќе го развие следново користејќи ги официјалните шаблони дадени во [8]:

За нова спецификација, нацрт на спецификацијата 0.9 со целосна содржина, која мора да содржи, минимум, информации за следново:

Опис на сите промени што беа направени од BARB-реviewed 0.7 спецификација (или бидејќи спецификацијата 0.5, ако производството на спецификацијата 0.7 е откажано), вклучувајќи нови или
изменети предлози, критериуми за избор и оправдување на изборот. Промените мора да се опишат на исто ниво на детали како што се бара во 0.5 Stagд и 0.7 Сtage.

2. За подобрување на спецификациите:

Или интегриран CR, кој мора да вклучува, минимум, информации за следново:
Опис на сите промени што беа направени од BARB-реviewed FIPD (или од DIPD ако FIPD е откажана) вклучувајќи нови или изменети предлози, критериуми за избор и оправдување на изборот. Промените мора да се опишат на исто ниво на детали како што се бара во DIPD Stagд и ФИПД Сtage.
Сите промени предложени на претходно усвоената спецификација со користење на следење на промени.
Сите одобрени технички грешки (со секоја грешка референцирана со погрешен број), прикажани со помош на следење на промените, кои допрва треба да се вградат во претходно усвоената верзија на спецификацијата, и тој текст на влијание што е поврзан со подобрувањето на спецификацијата; или што на друг начин влијае на тестирањето на ИОП.

3. Или скратен CR, кој мора да содржи, минимум, информации за следново:

Опис на сите промени што беа направени од BARB-реviewed FIPD (или од DIPD ако FIPD е откажана) вклучувајќи нови или изменети предлози, критериуми за избор и оправдување на изборот. Промените мора да се опишат на исто ниво на детали како што се бара во DIPD Stagд и ФИПД Сtage.
Сите промени предложени за секој засегнат дел и став од спецификацијата што КР предлага да се промени.
Сите одобрени технички грешки (со секоја грешка референцирана со погрешен број), прикажани со ознака, кои допрва треба да се вградат во претходно усвоената верзија на спецификацијата, и тој текст на влијание што е поврзан со подобрувањето на спецификацијата; или што на друг начин влијае на тестирањето на ИОП.

4. CSS CR (ако се бараат нови записи според спецификацијата), кој може да биде вграден во Скратен CR на спецификацијата.
5. GSS CR (ако се бараат нови записи според спецификацијата), кој може да биде вграден во Скратен CR на спецификацијата.
6. MDP CR (ако се бараат нови записи според спецификацијата), кој може да биде вграден во Скратен CR на спецификацијата.
7. Документи за тестирање 0.9/CR, кои мора да вклучуваат, минимум, информации за следново користејќи го официјалниот образец даден во [8]:

Тест пакетот 0.9/CR, кој вклучува тест случаи со целосна содржина и поврзаната табела за мапирање на тест случаи (TCMT), како што е опишано во TSTO [5].
0.9/CR ICS, како што е опишано во TSTO [5].
Ако конфигурирањето на тестовите бара специфични параметри за имплементација под тест (IUT), 0.9/CR Implementation Extra Information for Testing (IXIT).
Референтна листа на тест случаи 0.9/CR (TCRL) (опционално за ажурирања на основните спецификации).

8. Анализа на покриеност на тестот што покажува кои барања за спецификации се или тестирани или не се тестирани во пакетот за тестирање 0.9/CR (за подобрувања на спецификациите, анализата на покриеноста на тестот треба да ги вклучи само новододадената и погодената функционалност, а не незасегнатите области на оригиналната спецификација).
9. План за IOP тест.

За подобрување на спецификациите, тест пакетот, ICS и IXIT може да се доставуваат или како посебни документи или како дополнителни делови во Скратениот CR.

Во повеќето случаи, интегриран или скратен CR треба да се заснова на претходно усвоената верзија на спецификацијата, но може да се заснова и на најновиот среден нацрт. Најновиот среден број на верзијата на спецификацијата на нацртот мора да биде бројот на верзијата поврзан со верзијата на документот што е замрзната и која нема да се промени со текот на времето. Во спротивно, дополнителни информации за идентификација (како датумот на документот и а URL до постојана локација) мора да бидат обезбедени за да се идентификува специфичната верзија на „основната линија“. Ако се користи среден нацрт, сите промени кои не се директно поврзани со CR во даден дел што CR го менува мора да бидат вклучени, но не се бара да се прикажуваат со означување. Ако релевантните делови од средниот нацрт подоцна се ажурираат, CR мора да се ажурира за да ги одрази ажурирањата на средниот нацрт.

Идеално, скратениот CR материјал е интегриран во нацрт на комплетната спецификација и комплетните тест документи, соодветно, пред фазата на валидација, но тие исто така може да се интегрираат на почетокот на фазата на валидација. Ако се развиваат повеќе функции за спецификација (на пр. Основна спецификација), можеби е пожелно да се интегрираат карактеристиките во еден нацрт откако ќе заврши IOP тестирањето.

BSTS ќе реview 0.9/CR спецификацијата и документите за тестирање за усогласеност со Упатствата за изработка на Bluetooth. Тогаш BARB ќе се реview спецификацијата 0.9/CR, проследена подоцна со планот за тестирање IOP (како што е опишано во Дел 4.3.1). Откако 0.9/CR спецификацијата ќе биде поднесена од WG до BARB за повторноview, BSTS ќе го направи пристапен за сите членови за повторноview и да ги извести сите членови за неговата достапност. Од овој момент, во процесот на развој на спецификации, BSTS ќе направи нацрти на спецификацијата доставени до BARB достапни за сите членови со периодични известувања испратени до сите членови.

За подобрување на спецификациите, РГ ќе му препорача на одборот дали претходните верзии на спецификацијата треба да бидат застарени или повлечени, вклучувајќи ги техничките причини за препораките.

BARB ќе реview анализата на WG за усогласеноста на спецификацијата 0.9/CR со барањата дадени во FRD, какви било потенцијални безбедносни проблеми, какви било регулаторни проблеми, усогласеност со архитектурата Bluetooth и, за подобрување на спецификацијата, усогласеност со барањата за компатибилност наназад опишани во Дел 3.3.2 .XNUMX. Доколку BARB идентификува потенцијални безбедносни проблеми, BARB ќе го извести BSTS за повторноview и координација со Експертската група за безбедност; и ако BARB идентификува какви било регулаторни импликации, BARB ќе го извести BSTS да се вратиview и да се координира со Регулаторниот комитет и правниот советник на Bluetooth SIG. BARB мора или да ја одобри или отфрли спецификацијата 0.9/CR врз основа на неговата инженерска проценка и разгледување на факторите опишани во овој став.

ОТИ ќе реview 0.9/CR тест документи земајќи ја предвид анализата на покриеноста на тестот. ОТИ мора или да ги одобри или да ги отфрли документите за тестирање 0.9/CR.

Откако BARB ќе ја одобри спецификацијата 0.9/CR, WG го доставува планот за IOP тест до BARB за повторноview.

Спецификацијата 0.9/CR одобрена од BARB се презентира на Одборот за одбор за да го одобри почетокот на IOP тестирањето и објавувањето на спецификацијата 0.9/CR на сите членови.

За да се истакнат потенцијалните правни проблеми, РГ може да побараат спецификацијаview од правниот советник на Bluetooth SIG (правна реview) пред задолжителната правна реview се одвива во фазата на усвојување/одобрување. Меѓутоа, за подобрување на спецификациите, правната реview треба да се направи на интегриран CR (за разлика од скратен CR) и тоа треба да се планира што е можно понапред за да се достапни ресурсите.

План за IOP тест

РГ ќе развие писмен план за тестирање на ИОП кој мора да ги задоволува сите барања дефинирани подолу за употреба во фазата на валидација на настаните за тестирање на ИОП. РГ мора да го достават планот за тестирање на ИОП до BARB за повторноview пред да започнат настаните од тестот за ИОП. За едноставни подобрувања на спецификациите (особено оние за кои не е потребно менување или додавање случаи на тест во тест пакетот), можеби нема да биде потребно тестирање на IOP, а WG може да поднесе барање до BARB за откажување од IOP тестирањето со користење на дефинираниот процес во Дел 4.4.

Планот за IOP тест мора да вклучува:

Тест случаи за да ги потврдите сите нови задолжителни, опционални и условни карактеристики
Најмалку еден тест случај за секој оп. код
Најмалку еден тест случај за секој параметар
Најмалку еден тест случај за секој тип на пакет
Случаи за тестирање за компатибилност наназад за подобрувања на спецификациите, така што барањата наведени во Дел 3.3.2 се исполнети за целата подобрена функционалност (исто така, видете во Дел 4.3.1.1).
Тест случаи каде што IUT е изложен на вредности надвор од дефинираните опсези или на аспекти на однесување кои се сметаат за невалидни или неочекувани (случаи за тест за неважечко однесување). Имајте предвид дека се очекува тестерот како што е PTS или друга алатка за тестирање да биде иницијатор за какво било неважечко однесување.
Сите привремени доделени броеви (избрани во координација со BSTS за да се избегне преклопување на претстојните ИОП тест настани) што ќе се користат на настанот за тестирање на ИОП, како што е опишано во Дел 4.3.1.2.
Идентификација на потребниот број на независни имплементации кои мора да го поминат секој тест случај, земајќи ги предвид барањата за покриеност опишани во Дел 4.3.1.3
Идентификување на какви било тест случаи во тест пакетот за кои WG смета дека треба да бидат исклучени и оправдување за нивното исклучување. Тие обично вклучуваат: • Случаи за тестирање за идна проверка (на пр. вообичаени тестови за да може да се приспособат можните идни дополнувања, како што се дополнителни карактеристики, проширувачки карактеристики или употреба на битови или полиња резервирани за идна употреба (RFU))
• Тест случаи кои се подмножество на други вклучени тестови
• Генерични тест случаи кои се практично идентични со тестовите што работат за неколку други спецификации (на пр. активирање на вообичаени кодови за грешка)
• Случаи за тестирање со иста цел за тестирање како тест-случаи што прегазуваат друг транспорт (на пр. BR/EDR тест случај што е сличен на LE тест случај)
• Робустност или стрес-тестирање на имплементацијата

Планот за тестирање на ИОП, исто така, може да вклучува тестови кои се единствени за тестирањето на ИОП, како што се тест случаи од крај до крај што поврзуваат посложени секвенци што може да личат на типично корисничко сценарио.

Иако не е потребно одобрување BARB на планот за IOP тест (со разбирање дека планот за IOP тест ќе продолжи да се менува и подобрува со секој IOP тест настан), потребно е BARB одобрување на извештајот за IOP тест (види Дел 5.1.1). . Ако планот за тестирање на ИОП не ги задоволува сите барања дефинирани во Дел 4.3.1, WG треба да претстави резиме на сите познати варијанси и образложението за секоја варијанса до BARB пред да започне настанот(ите) на IOP тест.

Планот за тестирање на ИОП и случаите за тестирање треба првенствено да се засноваат на содржината во документите за тестирање на придружната спецификација.

За да ги направи настаните од тестот за ИОП ефикасни, РГ треба да го има планот за тестирање на ИОП и сите поврзани случаи на тестови завршени и достапни за имплементаторите идеално најмалку еден месец пред првиот настан за тестирање на ИОП.

Планирање за тестирање на компатибилност наназад
За подобрување на спецификациите, IOP тестирањето за компатибилност наназад мора да размисли за верификација со сите активни и застарени верзии на спецификацијата бидејќи тие спецификации и функционалности што вообичаено се наоѓаат во производите со Bluetooth може да имаат многу долг животен век (на пр. возила). РГ мора да го анализира соодветното ниво на потребното тестирање за компатибилност наназад (доколку има), вклучувајќи кои верзии да се тестираат и тестови да се изведат, и да ја достави оваа анализа на BARB. BARB мора повторноview анализата и препорачате промени (доколку има) за WG да ги вклучи во планот за IOP тест.

Членовите кои учествуваат во тестирањето за компатибилност наназад се охрабруваат да донесат наследни уреди кои биле квалификувани според претходните верзии на спецификацијата. WG мора да пријави какви било неуспеси за компатибилност наназад во извештајот за IOP тест. Компаниите-членки, исто така, се охрабруваат да вршат тестирање за компатибилност наназад во нивните лаборатории надвор од локацијата на настанот за тестирање IOP и да пријават какви било проблеми поврзани со спецификациите до WG.

Привремени доделени броеви кои се користат при тестирање на ИОП
BSTS и BARB мора да се консултираат за да се координира привременото доделување на доделените броеви што ќе се користат на настанот за тестирање IOP за да нема преклопувања или судири со други спецификации. Овие привремени вредности мора да бидат вклучени во планот за тестирање на ИОП и нема да бидат доделени за употреба според усвоените спецификации.

За IOP тестирање каде што се предлагаат една или повеќе нови 16-битни UUID вредности, вредностите во опсегот од 0x7F00 до 0x7FFF се резервирани за IOP тестирање.

За IOP тестирање каде што се предлагаат една или повеќе нови вредности на сервисен мултиплексер на фиксен протокол (PSM), ќе се користат вредности кои почнуваат од крајот на важечкиот опсег од 0x0000 до 0x007F, како што е наведено во Основната спецификација.

Барања за покриеност
WG мора да обезбеди доказ за BARB дека потребниот број (како што е опишано во деловите што следат) на независни имплементации го поминале секој тест случај. Секое барање на WG за исклучоци од потребниот број на независни имплементации мора да биде наведено во планот за тестирање IOP што се доставува до BARB.

Имплементациите се сметаат за независни едни од други се додека сите делови што се релевантни за валидацијата се развиени независно, т.е. од различни тимови (кои не мора да потекнуваат од различни компании). BSTS може да помогне во проценката дали прототиповите може да се сметаат за независни еден од друг со цел да се зачува анонимноста и доверливоста на деталите за имплементацијата.

Имајте предвид дека алатките за тестирање, вклучително и PTS, не се сметаат за независни имплементации.

Основна спецификација Барања за покривање на ИОП
Функцијата Основна спецификација обично дефинира една или повеќе улоги каде што секоја улога е дизајнирана да соработува со една или повеќе други улоги или евентуално со самата себе.

За секој пар на улоги што се дизајнирани да соработуваат една со друга, мора да се покажат најмалку три независни имплементации на секоја улога за да соработуваат со три независни имплементации на комплементарната улога.

За секоја улога што може да комуницира со друг уред во истата улога, најмалку три независни имплементации на таа улога мора да покажат дека можат да комуницираат една со друга во таа улога.

Спецификација на услугата Барања за покривање на ИОП
Најмалку три имплементации на независни услуги мора да покажат дека тие соработуваат со најмалку една имплементација на клиентот, која може да биде PTS.

Проfile и спецификации за протокол Барања за покривање на ИОП
Проfile и спецификациите на протоколот обично дефинираат една или повеќе улоги каде што секоја улога е дизајнирана да соработува со една или повеќе други улоги, или можеби со самата себе.

За секој пар на улоги што се дизајнирани да соработуваат една со друга, најмалку две независни имплементации на секоја улога мора да покажат дека тие меѓусебно функционираат со две независни имплементации на комплементарната улога.

За секоја улога што може да комуницира со друг уред во иста улога, најмалку три независни имплементации на таа улога мора да покажат дека тие комуницираат една со друга во таа улога.

Спецификација на моделот Барања за покривање на ИОП
Најмалку три имплементации на независен серверски модел или контролен модел мора да покажат дека интероперационираат со најмалку една имплементација на клиент (која може да биде PTS), а најмалку една имплементација на модел на клиент мора да покаже дека интероперационира со најмалку една имплементација на модел на сервер и PTS.

Нумерирање на верзијата на спецификациите

Во текот на 0.9/CR Сtagд, РГ мора да подготви препорака што ќе му ја достави на Одборот за одбор во врска со бројот на верзијата што треба да се примени на спецификацијата кога ќе биде усвоена.

Верзиите на спецификациите спаѓаат во два вида: верзии со целосно издание, кои вклучуваат нови или ажурирани функции, и верзии за издавање на одржување (исто така познати како „верзии со точка-Z“), кои интегрираат технички и уредувачки грешки, но не вклучуваат нови или ажурирани карактеристики. Верзиите со целосно издание имаат дводелни броеви во форма на XY, како што се 2.1 или 5.0, додека верзиите за одржување имаат триделни броеви во форма на XYZ, како што е 2.1.2. Вредноста на Z не може да биде 0.

За било кои две верзии, едната се нарекува „повисока верзија“, а другата е „пониска верзија“. Ова се одредува според следниве правила:

Доколку X компонентите се разликуваат, онаа со повисока X вредност е „повисоката верзија“.
Ако X компонентите се исти, но Y компонентите се разликуваат, онаа со повисока Y вредност е „повисоката верзија“.
Ако XY компонентите се исти, но Z компонентите се разликуваат, онаа со поголема Z вредност е „повисоката верзија“. Дводелниот број XY за оваа цел се третира како триделен број XY0.

За прampле, следните броеви на верзии би биле по редослед од најниска до највисока верзија: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. За CSS, секое ажурирање ја зголемува само X компонентата од бројот на верзијата.

Предуслови за одобрување од ОО
На крајот од фазата на развој на спецификации, мора да се исполнат следните барања пред да се поднесе спецификација 0.9/CR до Одборот за одобрување:

РГ ја заврши анализата на покриеноста на тестот.
BSTS го заврши повторнотоviewсо 0.9/CR спецификација и документи за тестирање.
BARB ја одобри спецификацијата 0.9/CR.
BARB го одобри CSS CR (ако се бараат нови записи според спецификацијата) кој може да биде вграден во Скратен CR на спецификацијата.
BARB ги одобри GSS CR и MDP CR (ако се бараат нови записи според спецификацијата).
BTI го одобри 0.9/CR тест пакетот, ICS и TCRL, заедно со IXIT (под услов IXIT да е потребен за извршување на тестовите во тест пакетот). TCRL е опционален во оваа stagд за ажурирања на Основната спецификација.
РГ го достави планот за тестирање IOP до BARB за повторноview (ако BARB не го отфрли тестирањето).

Документите доставени до Одборот мора да ја содржат спецификацијата 0.9/CR одобрена од BARB и презентација до ОД која мора да содржи:

Секое познато барање за откажување од IOP тестирање или кое било од барањата дефинирани во Дел 4.3.1
Список на транспорти што ги поддржува спецификацијата (на пр., BR/EDR, LE. итн.)
За подобрување на спецификациите, сите исклучоци од барањата за компатибилност наназад (опишани во Дел 3.3.2) што ги бара WG
За подобрување на спецификацијата, препорака од WG за бројот на верзијата да се примени на усвоената спецификација
За подобрување на спецификациите, препораката на WG за крајот на животниот век за претходната(и) верзија(и) на усвоената спецификација, вклучувајќи ги сите технички причини зошто отфрлањето или повлекувањето на која било претходна верзија на спецификацијата е или не се препорачува, и оправдувањето за препораката
Секоја нерешена сериозна загриженост од членовите на BARB или ОТИ (на пр. причини за какви било гласови „Не“ при одобрувањата, загрижености кои произлегуваат од реview на документи за тестирање или загриженост дека спецификацијата 0.9/CR е надвор од опсегот на FRD или повелбата)
Статусот на подготовка на Проfile Tuning Suite (PTS) или други потребни алатки поврзани со посвојувањето кои се подготвени од BSTS

Одборот може да избере да ја одобри спецификацијата 0.9/CR за IOP тестирање како што се бара со подзаконските акти [2], пред ОТИ да ги одобри документите за тестирање 0.9/CR и пред WG да потврди дека планот за тестирање IOP ги исполнува барањата дефинирани во Дел 4.3.1. 0.9. Одборот може, исто така, да го условува одобрувањето на спецификацијата 0.9/CR за IOP тестирање со одобрување од ОТИ на документите за тестирање XNUMX/CR.

0.9/CR Сtagбарања за излез
0.9/CR Stage е завршена и фазата на валидација започнува кога одборот на управата ќе го одобри почетокот на IOP тестирањето.

4.4 Откажувања од процесот на развој на спецификации

WG може да побара да се откаже од еден или повеќе од следниве чекори на процесот:

0.5/DIPD Stage
0.7/FIPD Stage
IOP тестирање во рамките на фазата на валидација

За да побара откажување, WG мора да го користи образецот за откажување од процес обезбеден од Bluetooth SIG [8] и да поднесе барање за откажување до секој комитет (т.е., BARB или BTI) кој е потребен за повторноview или да ги одобри нацрт-спецификациите или придружните документи за тестирање на сtagд дека РГ предлага да се откаже, и секој од тие комитети мора да го одобри барањето за откажување.

Барањето за откажување мора да го содржи следново:

Идентификација на сtagе(и) од кои WG сака да се откаже
Оправдување зошто сtage(s) треба да се откаже
Идентификација на секој комитет (т.е. ОТИ и/или BARB) што се бара повторноview и го одобри барањето за откажување

Комитетот што го разгледува откажувањето може да бара претставник на РГ да направи презентација за да го оправда откажувањето од процесот SMPD пред да одлучи за барањето за откажување.

Ако откажувањето бара откажување од повеќе чекори и дел од откажувањето е одбиено, а дел е одобрено, одговорот на комисијата мора да означи кои чекори во барањето за откажување биле одобрени, а кои биле одбиени. Ако барањето за откажување е одбиено, известувањето за одбивање мора да ги содржи причините за одбивањето.

5. Фаза на валидација

За време на фазата на валидација, WG ќе изврши IOP тестирање на спецификацијата 0.9/CR со цел да се достави извештај за IOP тест за BARB реview и одобрување. Секогаш кога е можно, IOP тестирањето на подобрувањата на спецификациите треба да се спроведе според интегрираната нацрт спецификација. Покрај тоа, членот Реview, како што се бара со подзаконските акти [2], започнува во оваа фаза.

Ако спецификацијата (или подобрувањето) не бара IOP тестирање, тогаш IOP тестирањето во рамките на фазата на валидација може да се откаже со користење на процесот опишан во Дел 4.4.

Во текот на тестирањето на IOP (што може да биде еден или повеќе настани), WG треба да ги следи проблемите користејќи го системот за следење проблеми на Bluetooth SIG и да повторува за да вклучи ажурирања на нацрт-спецификациите, документите за тестирање и планот за тестирање IOP. Откако ќе заврши тестирањето на ИОП, РГ мора да ги заврши ажурирањата на нацрт-спецификациите и документите за тестирање за да се решат сите проблеми и да подготви и достави извештај од тестот за ИОП до BARB за повторноview и одобрување. Ова е илустрирано на Слика 5.1.

За време на фазата на валидација, може да започнат неколку активности. Овие активности може да се случуваат паралелно и го вклучуваат следново:

Спецификацијата 0.9/CR одобрена од ОД е достапна за сите членови од БСТС со известување за почетокот на членот Реview период кој се бара со подзаконските акти.
Сите потребни ажурирања се вградени во CSS (кој може да биде вграден во Скратен CR на спецификацијата).
Карактеристичните или дескрипторските дефиниции се вградени во спецификацијата за GSS, како и во PTS за IOP тестирање.
Дефинициите на својствата на мрежата се вградени во спецификацијата MDP, како и во PTS за IOP тестирање.
BSTS овозможува регистрација на платформата IOP и алатка за внесување резултати во подготовка за IOP тестирање.
ИОП тестирање, доколку е потребно (види Дел 5.1).
Review коментарите и прашањата, вклучително и оние поднесени како резултат на тестирањето на ИОП, се обработуваат и промените се вградени во нацрт-спецификацијата.

5.1 IOP тестирање

Примарната цел на IOP тестирањето е да се потврди спецификацијата со, на прampле, проверка на точноста и нејаснотијата во текстот, реviewбарајќи какви било фундаментални грешки и пропусти во дизајнот и обезбедува валидација според претходно утврдените барања развиени порано во процесот на развој на спецификацијата. Тестирањето на ИОП може да резултира со промени во нацрт-спецификациите и може да бидат потребни повеќе настани од тестот за ИОП за да се завршат сите потребни тестови.

Важно е да им се даде можност на членовите надвор од РГ да учествуваат во тестирањето на ИОП бидејќи тие обезбедуваат независен view на спецификацијата и може да открие области на нејаснотии во спецификацијата кои можеби не се очигледни за членовите на РГ кои го развија нацртот. Пред секој IOP тест настан, BSTS ќе ги стави на располагање деталите за настанот, најновата нацрт спецификација, тест пакетот и планот за тестирање IOP и ќе ги извести сите членови идеално еден месец пред секој настан. Ажурираните нацрт-спецификации, тест пакет и план за тестирање IOP што се користат на настан за тестирање на ИОП треба да бидат достапни најмалку една недела пред секој настан.

За време на тестирањето на ИОП, парните комбинации на платформи ќе се обидат да ги извршат тестовите, а учесниците во тестирањето на ИОП ќе ги снимаат резултатите од секој тест и коментари. Анонимизирано резиме на овие резултати (на пр., „Платформа А“, „Платформа Б“ итн.) и сите коментари, ќе бидат собрани за време на настаните од тестот за ИОП и ќе им бидат достапни на членовите на РГ за време и по ИОП тест настан. Во случај да се потребни дополнителни информации за да се добие подобро разбирање за какви било коментари или неуспеси што се случиле за време на IOP тестирањето, BSTS може да дејствува како посредник за собирање дополнителни информации од членот што поднесува.

Ако е можно, PTS треба да се ажурира за да поддржува IOP тестирање со платформи на сите слоеви над интерфејсот на контролорот на домаќинот (HCI) и да биде присутен на IOP тест настани за тие слоеви. Други алатки за тестирање може да бидат присутни и на настаните за тестирање на ИОП. Резиме на резултатите од тестирањето со PTS или други алатки за тестирање (доколку ги има) треба да биде вклучено во извештајот за IOP тест.

Тестирањето на IOP ќе биде отворено за сите членови кои сакаат да обезбедат имплементација на прототип, меѓутоа, Bluetooth SIG може да го условува учеството со прифаќање договори со Bluetooth SIG (вклучувајќи договори за учество и доверливост). РГ е одговорен за обработка и решавање на проблемите откриени за време на IOP тестирањето и ажурирање на засегнатите документи; Промените одобрени од WG мора да се вградат како ажурирања на нацрт-спецификациите и документите за тестирање за употреба на секој IOP тест настан.

Пред фазата на валидација, WGs може да вршат прелиминарно IOP тестирање на настани што се отворени само за членовите на WG, но резултатите од неформалното тестирање може да не бидат вклучени во резултатите од IOP тестот.

Може да се случи да се следат сите чекори што водат до првиот настан за тестирање на ИОП, вклучително и најавен датум и локација за ИОП со намера да се започне со тестирањето на ИОП, но одобрението од ОО не беше обезбедено пред почетокот на тест-настанот. Во овој случај, ОД може да одобри вклучување на резултатите од тестовите кои биле собрани пред одобрението од ОД за започнување со тестирање на ИОП, под услов собраните резултати да се засноваат на истата спецификација и тест пакетот одобрен од ОД.

IOP тестирањето не е потребно за подобрувања на спецификациите на CSS, GSS или MDP.

Извештај за IOP тест
По завршувањето на IOP тестирањето, WG мора да го достави извештајот за IOP тест до BARB со цел да покаже дека потребниот број на независни платформи ги поминале бараните тестови. BARB мора повторноview и го одобри или отфрли извештајот од тестот за ИОП и ќе ја извести РГ доколку е потребно дополнително тестирање на ИОП пред да го достави пакетот спецификации на Предлогот за гласање до Одборот. BSTS и WG мора да се погрижат да не се појавуваат информации за идентификување на членовите во извештајот од IOP тестот пред да го поднесат извештајот до BARB.

Извештајот за IOP тест мора да содржи:

Список на сите ИОП тест настани што се случиле за време на фазата на валидација вклучувајќи ги нивните датуми и локации.
Бројот на компании-членки и независни платформи кои учествуваа на секој настан на ИОП, вклучително и дали е користен ПТС.
Список на спецификација, тест пакет и верзии на план за тестирање IOP што се користат на секој настан.
Извршно резиме во кое се наведува дали сите тест-случаи ги исполнуваат критериумите за минимално поминување или не.
Резиме на сите варијанси од барањата на планот за тестирање IOP дефинирани во Дел 4.3.1 и образложението за секоја варијанса.
Резиме на покриеност на PTS за тест случаи во тест пакетот.
Список на сите тест-случаи (вклучувајќи тестови за компатибилност наназад) од планот за тестирање IOP, бројот на поминати тестови, бројот на неуспеси на тестот и дали минималните критериуми се исполнети по тест случај, вклучувајќи објаснување зошто некои барања не биле се сретнале.
Резиме на прашања, коментари и прашања на секој настан (вклучувајќи ги и тие fileг против спецификацијата за време на IOP тестирањето) и влијанието врз спецификацијата и документите за тестирање.

5.2 Барања за излез од фазата на валидација

Фазата на валидација е завршена и фазата на одобрување/усвојување започнува кога BARB ќе го одобри извештајот за IOP тест (освен ако BARB не го отфрли тестирањето) и ќе бидат исполнети сите следниве барања:

BSTS ја направи одобрената спецификација 0.9/CR достапна за сите членови за член Review како што се бара со подзаконските акти и ги извести сите членови за неговата достапност.
Сите проблеми кои беа идентификувани за време на IOP тестирањето и кои имаат влијание на тестот, се вградени и тестирани.
WG има завршено IOP тестирање (освен ако тестирањето не беше откажано од BARB).

6. Фаза на усвојување/одобрување

За време на фазата на усвојување/одобрување, спецификациите и поврзаните документи за тестирање се финализираат, се добива одобрение за BARB, BQRB и ОТИ, се издава известување за предложениот Датум на усвојување заедно со конечната верзија на нацрт-спецификацијата поднесена до Одборот за усвојување ( Гласање Нацрт), а конечниот пакет на спецификација се доставува до ОД. По минималното времетраење на Член Реview се бара со подзаконските акти [2]) е исполнето, УО ќе ја разгледа спецификацијата за усвојување на датумот на усвојување. По усвојувањето, спецификацијата се објавува и системот за квалификација е овозможен. Фазата на усвојување/одобрување е илустрирана на Слика 6.1.

6.1 Гласање Нацрт

Нацртот за гласање се креира со инкорпорирање на ажурирања (обезбедени во фазата на валидација) во потребните спецификациски документи и подготовка на конечен нацрт на новата спецификација. За подобрување на спецификациите, BSTS ќе ја креира интегрираната спецификација со интегрирање на еден или повеќе CR(и) во претходно усвоената повисока верзија на спецификацијата (види Дел 4.3.2) доколку не е веќе завршена пред Фазата на валидација.

Доколку се направат промени во спецификацијата во текот на оваа фаза и WG, BARB или BTI утврдат дека за секоја промена е потребно дополнително тестирање на IOP, спецификацијата ќе се врати во делот за тестирање на IOP во фазата на валидација за WG да ги изврши дополнителните тестови. За време на фазата на усвојување/одобрување, следните документи ќе бидат комплетирани и ставени на располагање на ОО пред датумот на усвојување:

Нацртот за гласање
Сите придружни спецификации (т.е. CSS, GSS, MDP) како што се бара за релевантната спецификација (или подобрување) тип, доколку претходно не е усвоена
За подобрувања на спецификациите, верзија следена со промени на усвоената верзија на спецификација која ги прикажува промените предложени во нацртот за гласање
Опис од WG за какви било барања за компатибилност наназад (како што е опишано во Дел 3.3.2) кои не се исполнети и оправдување за какви било исклучоци
Опис од WG за какви било барања за план за тестирање IOP (како што е опишано во Дел 4.3.1) кои не се исполнети и оправдување за какви било отстапувања заедно со извештајот од IOP тестот (кој може да се обезбеди со обезбедување врска до копија на Bluetooth SIG webсајт)
Препорака од WG за укинување или повлекување на која било претходна верзија(и) на усвоената спецификација заедно со оправдување, нагласувајќи ги промените од 0.9/CR Stagд препорака за крај на животниот век
Резиме, подготвено од WG, на промени во карактеристиките или функционалноста од спецификацијата 0.9/CR (доколку има)
Резиме, подготвено од BARB, за загриженоста покрената од членовите на BARB дека спецификацијата што ја изготвува РГ е надвор од опсегот на повелбата одобрена од Одборот на Одборот (доколку има)
Список на преостанати нерешени правни прашања од правна реview (ако има)
Тест пакетот одобрен од ОТИ, заедно со резимето за покриеноста на тестот на спецификацијата на нацрт-гласањето одобрено од WG. Во случај на новододадена или изменета функционалност без покривање на тестот, потребно е писмено оправдување за пропустот
ICS и IXIT одобрени од ОТИ (ако се бара со спецификацијата)
TCRL одобрени и од ОТИ и од BQRB
Извештај подготвен од BSTS заедно со ОТИ во врска со статусот на подготвеност на алатот (на пр., PTS и други алатки за тестирање, Студио за лансирање Bluetooth) вклучително и ако некои случаи за тестирање во TCRL не се поддржани од алатките за тестирање
Резиме, подготвено од РГ, на сите потребни доделени броеви
Список за проверка на посвојување подготвен од BSTS и WG што покажува дека сите резултати во овој дел се сите завршени
Сите останати информации кои ги бара ОД

За време на фазата на усвојување/одобрување, РГ треба да го користи системот за следење проблеми на Bluetooth SIG за да ги опфати прашањата и коментарите во однос на нацрт-спецификациите и документите за тестирање, така што тие ќе бидат земени предвид при финализирањето на спецификацијата за нацрт-гласањето. За подобрување на спецификациите, сите релевантни одобрени грешки (т.е. оние одобрени грешки кои сè уште не се интегрирани) мора да бидат вградени и мора да се идентификуваат користејќи следени промени.

РГ мора да ја достави конечната нацрт-спецификација до BSTS за правен одговорview. За нови спецификации, правната реview ќе ја вклучи целата спецификација. За подобрување на спецификациите, реview ќе се фокусира првенствено на изменетите делови од спецификацијата. Целта на правната реview е првенствено да ги идентификува правните ризици кои РГ треба да ги разгледа и да бара да ги реши. Правните повратни информации ќе бидат категоризирани врз основа на сериозноста. Доколку факултативна правна реview е извршена на 0.9/CR Сtagд, верзијата што се доставува за правна реview мора да ги прикаже, како следени промени, сите промени што се направени од таа верзија (генерирани или од WG или BSTS). По завршување на правната реview, WG и BSTS ќе се договорат за повратните информации што треба да се вклучат во нацрт-спецификацијата. Доколку има нерешени правни забелешки од правна реview на нацрт-спецификациите, претседавачот на РГ може да побара време на дневниот ред на Одборот за да се договори за резолуцијата.

Паралелно со правната реview, РГ мора да ја достави нацрт-спецификацијата до BARB за повторноview. По првичното поднесување до BARB, BSTS ќе ги извести сите членови дека нацрт-спецификацијата е доставена до BARB за повторноview и дека е достапен и за Член Реview. Доколку РГ поднесе ажурирања на нацрт-спецификациите за BARB повторноview, BSTS ќе испраќа дополнителни известувања до сите членови на периодична основа.

По завршувањето на BARB реview, WG и BARB ќе се договорат за повратните информации што треба да се вклучат во нацрт-спецификацијата.

Доколку законската реview резултира со какви било суштински промени, дополнителни реview од страна на BARB може да се бара. Слично на тоа, ако BARB повторноview резултира со какви било суштински промени, БСТС ќе утврди дали дополнителна правна реview од тие промени се бара. По завршување на правната реview и BARB реview, BARB мора или да го одобри или отфрли Предлогот за гласање.

Ако некој тест документ бара ажурирање, BSTS ќе му помогне на WG во ажурирањето на документите за тестирање. ОТИ мора или да ги одобри или да ги одбие документите за тестирање. Доколку биде одобрен од ОТИ, ОТИ ќе помогне во финализирањето на TCRL и ќе го достави овој документ до BQRB заедно со поврзаните ICS, IXIT и тест пакетот. BSTS ќе го процени датумот на состанокот на Одборот кога одборот има намера да гласа за усвојување на нацртот за гласање (Датум на усвојување) и ќе го обезбеди ОТИ за употреба во TCRL. Одобрувањето од BARB на спецификацијата, ОТИ одобрувањето на сите документи за тестирање (вклучувајќи го тест пакетот, TCRL, ICS и IXIT) и одобрувањето BQRB на TCRL мора да се случи на или пред датумот на усвојување.

BSTS ќе ги информира сите членови за финализирањето и достапноста на нацртот за гласање и датумот на усвојување. Датумот на усвојување ќе биде одреден не порано од 60 дена откако членовите биле известени за спецификацијата 0.9/CR одобрена од ОД, освен ако членот Реview рокот го скратува УО во согласност со подзаконските акти, а најмалку 14 дена по известувањето за датумот на усвојување им го обезбедува на членовите во согласност со Статутот. За случаи каде што повеќе CR се интегрирани во нацрт за гласање, почетокот на Член Реview е датумот на кој членовите биле известени за најновиот CR одобрен од ОО.

По известувањето за датумот на усвојување на членовите, дозволени се корекции на типографски грешки во Нацртот за гласање одобрени од ОО. Временската рамка за усвојување на спецификацијата е илустрирана на Слика 6.2.

6.2 Доделени броеви

Bluetooth SIG одржува јавно достапен сет на доделени броеви на доделените броеви на Bluetooth SIG webсајт [7]. Овие доделени броеви се групирани во различни места за броеви (поврзан сет на броеви без дупликати). Доделените броеви може да се преклопуваат со други доделени броеви во различни нумерички простори, но ниту еден број во броен простор не е дозволено повторно да се користи. Различните простори за броеви се дефинирани во спецификацијата што ја дефинира употребата на доделените броеви.

Откако BARB ќе го одобри извештајот за IOP тест, WG ќе поднесе барање до BARB за доделување нови броеви во рамките на просторот за броеви што се бара со конечната спецификација. BARB ќе реview барањето и работа со БСТС за одредување на доделените броеви. По одобрувањето на BARB, BSTS ќе закаже објавување на доделените броеви да бидат јавно достапни на доделените броеви на Bluetooth SIG webсајт [7] во рок од една недела од усвојувањето на спецификацијата.

По објавувањето на доделените броеви на доделените броеви на Bluetooth SIG webлокација или во рамките на усвоена спецификација се случува, доделените броеви се наменети да бидат непроменливи (да не се менуваат ниту во вредност ниту во значење). Ако поради некоја причина станат неупотребливи, тие стануваат резервирани вредности и не им е дозволено повторно да се користат.

6.3 Барања за излез од фазата на усвојување/одобрување

Фазата на одобрување/усвојување е завршена кога ОД ќе ја усвои спецификацијата и ќе се завршат следните активности по усвојувањето:

BSTS ги направи јавно достапни конечните доделени броеви на Bluetooth SIG webсајт.
BSTS ја направи усвоената спецификација јавно достапна на Bluetooth SIG webсајт
BSTS ги направи сите придружни документи (на пример, CSS, GSS, MDP) потребни за релевантната спецификација јавно достапни на Bluetooth SIG webсајт.
BSTS ги направи придружните тест документи достапни за сите членови на Bluetooth SIG webсајт.
За подобрување на спецификациите, BSTS направи информативна верзија следена со промени на претходно усвоената верзија на спецификација со сите промени направени од новоусвоената верзија и ја направи достапна за сите членови на Bluetooth SIG webсајт.
BSTS го овозможи системот за квалификации.
BSTS ги извести сите членки за достапноста на усвоената спецификација и сите придружни документи.

Bluetooth SIG планира да ги заврши овие активности по усвојувањето во рок од една недела по усвојувањето на спецификацијата.

7. Спецификација Фаза на одржување

Фазата на одржување на спецификацијата започнува откако ќе заврши фазата на усвојување/одобрување. Ако се најдат проблеми (на пр., нејаснотии во формулацијата или технички грешки) со спецификацијата или поврзаните документи за тестирање, тие мора да се документираат со креирање предлози за погрешни грешки со помош на алатката Bluetooth SIG Errata. Предлозите за погрешни спецификации ќе бидат обработени, категоризирани и одобрени според EPD [3]. Грешките на тест пакетот се обработуваат и категоризираат според TSTO [5]. Ако има некакви конфликти помеѓу SMPD и EPD или TSTO, SMPD има приоритет.

Грешката во спецификацијата мора да се користи само за да се поправат техничките или уредувачките грешки во конечните усвоени спецификации за Bluetooth. Додавањето, промените и отстранувањето на функционалноста може да се направи само со процесот на подобрување на спецификациите дефиниран претходно во овој документ.

7.1 Забрзан погрешен процес

Кога грешката е одобрена по процесот дефиниран во EPD [3], WG, BARB или BSTS може да препорача да се смета за итен и треба да се забрза. Кога тоа ќе се случи, BSTS заедно со WG или BARB ќе ја презентираат препораката до ОД. Одборот ќе одлучи дали ќе ја прифати или отфрли препораката. Ако препораката биде прифатена, BSTS веднаш ќе го вгради одобрениот erratum во шаблонот за erratum [8] и ќе работи со одговорниот WG за финализирање на забрзана корекција на погрешни грешки што ќе се достави до WG за повторноview и одобрување.

Надview на забрзаниот erratum процес е илустриран на слика 7.1.

Следниве документи мора да бидат пополнети и ставени на располагање на Одборот пред датумот на усвојување:

Нацрт забрзана корекција на грешки, одобрен од BARB.
Опис од WG за какви било барања за компатибилност наназад (како што е опишано во Дел 3.3.2) кои не се исполнети и оправдување за какви било исклучоци.
Список на преостанати нерешени правни прашања од правна реview (ако има).
Тест пакет, ICS и IXIT одобрени од ОТИ (ако тоа го бара погрешното).
TCRL одобрени од BTI и BQRB (ако тоа го бара погрешното).
Извештај пополнет од BSTS заедно со ОТИ во врска со статусот на подготвеност на алатот (на пр., PTS и други алатки за тестирање, Студио за лансирање на Bluetooth), вклучително и ако некои случаи за тестирање во TCRL не се поддржани од алатките за тестирање и објаснување (ако тоа го бара грешката ).
Список за проверка за усвојување пополнет од BSTS и WG, кој покажува дека испораките во овој дел се сите завршени.
Сите останати информации кои ги бара ОД.

BSTS ќе работи со одговорниот WG за да го финализира нацртот на забрзана корекција на грешки и да создаде верзија што ќе ја достави до одговорната РГ за повторноview и одобрување.

РГ мора да ја достави забрзаната корекција на грешки до BSTS за правен одговорview. По завршување на правната реview, WG и BSTS ќе се договорат за повратните информации што треба да се вклучат во забрзаната корекција на грешки. Доколку има нерешени правни забелешки од правна реview за забрзана корекција на грешки, претседавачот на РГ може да побара време на дневниот ред на Одборот за да побара придонес од Одборот за решавање.

Паралелно со правната реview, РГ мора да ја достави забрзаната корекција на грешки до BARB за повторноview. Откако забрзаната корекција на грешка ќе биде поднесена до BARB, BSTS ќе ја направи достапна за сите членови повторноview и да ги извести сите членови за неговата достапност. По завршувањето на BARB реview, WG и BARB ќе се договорат за повратните информации што треба да се вклучат во забрзаната корекција на грешки.

Доколку законската реview резултира со какви било суштински промени, дополнителни реview од страна на BARB може да се бара. Слично на тоа, ако BARB повторноview резултира со какви било суштински промени, БСТС ќе утврди дали дополнителна правна реview од тие промени се бара. По завршување на правната реview и BARB реview, BARB мора или да ја одобри или отфрли забрзаната корекција на грешки.

Ако некој тест документ бара ажурирање, BSTS ќе му помогне на WG во ажурирањето на документите за тестирање. По одобрувањето на тест документите за ОТИ, ОТИ ќе помогне во финализирањето на TCRL и ќе го достави документот до BQRB заедно со поврзаните ICS, IXIT и тест пакетот како што е применливо. BSTS ќе го процени Датумот на усвојување и ќе го достави до ОТИ за употреба во TCRL. Одобрување BARB на забрзана корекција на погрешни грешки, ОТИ одобрување на сите документи за тестирање (вклучувајќи го тест пакетот, TCRL, ICS и IXIT како што е применливо) и BQRB одобрувањето на TCRL мора да се случи на или пред датумот на усвојување.

BSTS ќе ги информира сите членови за финализирањето и достапноста на забрзаната корекција на грешки и предложениот датум на усвојување. Датумот на усвојување ќе биде одреден и известен за сите членови во согласност со подзаконските акти [2] и датумот на усвојување ќе биде најмалку 14 дена по известувањето до членовите. Откако ќе се достави известувањето за предложениот датум за усвојување на членовите, УО може да одобри корекции на печатни грешки во забрзаната корекција на погрешни грешки без дополнително известување за предложениот датум за усвојување и да ги чека потребните 14 дена.

Bluetooth SIG ќе ја направи усвоената забрзана корекција на грешки јавно достапна и планира да го стори тоа во рок од една недела по усвојувањето. Известување за неговата достапност ќе биде издадено од BSTS до сите членови.

Процесот на забрзана грешка е завршен кога ОД ќе ја усвои забрзаната корекција на грешки и ќе бидат завршени следните активности по усвојувањето:

BSTS ја направи усвоената забрзана корекција на грешки и придружните тест документи (доколку тоа е потребно со погрешно) јавно достапни на Bluetooth SIG webсајт.
BSTS го има овозможено системот за квалификација (ако тоа го бара погрешното).
BSTS ги извести сите членови за достапноста на усвоената забрзана корекција на грешки.

По завршувањето на овие активности, корекцијата на погрешно ќе биде закажана за интеграција во засегнатите спецификации или како дел од планираното подобрување на спецификациите или во претстојното издание за одржување како што е опишано во Дел 7.2.

7.2 Процес на ослободување на одржување (спецификации .Z)

На приближно годишна основа, BSTS ќе одредува дали има одобрени грешки (наведени како корекции на погрешни) кои се класифицирани како Технички/Високи или Технички/Критични и кои допрва треба да се вградат во текстот на која било активна спецификација (т.е. усвоена спецификација која не е застарена или повлечена). Видете Додаток А за погрешни дефиниции за класификација. Сопственикот на спецификациите (или WG овластен да ја одржува спецификацијата или BARB ако не е изнајмен WG за одржување на спецификацијата) може исто така да побара претходно објавување за одржување на активна спецификација во која ќе се вклучат какви било одобрени грешки. По утврдување на BSTS или барање на сопственикот на спецификацијата, ќе започне процесот на ослободување на одржување.

Надview на процесот на ослободување на одржување е илустриран во Error! Референтен извор не е пронајден.

На почетокот на процесот на ослободување за одржување, BSTS заедно со сопственикот на спецификацијата, BARB и BTI ќе развијат и ќе презентираат план до Одборот за одбор за инкорпорирање на корекции на погрешни промени во објавената верзија на спецификацијата. Предложениот план мора да означи дали корекциите на грешка ќе бидат вградени во изданието за одржување на спецификацијата (т.е. верзија .Z) или подобрување на спецификацијата што е веќе во тек (т.е. верзија на XY). Предложениот план треба да земе предвид дали се додадени нови задолжителни карактеристики помеѓу верзиите на усвоените спецификации, проценетото време кога се планира следното подобрување на спецификацијата за усвојување и други фактори.

По одобрувањето на планот од страна на Одборот, BSTS заедно со сопственикот на спецификацијата ќе продолжи да ги вградува сите технички/средни, технички/високи и технички/критични корекции во нацрт спецификацијата наречена „Нацрт за ослободување за одржување“. За уредувачки или технички/ниски корекции на погрешни грешки, ако исправката на погрешно се применува на повеќе од една верзија на спецификацијата, BSTS ќе ги интегрира тие грешки само во најновата верзија со повисоки спецификации на следното ажурирање на таа верзија, освен ако BOD не назначи поинаку. . Не смеат да се вклучат никакви промени во нацрт-изјавата за одржување освен инкорпорирање на погрешни корекции. Секој нацрт на изданието за одржување мора да ги идентификува сите вградени корекции на неправилности користејќи следење на промени за да ги прикаже предложените промени на претходно усвоената верзија на објавената спецификација.

Времето на предложеното вградување за секоја корекција на грешка во нацрт-изданието за одржување ќе зависи од влијанието на пакетот за тестирање: сите корекции на грешки кои немаат влијание на тест пакетот може да се вградат веднаш, но поправките на погрешни што влијаат на пакетот за тестирање ќе бидат обработени така што времето се совпаѓа со ажурирањето на TCRL.

ОТИ и BSTS ќе утврдат краен рок за вклучување на погрешни корекции со влијание на тест пакетот во нацрт-изјавата за одржување. Овој рок обично е 3 до 6 месеци пред планираниот датум на одобрување на следното големо издание на TCRL. Неправилните корекции со влијание на тест пакетот што го пропуштаат крајниот рок за вклучување ќе бидат обработени како дел од следното годишно издание на TCRL. Затоа, освен ако не е побарано претходно објавување, максималното време за Технички/Високи или Технички/Критични корекции на грешки што треба да бидат вклучени во ажурирањето на спецификациите е приближно 15 до 18 месеци.

Сопственикот на спецификацијата мора да го достави Нацртот за издавање за одржување што го одобрил како конечен за правна ревизијаview. Правната реview ќе се фокусира првенствено на изменетите делови од спецификацијата. По завршување на правната реview, Сопственикот на спецификацијата и BSTS ќе се договорат за повратните информации што треба да се вградат во Нацртот за издавање за одржување. Доколку има нерешени правни забелешки од правна реview на Нацртот за ослободување за одржување, сопственикот на спецификацијата може да побара време на дневниот ред на Одборот за да побара информации од ОО за решението.

Паралелно со правната реview, сопственикот на спецификацијата мора да го достави Нацртот за издавање за одржување до BARB за повторноview. Откако нацртот за издавање за одржување ќе биде доставен до BARB, BSTS ќе го направи достапен за сите членови повторноview и да ги извести сите членови за неговата достапност. По завршувањето на BARB реview, Сопственикот на спецификацијата и BARB ќе се договорат за повратните информации што треба да се вградат во нацрт спецификацијата.

За корекции на грешка кои влијаат на документите за тестирање и каде што соодветните грешки за тестирање ќе бидат обработени навреме за претстојното издание на TCRL, BSTS ќе работи со сопственикот на спецификацијата и ОТИ за ажурирање на документите за тестирање. По одобрувањето на ОТИ на тест документите, BSTS ќе го процени Датумот на усвојување и ќе го достави предложениот Датум на усвојување на ОТИ за употреба во TCRL. BTI ќе го достави TCRL на BQRB заедно со поврзаните ICS, IXIT и тест пакет, како што е применливо. Одобрувањето од BARB на спецификацијата, ОТИ одобрувањето на сите документи за тестирање (вклучувајќи го тест пакетот, TCRL, ICS и IXIT како што е применливо) и BQRB одобрувањето на TCRL мора да се случи на или пред датумот на усвојување.

BSTS ќе ги информира сите членови за финализирањето и достапноста на нацртот за гласање и предложениот датум за усвојување. Датумот на усвојување ќе биде одреден и известен до сите членови во согласност со подзаконските акти и датумот на усвојување ќе биде најмалку 14 дена по известувањето за известувањето до членовите. По известувањето за предложениот датум за усвојување на членовите, УО може да одобри корекции на печатни грешки во Нацртот за гласање без дополнително известување за предложениот датум за усвојување и да ги чека потребните 14 дена.

Следниве документи мора да бидат пополнети и ставени на располагање на Одборот пред датумот на усвојување:

Нацртот за гласање
Верзија на нацртот за гласање следена со промени што ги прикажува сите промени на усвоената верзија на спецификацијата што ја има истата вредност XY (на пр., ако нацртот за гласање е предложен како верзија 1.4.2, промените ќе се следат според 1.4.1 верзија на спецификацијата)
Препорака од сопственикот на спецификацијата за укинување или повлекување на која било претходна верзија(и) на усвоената спецификација заедно со оправдување
Список на преостанати нерешени правни прашања од правна реview (ако има)
Тест пакет, ICS и IXIT одобрени од ОТИ (ако се бара од изданието за одржување)
TCRL одобрени од BTI и BQRB (ако се бара од изданието за одржување)
Извештај пополнет од BSTS заедно со ОТИ во врска со статусот на подготвеност на алатот (на пр., PTS и други алатки за тестирање, Студио за лансирање Bluetooth) вклучувајќи ги сите тест случаи во TCRL што не се поддржани од алатките за тестирање и објаснување (ако тоа го бара одржувањето ослободување)
Список за проверка за посвојување, пополнет од BSTS и сопственикот на спецификација, што покажува дека испораките во овој дел се сите завршени
Сите останати информации кои ги бара ОД

Процесот на ослободување за одржување е завршен кога одборот ќе го усвои нацртот за гласање и ќе се завршат следните активности по усвојувањето:

BSTS ја направи усвоената спецификација и поврзаните документи за тестирање (ако се бара од изданието за одржување) јавно достапни на Bluetooth SIG webсајт.
BSTS направи информативна верзија следена со промени на претходно усвоената верзија на спецификација со сите промени вградени во новоусвоената верзија достапни за сите членови на Bluetooth SIG webсајт.
BSTS го овозможи системот за квалификации.
BSTS ги извести сите членови за достапноста на усвоената спецификација и придружните документи.

По завршувањето на овие активности, спецификацијата останува во фазата на одржување на спецификацијата сè додека спецификацијата не биде застарена или повлечена, како што е дефинирано во Дел 8.

8. Спецификација Фаза на крајот на животот

Спецификациите може да бидат застарени или повлечени кога ќе бидат заменети со понови верзии, кога ќе се утврди дека се технички недоволни или поради други причини. Застарените и повлечените спецификации се архивираат и повеќе не се ажурираат. Застарените и повлечените спецификации се третираат поинаку во Програмата за квалификација Bluetooth.

Секој член, група или комитет може да достави препораки за отфрлање или повлекување на спецификацијата заедно со поврзаната временска рамка до BSTS (преку е-пошта до

specification.manager@bluetooth.com) во секое време. BSTS исто така може да препорача укинување или повлекување на спецификацијата и поврзаната временска рамка. BSTS ќе ја упати препораката до BARB и групата или комитетот одговорен за одржување на спецификацијата за реview и повратни информации.

BARB и одговорната група или комитет ќе ги оценат препораките за отфрлање или повлекување на спецификацијата и ќе ги разгледаат следните (неисцрпни) критериуми:

Дали има функционалност во претходната верзија на спецификацијата што е застарена или не треба да се користи?
Дали е додадена нова задолжителна функционалност на подоцнежните верзии?
Дали има недостатоци во претходните верзии кои го нарушуваат работењето или интероперабилноста кои се коригирани во подоцнежните верзии и се потребни за унапредување на постоечките кориснички сценарија?
Дали е потребна дополнителна функционалност во подоцнежните верзии за да се унапредат нови кориснички сценарија?
Дали има подобрена употребливост и интероперабилност во подоцнежните верзии?
Дали има безбедносни подобрувања во подоцнежните верзии?

BARB и одговорната група или комитет може да предложат алтернативна препорака.

По добивањето повратни информации од BARB или групата или комитетот одговорен за одржување на спецификацијата, BSTS ќе ги достави препораките и повратните информации до Одборот за одбор за разгледување. Одборот може да ја покани групата или комисијата која е одговорна за одржување на засегнатите спецификации да се состане и да разговара за препораките. Одборот ќе ги разгледа препораките и повратните информации и може да се согласи или да го измени предлогот. Управниот одбор ќе побара BSTS да ги извести сите членови за предлозите за укинување или повлекување на спецификациите и поврзаните временски рокови за 30-дневен повторноview период за да им се овозможи на сите членови да дадат дополнителни повратни информации пред да ја донесат својата конечна одлука.

Одборот ќе ги разгледа повратните информации добиени од членовите. Откако Управниот одбор ќе го одобри укинувањето или повлекувањето на спецификацијата, BSTS ќе ги извести сите членови за одлуката и поврзаната временска рамка.

8.1 Откажување

Откако спецификацијата е застарена, ќе се случи следново:

Спецификацијата повеќе нема да се ажурира.
Одговорната РГ ќе реview сите извонредни грешки напишани против застарената спецификација за да се утврди дали се однесуваат на други спецификации. Грешките може да се отфрлат во системот за грешки и да се препишат според важечката спецификација(и).
WG или BSTS ќе создадат грешки за ажурирање на сите потребни референци за застарените спецификации во другите спецификации.
ОТИ ќе ги ажурира важечките документи за тестирање за да укаже на застарување на спецификацијата.
BSTS ќе го ажурира Bluetooth SIG webсајт со насоки во врска со алтернативните спецификација(и) за употреба.
Новите грешки веќе не може да се поднесуваат против застарена спецификација.
Спецификацијата нема да биде наведена во ниту една идна спецификација.
BSTS ќе архивира верзија на спецификацијата означена како застарена за членовите да можат да пристапат за историски цели.

8.2 Повлекување

Откако ќе се повлече спецификацијата, покрај чекорите што се применуваат за отпишување, ќе се случи следново:

ОТИ ќе ги ажурира важечките документи за тестирање за да укаже на повлекување на спецификацијата.
BSTS ќе го ажурира Bluetooth SIG webсајт со насоки во врска со алтернативните спецификација(и) за употреба.
BSTS ќе архивира верзија на спецификацијата означена како повлечена за членовите да можат да пристапат за историски цели.

Одборот може да избере веднаш да ја повлече спецификацијата без претходно да ја отфрли спецификацијата.

9. Процес на бела хартија

Белите книги се креирани само за информативни цели. Следниот процес на бела хартија се однесува на сите Bluetooth WG, EG, SGs и комитети. Овој дел не се однесува на информативни документи за употреба само во рамките на Bluetooth SIG.

Овој процес е илустриран на Слика 9.1 подолу.

Пред која било група или комитет да започне со работа на бела хартија што имаат намера да ја објави Bluetooth SIG, групата или комитетот ќе подготви и предложено ажурирање на повелбата со јасно дефинирање на предложената содржина на белата книга и презентација на предлогот во бела хартија.

Презентацијата на предлогот за бела хартија мора да содржи најмалку:

Потребата за бела хартија
Резиме на предложената содржина на белата книга
Објаснување зошто содржината не се препорачува да биде вклучена како дел од спецификацијата
Предвидената публика
Сите планови за одржување (т.е., проценетото време пред следното објавување на оваа бела книга може да биде неопходно)
Препораки за тоа како да се постапува со претходните верзии на белата хартија, доколку ги има (на пр., архивирање)

Ажурирањето на повелбата и презентацијата на предлогот за бела книга мора да се достават за BARB повторноview. По реview и одобрување на ажурирањето на повелбата од страна на BARB, BSTS ќе го достави ажурирањето на повелбата до Одборот на одобрување заедно со придружната презентација на предлогот за бела книга.

Доколку ОД го одобри ажурирањето на повелбата, групата или комитетот може да продолжи со изработка на белата книга.

Кога групата или комисијата ќе го заврши развојот на белата книга, BSTS ќе изврши уредувачка ревизијаview за усогласеност со насоките за изработка на Bluetooth.

По решавањето на коментарите на BSTS, групата мора да ја достави белата книга до BSTS за правен одговорview. По завршување на правната реview, групата и BSTS ќе се договорат за повратните информации што треба да се вклучат во белата книга. Доколку има нерешени правни забелешки од правна реview на белата хартија, претседавачот на групата може да побара време на дневниот ред на ОО за да побара придонес од ОД за решението.

Паралелно со правната реview, групата мора да ја достави белата хартија до БАРБ за повторноview. Како дел од нивната реview, BARB може да препорача дали кој било дел од белата хартија треба да се отстрани од белата хартија и да се вклучи во спецификација по процесот во Дел 3. BARB може да одлучи да ја достави белата хартија до други групи или комисии за повторноview. По завршувањето на BARB реview, групата и BARB ќе се договорат за повратните информации што треба да се вклучат во белата книга.

Доколку законската реview резултира со какви било суштински промени, дополнителни реview од страна на BARB може да се бара. Слично на тоа, ако BARB повторноview резултира со какви било суштински промени, БСТС ќе утврди дали дополнителна правна реview од тие промени се бара. По завршување на правната реview и BARB реview, BARB мора или да одобри или да ја одбие белата хартија.

Откако BARB ќе ја одобри белата книга, белата хартија одобрена од BARB ќе биде претставена од авторската група или комисија до Одборот за одобрување.

Процесот на бела книга е завршен кога ОД ќе ја одобри белата книга и ќе се завршат следните активности по одобрувањето:

BSTS ја направи одобрената бела хартија јавно достапна на Bluetooth SIG webсајт.
BSTS ги известува сите членови на одобрената бела хартија.
Ако белата книга е подобрување на постоечката бела хартија, BSTS ќе архивира верзија на белата книга за членовите да можат да пристапат за историски цели.

Bluetooth SIG планира да ги заврши активностите по одобрувањето во рок од една недела по одобрувањето на белата книга.

10. Референци

Референцирани документи со Bluetooth се достапни од Bluetooth webсајт http://www.bluetooth.com.

Насоки за изработка на Bluetooth (достапни на страницата Шаблони и документи на работната група, на https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Подзаконски прописи на Bluetooth SIG, Inc. (достапен на страницата со Управни документи, на https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Bluetooth Specification Errata Process документ (достапен на страницата Шаблони и документи на работната група, на https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Документ за процес на работна група (достапен на страницата Шаблони и документи на работната група, на https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Тест стратегија и терминологија завршиview документ (достапен на страницата Барања за квалификациски тест, на https://www.bluetooth.com/specifications/qualification-test-requirements)
ОТИ спецификација Review Список за проверка на процесите (достапен на страницата Шаблони и документи на работната група, на https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Bluetooth SIG доделени броеви (https://www.bluetooth.com/specifications/assigned-numbers)
Шаблони и документи за работни групи (достапни на страницата Шаблони и документи на работната група, на https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Додаток за спецификација ГАТТ (GSS) (достапен на страницата Спецификации ГАТТ, на https://www.bluetooth.com/specifications/gatt)
Поднесете идеја за нова спецификација https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Акроними и кратенки

Табела А: Акроними и кратенки

Додаток А – Класификација на сериозноста на Erratum

Овој додаток ги сумира упатствата за класификација на сериозноста за грешка во спецификацијата. Оваа табела ќе биде додадена на идна ревизија на EPD, а потоа овој дел ќе биде избришан.

Прочитајте повеќе за овој прирачник и преземете PDF:

Документ за процесот на управување со спецификациите (SMPD) – Оптимизиран PDF
Документ за процесот на управување со спецификациите (SMPD) – Оригинален PDF

Имате прашања за вашиот прирачник? Објави во коментари!

Референци

Упатство за употреба