Specifikace procesu řízení dokumentu (SMPD)

Tento dokument, bez ohledu na jeho název nebo obsah, není specifikací Bluetooth, na kterou se vztahují licence udělené společností Bluetooth SIG Inc. („Bluetooth SIG“) a jejími členy na základě licenční smlouvy o patentu / autorském právu Bluetooth a licenční smlouvy Bluetooth.

TENTO DOKUMENT JE POSKYTOVÁN „TAK, JAK JE“, A BLUETOOTH SIG, JEJÍ ČLENOVÉ, A JEJICH PŘÍSLUŠENSTVÍ NEPOSKYTUJÍ ŽÁDNÁ ZASTOUPENÍ NEBO ZÁRUKY A ZRUŠENÍ VŠECH ZÁRUK, VÝSLOVNÝCH NEBO PŘEDPOKLÁDANÝCH, VČETNĚ ZÁRUKY OBCHODOVATELNOSTI, TITULU ŽE OBSAH TOHOTO DOKUMENTU JE BEZ CHYB.

V ROZSAHU NEZAKÁZANÉM ZÁKONEM, BLUETOOTH SIG, JEJÍ ČLENOVÉ A JEJICH PŘIDRUŽENÍ ODMÍTÁ VŠECHNY ODPOVĚDNOSTI VYPLÝVAJÍCÍ Z NEBO SOUVISEJÍCÍ S POUŽITÍM TOHOTO DOKUMENTU A JAKÉKOLI INFORMACE OBSAŽENÉ V TOMTO DOKUMENTU, VČETNĚ ZTRACENÉHO PŘÍJMU PŘERUŠENÍ NEBO ZVLÁŠTNÍCH, NEPŘÍMÝCH, NÁSLEDNÝCH, NÁHODNÝCH NEBO TRESTNÝCH ŠKOD, POKUD JE ZPŮSOBENO A BEZ ohledu na teorii odpovědnosti, A ŽE JE MOŽNÉ ZOBRAZIT JEJICH ČLENY NEBO JEJICH PŘÍSADY.

Tento dokument je vlastnictvím společnosti Bluetooth SIG. Tento dokument může obsahovat nebo pokrývat předměty, které jsou duševním vlastnictvím společnosti Bluetooth SIG a jejích členů. Poskytnutím tohoto dokumentu se neuděluje žádná licence na žádné duševní vlastnictví společnosti Bluetooth SIG nebo jejích členů.

Tento dokument se může bez upozornění změnit.

1. Úvod

Dokument o procesu řízení specifikací (SMPD) popisuje procesy, které autoři specifikace a reviewUživatelé se musí řídit, aby vyvinuli nové specifikace a zlepšili stávající specifikace (tj. přidali nebo odstranili funkce nebo změnili konkrétní funkce v přijaté specifikaci), udržovali přijaté specifikace a řídili konec životnosti přijatých specifikací. Kromě toho tento dokument popisuje proces vytváření, reviewa schvalování bílých knih.

V procesu vývoje specifikací existují rozdíly mezi vývojem nových specifikací a vylepšením stávajících specifikací kvůli inherentním rozdílům v rozsahu těchto úkolů; tyto rozdíly jsou v tomto dokumentu zvýrazněny.

Proces vývoje specifikace zahrnuje:

Fáze požadavků (popsaná v části 3) k definování funkčních požadavků
Fáze vývoje (popsaná v části 4) k vývoji a přepracováníview specifikace

Fáze ověřování (popsaná v části 5) k ověření specifikací pomocí testování interoperabilního prototypu (IOP)
Fáze přijetí / schválení (popsaná v části 6) k předání specifikací správní radě Bluetooth SIG (BoD) k přijetí / schválení

Dokument Specification Errata Process (EPD) [3] popisuje proces navrhování a přepracováníviewing. specifikace chyb a jejich schválení jako opravy chyb (jak je definováno ve stanovách [2]) podle přijatých specifikací. Pokud není uvedeno jinak, všechny odkazy na chyby v tomto SMPD znamenají chyby specifikace.

1.1 Přednost

Stanovy společnosti Bluetooth SIG, Inc. (Stanovy) a členské dohody [2] mají přednost před jakýmkoli konfliktním obsahem v těchto dokumentech a SMPD. Bez ohledu na cokoli v tomto dokumentu si představenstvo ponechává maximální diskrétnost a pravomoc jednat a rozhodovat, i když tyto kroky a rozhodnutí nebudou v tomto dokumentu následovat nebo s nimi nebudou v rozporu a nic v tomto dokumentu neomezuje nebo neomezuje nezávislou autoritu představenstva. a diskrétnost.

Pokud dojde ke konfliktu mezi textem v SMPD a čísly, text má přednost.

1.2 Odkazy na skupiny a výbory

V tomto dokumentu se odkazuje na následující typy skupin: Studijní skupiny (SG), Expertní skupiny (EG) a Pracovní skupiny (WG). WG může mít také podskupinu, která je podřízena WG. Podobně jsou v tomto dokumentu uvedeny následující typy výborů: Bluetooth Architectural Review Board (BARB), Bluetooth Test and Interoperability (BTI) a Bluetooth Qualification Review rada (BQRB). Tento dokument také odkazuje na technický personál Bluetooth SIG (BSTS) a představenstvo.

1.3 Výbor k věciviews a schválení

Výbor review je jsouview kterou vedou členové komise (obvykle 3 členové), aby poskytli zpětnou vazbu ve stanoveném čase (obvykle 2–3 týdny), nicméněview doba se může lišit v závislosti na délce a složitosti materiálu a dalších prioritách v rámci komise. Skupina požadující review a výbor provádějící review se každý dohodne na délce trvání review. Členové skupiny a komise používají nástroje Bluetooth SIG k upozornění a zaznamenání začátku a konce review. Skupina obvykle zpracuje zpětnou vazbu výboru, jakmile ji obdrží. Když výbor review vyprší čas, skupina dokončí řešení zpětné vazby výboru a měla by také zvážit případné pozdní příchodyview zpětnou vazbu s tím, že materiál může podléhat následnému schválení komisí.

Souhlas výboru je získán hlasováním členů výboru v souladu s procesním dokumentem pracovní skupiny [4].

1.4 Sdělení členům a přístupnost materiálů

Všechna oznámení poskytovaná členům podle tohoto dokumentu mohou být poskytována e-mailem, například pravidelná technická aktualizace. Oznámení, která mají být poskytována všem členům, budou zaslána všem aktivním členům (tj. Pokud členství nebylo pozastaveno, ukončeno nebo zrušeno). Když jsou oznámení zasílána e-mailem, budou zasílána na poslední známou e-mailovou adresu (jak se odráží v aktuálních záznamech Bluetooth SIG) každého jednotlivce, který se zaregistroval pod členským účtem členské společnosti a který se neodhlásil z přijímání e-mailových oznámení. Nic v tomto dokumentu nemění povinnosti ani požadavky Bluetooth SIG, pokud jde o poskytování upozornění podle Stanov nebo jakékoli jiné dohody mezi Bluetooth SIG a kterýmkoli členem.

Kdekoli tento dokument odkazuje na a webstránka, která je přístupná všem členům, to se týká přístupnosti pro jednotlivce, kteří mají aktivní účet Bluetooth SIG. Členové, kteří nemají aktivní účet, si mohou vytvořit účet přes Bluetooth SIG webmísto.

1.5 Šablony

Pro každý typ dokumentu (např. specifikace, bílé knihy, testovací dokumenty) uvedený v tomto SMPD poskytuje Bluetooth SIG šablonu. Šablona musí být použita jako základ pro každý dokument vytvořený v souladu s tímto SMPD. Pokud nepoužijete správnou šablonu, může dojít k neschválení dokumentu. Šablony jsou k dispozici na Bluetooth SIG webmísto [8].

1.6 Typy specifikací

Existuje několik typů specifikací Bluetooth SIG. Hierarchicky všechny specifikace závisí na specifikaci Bluetooth Core Specification. Specifikace jako tradiční profiles; tradiční protokoly; a na základě GATTfileSlužby založené na GATT a protokoly založené na GATT všechny závisí na funkcích v rámci základní specifikace. Další specifikace, jako jsou specifikace Mesh Model, závisí na Mesh Profile specifikace, která zase závisí na základní specifikaci.

Specifikace Core Specification Supplement (CSS) definuje datové typy, datové formáty a běžné profile a servisní chybové kódy, které se používají v základní specifikaci a dalších specifikacích a samy o sobě nedefinují žádné chování.

Specifikace GATT Specification Supplement (GSS) definuje charakteristické a deskriptorové formáty, které používá Profiles a službami a sama o sobě nedefinuje žádné chování.
Specifikace Mesh Device Properties (MDP) definuje vlastnosti sítě používané Mesh Profile a Mesh Model specifikace a sama o sobě nedefinuje žádné chování.

2. Přesview

Tato sekce poskytuje přesview procesů a není zamýšleno tak, aby zahrnovalo všechny podrobnosti.

Obrázek 2.1 ukazuje šest hlavních fází, které tvoří proces správy specifikací.

První čtyři fáze probíhají během procesu vývoje specifikace a skládají se z fáze požadavků (část 3), fáze vývoje (část 4), fáze ověřování (část 5) a fáze přijetí / schválení (část 6). Poté následují dvě fáze po přijetí: Fáze údržby specifikace (část 7) a Fáze ukončení životnosti specifikace (část 8).

Obrázek 2.2 ilustruje podrobnosti o čtyřech fázích procesu vývoje specifikace. Šedá pole označují hlavní výstupy pro každou fázi. Oranžové rámečky shrnují milníky procesu.

Ve fázi požadavků (popsané v části 3) iniciuje proces zahájení specifikace návrh nové práce (New Work Proposal (NWP)) definováním uživatelských scénářů, které mají být povoleny, pokud bude pokračovat nová práce. Pokud je NWP schválen, přidělená skupina vytvoří dokument Functional Requirements Document (FRD). Jakmile je FRD schválen a přiřazen ke skupině, začíná vývojová fáze.

Během vývojové fáze (popsané v části 4) postupuje vývoj specifikace prostřednictvím sekvence stages (0.5/DIPD až 0.9/CR), které vyvrcholí kompletním návrhem specifikace. Specifikace 0.9/CR je zpřístupněna všem členům a poté předložena představenstvu, které zvažuje specifikaci ke schválení. Po schválení začíná fáze ověřování.

Během ověřovací fáze vývoje specifikace (popsané v části 5) je všem členům zpřístupněna specifikace 0.9/CR schválená představenstvem.view a potvrdit, a Member Review je spuštěno. Ověření se provádí prostřednictvím testování interoperability (IOP) mezi prototypy, které jsou sestaveny členy. Jakmile je dokončeno testování IOP (je-li to požadováno pro specifikaci) a BARB schválí zprávu o testu IOP, začne fáze přijetí/schvalování.

Během fáze přijetí / schválení (popsané v části 6) se finalizuje specifikace a související zkušební dokumenty; Jsou přijímána schválení BARB, BQRB a BTI; a balíček finální specifikace je předložen představenstvu, které považuje specifikaci za přijatelnou (tj. konečné schválení).

Specifikace může vyžadovat návrat k předchozí fázi nebo fázímtage pokud jsou provedeny významné změny. V některých případech může být také možné upustit od části fáze, jak je popsáno v části 4.4.

Fáze údržby specifikace (popsaná v části 7) začíná poté, co Rada přijme specifikaci. Během této fáze jsou hlášeny a vyhodnocovány potenciální chyby nalezené v přijaté specifikaci a (pokud je to nutné) jsou provedeny Errata opravy ve specifikaci. Fáze údržby specifikace pokračuje, dokud nebude specifikace zastarána nebo stažena (viz Fáze ukončení životnosti specifikace v následujícím odstavci).

Fáze ukončení životnosti specifikace (popsaná v části 8) popisuje postup pro ukončení podpory a zrušení přijatých specifikací.

3. Fáze požadavků

Fáze požadavků začíná buď NWP (které uvádí touhu zahájit práci na jednom nebo více uživatelských scénářích) nebo po zjištění, že požadovaná nová práce je již pokryta jejich charterovou smlouvou WG. Pokud pracovní skupina chce zahájit novou práci, o které se domnívá, že již spadá do rozsahu její charty pracovní skupiny, musí pracovní skupina postupovat podle postupu definovaného v oddíle 3.1, aby mohla pokračovat přímo v rozvoji FRD. U všech ostatních pracovních položek musí pracovní skupina postupovat podle postupu uvedeného v části 3.2. FRD definuje rozsah funkčních požadavků, které se používají k sestavení specifikací ve vývojové fázi. Fáze požadavků je znázorněna na obrázku 3.1.

3.1 Nová práce, na kterou se vztahuje pracovní listina pracovní skupiny

Když WG chce zahájit novou práci a důvodně věří, že funkce, kterou chce přidat, je již v rozsahu její charty WG, WG může začít pracovat na FRD, za předpokladu, že to okamžitě oznámí BARB. Pracovní skupina zahrne do svého oznámení pro BARB popis navrhované nové práce a kopii charty pracovní skupiny se zvýrazněným jazykem, který je opravňuje k zahájení nové práce.

Pokud BARB odmítne analýzu pracovní skupiny, musí pracovní skupina přestat pracovat na FRD a pokračovat v procesu NWP popsaném v části 3.2. Pokud BARB schválí analýzu pracovní skupiny, pracovní skupina okamžitě upozorní BSTS (e-mailem na specifikaci.manager@bluetooth.com) a BSTS přidá položku do další agendy BoD.

Pracovní skupina zahrne do svého oznámení BSTS stejné informace, jaké poskytla BARB. Pokud představenstvo odmítne analýzu pracovní skupiny, musí pracovní skupina přestat pracovat na FRD a pokračovat v procesu NWP popsaném v části 3.2. Pokud představenstvo schválí analýzu pracovní skupiny, může pracovní skupina pokračovat v práci na FRD, jak je uvedeno v části 3.3.

3.2 Nový návrh práce (NWP)

Každý člen, WG, SG nebo EG může vytvořit a odeslat NWP (prostřednictvím Bluetooth SIG webmísto [10]). NWP musí obsahovat minimálně informace o následujícím pomocí oficiální šablony uvedené v [8]:

Uživatelské scénáře
Členský závazek rozvíjet FRD a v jaké oblasti (oblastech) (např. Přispěvatel, Autor, Reviewehm, prototypování)

Navrhované vedení práce FRD
Navrhované skupinové přiřazení pro práci FRD
E-mailová adresa primárních autorů

Poznámka: Pokyny k procesu NWP jsou k dispozici na Bluetooth SIG webmísto [10].

BSTS bude během vývoje NWP plnit následující úkoly:

Poskytněte autorům potvrzení o přijetí (obvykle do sedmi kalendářních dnů od přijetí) a nastínte další kroky.

V případě potřeby spolupracujte s autory, aby byl NWP jasný a úplný. To může vyžadovat několik iterací NWP.
Pokud NWP obsahuje prohlášení o chybách v přijatých specifikacích Bluetooth, pracujte s jejich autory file vstupy do systému errata.
Pokud si všimnete, že NWP potenciálně duplikuje práci, která již probíhá nebo již byla dokončena, informujte autory dalších prací o jejich vyhodnocení.

Odešlete NWP do NWP webstránky přístupné všem členům.
Oznamte všem členům, že NWP je k dispozici pro znovuview a zda je zapotřebí další závazek členů k rozvoji FRD.

Členové mohou kontaktovat autora (autory), aby mu položili otázky nebo poskytli zpětnou vazbu týkající se NWP.

Nejméně tři členské společnosti se musí zavázat k účasti na dokončení výsledné FRD, aby se NWP mohla stát kandidátem na schválení BoD, a alespoň jedna členská společnost musí být členem přidruženým nebo promotérem. Po schválení představenstvem NWP přidělí představenstvo NWP existující celočlenné podskupině WG nebo SG pro práci na FRD (popsáno v části 3.3). Pokud příslušná podskupina WG nebo SG neexistuje, lze ji vytvořit.

U NWP, které mají dostatečné odhodlání členů, provede BSTS následující další úkoly:

Nejméně 13 dní před tím, než představenstvo navrhne schválení NWP, informujte BARB a skupinu, které je NWP doporučeno pro přiřazení, o čekajícím schválení NWP. Důvodem je poskytnout příležitost k zpětné vazbě v oblastech, jako je navrhovaná skupina, zda již je NWP pokryta existující prací atd.

Odešlete vyplněný NWP představenstvu.

Pokud NWP předkládají členové, kteří nejsou spojeni se skupinou, zajistěte, aby jeden z členů představil NWP představenstvu.
Pokud NWP předkládá skupina, zajistěte, aby předseda skupiny představil NWP představenstvu.

Pozvěte předsedu BARB a předsedy skupiny, do níž je doporučeno přidělení NWP, na schůzi představenstva.
Pokud je NWP schválen a přiřazen představenstvem, informujte skupinu, ke které byl přiřazen; autoři); členové identifikovaní v NWP jako členové, kteří se zavázali vyvinout odpovídající FRD; a pokud NWP navrhuje skupina, skupina výsledku a další kroky.

Po schválení NWP představenstvem aktualizujte stav NWP webmísto.

Představenstvo může podle svého uvážení odmítnout jakýkoli NWP, napřample, z důvodu omezení zdrojů, pokud je práce již zcela dokončena, je práce mimo rozsah řídících dokumentů Bluetooth SIG (např. rozhraní pro programování aplikací (API)) [2], nebo pokud by navrhovaná práce měla být filed jako erratum. Pokud je NWP odmítnut, BSTS uvědomí autora (autory), členy označené v NWP jako zavázané k vytvoření odpovídajícího FRD, a pokud je NWP navržen skupinou, skupinu. Oznámení bude obsahovat případné důvody zamítnutí. Autor (autoři), angažovaní členové nebo skupina mohou požádat o čas na pořadu jednání představenstva, aby se mohli proti zamítnutí odvolat.

Pokud člen nebo skupina chce navrhnout odebrání prvku z přijaté specifikace, musí skupina nebo člen připravit NWP. NWP musí zahrnovat analýzu dopadu, který bude mít odstranění na zpětnou kompatibilitu a interoperabilitu, včetně analýzy dopadu na testovací případy.

NWP nejsou vyžadovány pro vylepšení specifikací CSS, GSS nebo MDP: aktualizace specifikací CSS, GSS nebo MDP jsou obvykle výsledkem aktualizací jiných specifikací, které mají své vlastní NWP.

3.3 Dokument o funkčních požadavcích (FRD)

FRD definují funkční požadavky, aby umožnily uživatelské scénáře. FRD musí obsahovat přinejmenším informace o následujících údajích s využitím oficiálního vzoru uvedeného v [8]:

Uživatelské scénáře
Funkční požadavky založené na uživatelských scénářích

Závazek člena k vývoji výsledných specifikací
Volitelná podpora prototypů u členů pro očekávané role
Doporučená pracovní skupina pro vývoj výsledných specifikací

Vývoj FRD

FRD jsou vytvářeny přiřazenou celočlennou podskupinou WG nebo členy SG s redakční podporou od BSTS. Do skupiny se může připojit kterýkoli člen, který má zájem o účast na vývoji FRD.

FRD musí označovat závazek alespoň dvou (ačkoli tří se doporučuje) členských společností na úrovni přidružených nebo promotérů podílet se na vývoji výsledné specifikace. Pracovní skupiny nebo SG, které předkládají FRD, by se měly pokusit dosáhnout široké podpory od společností členů skupiny, které představují zamýšlený cílový průmyslový segment identifikovaný v FRD.

Nová funkce, která je navržena ve FRD, by měla být podporována na co největším počtu přenosů a stávajících zařízení. To zahrnuje napřample, podporující pro založené na GATTfiles a služby na přenosech Basic Rate/Extended Data Rate (BR/EDR) a Bluetooth Low Energy (LE). Pokud nová funkčnost postrádá dostatečnou podporu členů pro přenos, napřample z důvodu nedostatečného odhodlání členů definovat použití dopravy nebo potenciálně nedostatečného počtu testovacích platforem IOP pro jednu nebo více rolí může být podpora této dopravy z FRD vyloučena.

Pokud není jinak zdůvodněno, nová funkčnost, profiles a služby musí být v souladu s požadavky na zpětnou kompatibilitu popsanými v části 3.3.2.

WG nebo SG musí předložit FRD BARB k reviziview a schválení. BARB musí FRD schválit nebo zamítnout na základě svého technického úsudku. Pokud bude schválen BARB, FRD bude zpřístupněn všem členům a oznámení o jeho dostupnosti vydá BSTS.

FRD nejsou vyžadovány pro vylepšení specifikací CSS, GSS nebo MDP: aktualizace specifikací CSS, GSS nebo MDP jsou obvykle výsledkem aktualizací jiných specifikací, které mají své vlastní FRD.

Požadavky na zpětnou kompatibilitu

Zpětná kompatibilita pro BR / EDR

Pro provoz BR / EDR je požadavek na zpětnou kompatibilitu definován jako spolupráce s částí BR / EDR části Bluetooth Core Specification v1.1 a novější.

Zpětná kompatibilita pro Bluetooth Low Energy

Pro operaci LE je požadavek zpětné kompatibility definován jako spolupráce s LE částí specifikace Bluetooth Core v4.0 a novější.

Zpětná kompatibilita pro jiné než základní specifikace

U specifikací jiných než specifikace Bluetooth Core Specification musí být zachována zpětná kompatibilita dané verze se všemi dřívějšími verzemi, které mají stejné hlavní číslo verze. Napřample, verze 1.3 musí být kompatibilní s verzemi 1.2, 1.1 a 1.0, ale verze 2.0 nemusí být kompatibilní s verzemi 1.0, 1.1, 1.2 a 1.3. Upozorňujeme, že zvýšení čísla hlavní verze základní specifikace neznamená nedostatek zpětné kompatibility s předchozími verzemi.

Výjimka z požadavků zpětné kompatibility

WG nebo SG mohou navrhnout vyjmout konkrétní funkce z požadavku zpětné kompatibility, pokud je poskytnuto odůvodnění. NapřampPokud se prokáže, že funkce má nízkou míru přijetí na trhu nebo z důvodu problémů s interoperabilitou je lepší funkci odstranit nebo nahradit, než funkci upravit. WG nebo SG musí zahrnout všechny výjimky zpětné kompatibility ve FRD, které schvaluje BARB po schválení FRD. Jakékoli výjimky schválené BARB budou předloženy představenstvu ke schválení na 0.9/CR Stage.

3.4 Charta pracovní skupiny

Když BARB schválí FRD, které má být přiřazeno k existující pracovní skupině, musí tato pracovní skupina připravit koncept aktualizace své charty, aby přidala novou funkčnost do rozsahu (pokud představenstvo dříve neschválilo analýzu pracovní skupiny, že aktualizace charty pracovní skupiny je není požadováno). Když však BARB schválí FRD, které má být přiděleno nové pracovní skupině, musí BARB a členové, kteří mají zájem o vývoj funkcí uvedených ve FRD, připravit návrh charty pro novou pracovní skupinu s novou funkcí zahrnutou do rozsahu charty .

Jakmile je nová nebo aktualizovaná charta WG připravena, musí být předložena společnosti BARB k opětovnému schváleníview a schválení. Jakmile BARB schválí chartu, bude návrh nové nebo aktualizované charty WG předložen představenstvu ke schválení.

Jakmile představenstvo schválí chartu, musí pracovní skupina, které byla pověřena vývojářskou prací specifikací, úzce spolupracovat se skupinou, která připravila FRD v případě, že jsou vyžadovány jakékoli nezbytné aktualizace nebo vysvětlení této FRD. Pokud je během vývojové fáze nutná aktualizace FRD, musí být dodrženy procesy uvedené v části 3.3 a v této části; vývoj specifikací však může nastat souběžně s aktualizacemi chart FRD a WG.

3.5 Požadavky Požadavky na ukončení fáze

Fáze požadavků je dokončena a fáze vývoje začíná, když BoD charter s nezbytným rozsahem pro FRD buď potvrdí, nebo schválí představenstvo a budou splněny následující požadavky:

NWP byla buď schválena představenstvem, nebo představenstvo souhlasilo s tím, že NWP není nutný.

FRD a odpovídající charterová smlouva WG byla schválena společností BARB.

4. Vývojová fáze

Během vývojové fáze přidělené pracovní skupiny vytvoří novou specifikaci a / nebo vylepší stávající specifikaci. FRD definuje požadavky nové nebo vylepšené specifikace Bluetooth. Ve specifikaci není povolena žádná funkce, která se přiměřeně netýká požadavků ve FRD. Cílem je vytvořit specifikaci 0.9 / CR, která je připravena pro ověřovací fázi (popsanou v části 5) na konci vývojové fáze.
Během vývojové fáze postoupí specifikace (nebo vylepšení specifikace) o tři sekundytages.

Pro novou specifikaci, tři stages jsou:

0.5 Stage
0.7 Stage

0.9 Stage

Pro vylepšení specifikace jsou tři stages jsou:

Návrh dokumentu návrhu zlepšení (DIPD) Stage

Dokument konečného návrhu zlepšení (FIPD) Stage
Žádost o změnu (CR) Stage

Každý stage je dále popsáno v následujících pododdílech. Obrázek 4.1 níže ilustruje různé dokumenty, které WG připraví v každém stage.

Obrázek 4.1: Přesview specifikace stagkteré se vyskytují během vývojové fáze

Úlohou BARB v celém procesu vývoje specifikace je poskytovat pracovním skupinám rady a technickou pomoc. Pracovní skupiny mohou kdykoli požádat BARB o technické poradenství týkající se vývoje specifikací a architektonických konceptů, které mají být použity ve specifikaci. Pracovní skupiny se obzvláště vyzývají k získání včasné zpětné vazby od BARB pro funkce, které mají složitější architektonické úvahy.

4.1 0.5/DIPD Stage

Během 0.5/DIPD Stage, WG vyvine následující pomocí oficiálních šablon uvedených v [8]:

Pro novou specifikaci je návrh specifikace 0.5, který musí obsahovat minimálně informace o následujících:

Architektura k pokrytí požadavků stanovených ve směrnici FRD

U protokolů jsou definovány servisní přístupové body
Pro služby, vystavená data a chování
Pro proffiles, identifikované protokoly a specifikovaná funkčnost

2. Pro vylepšení specifikace návrh DIPD, který musí obsahovat minimálně informace o:

Pozadí: Rozsah práce, cíle, kterými se práce řídí, a to, jak tento konkrétní návrh zapadá do oblasti působnosti
Nadview návrhu: Souhrn rozšířených funkcí (přidaná flexibilita, lepší výkon atd.) Poskytovaných DIPD, včetně jasného popisu týkajícího se toho, jak nová funkce zapadá do aktuální verze specifikace. Pokud pracovní skupina vyhodnotila více návrhů, měly by být tyto návrhy zahrnuty, aby měl BARB příležitost určit, zda byla při výběru upřednostňovaného návrhu provedena dostatečná náležitá péče.

Pokrytí požadavků: Souhrn pokrytí funkčních požadavků daných návrhem s odkazem na příslušné systémové požadavky a scénáře použití uvedené v příslušné FRD
Definice problému: Prohlášení o problémech vyřešených návrhy
Kritéria výběru: Prohlášení týkající se kritérií výběru / výkonu z přidružených hodnotících metrik, které vedly proces výběru

Odůvodnění volby: Zkoumání metrik hodnocení, které ospravedlňují výběr mezi návrhy a odhalují kompromisy
Popis: Popis funkcí a rozšířených protokolů. Tato část se může přizpůsobit různým potřebám přidáním příslušných podsekcí.

3. Strategie testování: Popis funkčnosti, která má být testována (nebo netestována) jako součást kvalifikačního programu Bluetooth, a způsob, jakým má být funkčnost testována (např. očekávání na dolním testeru nebo na horním testeru) a zda budou zkoušky přisuzovány jako zkoušky shody nebo interoperability nebo jako kombinace obou). To může být v samostatném dokumentu nebo v samostatné části specifikace 0.5/DIPD. Konvence, které mají být použity v testovací strategii, jsou popsány v testové strategii a terminologiiview dokument (TSTO) [5].

Primární publikum dokumentů na této stage jsou členové WG a BARB, kteří review architektonické návrhy a pokrytí požadavků a BTI, kteří reviews Testovací strategie. Ve většině případů jsou dokumenty na tomto stage nejsou určeny k tomu, aby obsahovaly text, který je plánován k zahrnutí do konečné specifikace.

BSTS musí znovuview všechny dokumenty, aby byly konzistentní s pokyny pro návrh Bluetooth [1] a identifikovaly problémy, které má WG řešit. BARB musí znovuview specifikace 0.5/DIPD. Pro vylepšení specifikace musí BARB také znovuview DIPD pro shodu s požadavky na zpětnou kompatibilitu popsanými v části 3.3.2. ZISZ musí znovuview testovací strategii.

BARB musí buď schválit nebo zamítnout specifikaci 0.5/DIPD na základě svého technického úsudku. Pokud to schválí BARB, bude specifikace 0.5/DIPD k dispozici na Bluetooth SIG webstránky všem přidruženým členům a členům pořadatele a oznámení o její dostupnosti vydá BSTS. Při 0.5/DIPD Stage, schválení strategie testování se nevyžaduje.
0.5/DIPD Stage není vyžadováno pro vylepšení specifikací CSS, GSS nebo MDP

0.5/DIPD Stage výstupní požadavky

0.5/DIPD Stage je kompletní a 0.7/FIPD Stage začíná, když jsou splněny následující požadavky na ukončení:

BSTS dokončila reviewspecifikace 0.5/DIPD a testovací strategie.

BARB schválil specifikaci 0.5 / DIPD.
ZISZ dokončila svou review testovací strategie.
Společnost BSTS zpřístupnila schválenou specifikaci 0.5 / DIPD všem členům přidruženého a promotéra.

4.2 0.7/FIPD Stage

Během 0.7/FIPD Stage, WG vyvine následující pomocí oficiálních šablon uvedených v [8]:

Pro novou specifikaci je návrh specifikace 0.7, který musí obsahovat minimálně informace o následujících:

Popis všech změn, které byly provedeny od schválení BARB 0.5, včetně nových nebo upravených návrhů, výběrových kritérií a odůvodnění výběru. Změny musí být popsány na stejné úrovni podrobností, jak je požadováno v 0.5 Stage.

Všechny funkční požadavky z FRD řešeny.

2. Pro vylepšení specifikace návrh FIPD, který musí obsahovat minimálně informace o:

Popis všech změn, které byly provedeny od DIPD schváleného BARB, včetně nových nebo upravených návrhů, výběrových kritérií a odůvodnění výběru. Změny musí být popsány na stejné úrovni podrobností, jak je požadováno v DIPD Stage.

Podle potřeby dále rozvinuté oblasti, které byly popsány v části 4.1 týkající se DIPD.
Kompletní popis vylepšení.
Aktualizovaný architektonický popis.
Všechny funkční požadavky z FRD řešeny.

3. 0.7 / FIPD testovací dokumenty, které musí obsahovat minimálně informace o následujících:

Sada testů, skládající se ze seznamu účelů testování popsaných v TSTO [5].
Prohlášení o shodě s implementací (ICS), jak je popsáno v TSTO [5].

Pro vylepšení specifikací mohou být Test Suite a ICS dodány buď jako samostatné dokumenty, nebo jako další oddíly FIPD.

Primárním publikem dokumentů vyrobených v této stage jsou členové WG a BARB, kteří review úplný popis funkce nebo vylepšení včetně textu plánovaného pro zahrnutí do konečné specifikace. BTI je publikum pro znovuview zkušebních dokumentů.

BSTS bude znovuview nové nebo změněné části specifikace 0.7/FIPD a zkušební dokumenty pro soulad s pokyny pro návrh Bluetooth, včetně jazykových konvencí stanovených společností Bluetooth SIG. BARB bude znovuview specifikace 0.7/FIPD.

BSTS bude WG pomáhat s přípravou zkušebních dokumentů 0.7 / FIPD v souladu s TSTO [5].

ZISZ musí znovuview zkušební dokumenty 0.7/FIPD. Pracovní skupina musí poskytnout ZISZ specifikaci 0.7/FIPD jako referenci, když bude reviewzkušebních dokumentů 0.7/FIPD, které budou ZISZ review v souladu se specifikací ZISZ Review Kontrolní seznam procesu [6].

Poté, co BARB dokončí svou review specifikace 0.7/FIPD a ZISZ dokončila svou review ze zkušebních dokumentů 0.7/FIPD provede BSTS reviewed 0.7/FIPD specifikace je k dispozici všem členům přidruženého a promotéra.

0.7/FIPD Stage není vyžadováno pro vylepšení specifikací CSS, GSS nebo MDP.

0.7/FIPD Stage výstupní požadavky

0.7/FIPD Stage je kompletní a 0.9/CR Stage začíná, když jsou splněny následující požadavky na ukončení:

BSTS dokončila reviewspecifikace 0.7/FIPD a testovací dokumenty.
BARB dokončil reviewpodle specifikace 0.7/FIPD.
ZISZ byla dokončena znovuview0.7/FIPD Test Suite (Test Purposes) a 0.7/FIPD ICS.
BSTS udělala reviewed 0.7/FIPD specifikace je k dispozici všem členům přidruženého a promotéra.

4.3 0.9/CR Stage

Existují dva typy CR: Integrovaný CR, což je dokument sledovaný změnami celé přijaté specifikace zobrazující všechny změny od předchozí verze, a Zkrácený CR, což je dokument, který poskytuje pokyny k úpravám pouze dotčených částí verze specifikace, na které je ČR založena.

Během 0.9/CR Stage, WG vyvine následující pomocí oficiálních šablon uvedených v [8]:

Pro novou specifikaci obsahově kompletní koncept specifikace 0.9, který musí obsahovat minimálně informace o následujících:

Popis všech změn, které byly provedeny od BARB-reviewed specifikace 0.7 (nebo od specifikace 0.5, pokud bylo upuštěno od výroby specifikace 0.7), včetně nových popř.
upravené návrhy, kritéria výběru a odůvodnění výběru. Změny musí být popsány na stejné úrovni podrobností, jak je požadováno v 0.5 Stage a 0.7 Stage.

2. Pro vylepšení specifikace:

Buď Integrovaný CR, který musí obsahovat minimálně informace o:
Popis všech změn, které byly provedeny od BARB-reviewed FIPD (nebo od DIPD, pokud bylo FIPD upuštěno) včetně nových nebo upravených návrhů, výběrových kritérií a odůvodnění výběru. Změny musí být popsány na stejné úrovni podrobností, jak je požadováno v DIPD Stage a FIPD Stage.
Všechny změny navržené k dříve přijaté specifikaci pomocí sledování změn.
Všechny schválené technické opravy (s každou opravou odkazovanou na číslo opravy), zobrazené pomocí sledování změn, které dosud nebyly začleněny do dříve přijaté verze specifikace, a tento dopadový text, který je spojen s vylepšením specifikace; nebo které jinak ovlivňují testování IOP.

3. Nebo zkrácený CR, který musí obsahovat minimálně informace o:

Popis všech změn, které byly provedeny od BARB-reviewed FIPD (nebo od DIPD, pokud bylo FIPD upuštěno) včetně nových nebo upravených návrhů, výběrových kritérií a odůvodnění výběru. Změny musí být popsány na stejné úrovni podrobností, jak je požadováno v DIPD Stage a FIPD Stage.
Všechny změny navržené pro každou ovlivněnou část a odstavec specifikace, které ČR navrhuje změnit.
Všechny schválené technické opravy (s každou opravou odkazovanou na číslo opravy), zobrazené pomocí značek, které dosud nebyly začleněny do dříve přijaté verze specifikace, a tento dopadový text, který je spojen s vylepšením specifikace; nebo které jinak ovlivňují testování IOP.

4. CSS CR (pokud specifikace vyžaduje nové položky), který může být vložen do zkráceného CR specifikace.
5. GSS CR (pokud specifikace vyžaduje nové položky), který může být vložen do zkráceného CR specifikace.
6. MDP CR (pokud specifikace vyžaduje nové položky), který může být vložen do zkráceného CR specifikace.
7. Zkušební dokumenty 0.9 / CR, které musí obsahovat minimálně informace o následujících, které používají oficiální vzor uvedený v [8]:

Sada 0.9 / CR Test Suite, která obsahuje testovací případy s úplným obsahem a související tabulku mapování testovacích případů (TCMT), jak je popsáno v TSTO [5].
0.9 / CR ICS, jak je popsáno v TSTO [5].
Pokud konfigurace testů vyžaduje specifické parametry pro Implementation Under Test (IUT), bude 0.9 / CR Implementation eXtra Information for Testing (IXIT).
Seznam referencí testovacích případů 0.9 / CR (TCRL) (volitelný pro aktualizace specifikace jádra).

8. Analýza pokrytí testu označující, které požadavky na specifikaci jsou testovány nebo netestovány v rámci sady testů 0.9 / CR (pro vylepšení specifikací musí analýza pokrytí testů zahrnovat pouze nově přidanou a ovlivněnou funkčnost, a nikoli neovlivněné oblasti původní specifikace).
9. Plán zkoušek IOP.

Pro vylepšení specifikací mohou být Test Suite, ICS a IXIT dodány buď jako samostatné dokumenty, nebo jako další oddíly ve Zkrácené verzi CR.

Integrovaný nebo zkrácený CR by měl ve většině případů vycházet z dříve přijaté verze specifikace, ale může také vycházet z posledního přechodného návrhu. Nejnovější číslo verze zprostředkujícího konceptu specifikace musí být číslo verze přidružené k verzi dokumentu, která je zmrazená a která se časem nezmění. Jinak další identifikační údaje (například datum dokumentu a URL k identifikaci konkrétní „základní“ verze. Pokud se použije přechodný koncept, musí být zahrnuty všechny změny, které přímo nesouvisejí s CR v dané části, kterou CR upravuje, ale nemusí se zobrazovat pomocí značek. Pokud budou příslušné části přechodného konceptu později aktualizovány, musí být CR aktualizována, aby odrážela aktualizace přechodného konceptu.

V ideálním případě je zkrácený materiál CR integrován do návrhu úplné specifikace a úplných zkušebních dokumentů před fází ověřování, ale mohou být také integrovány na začátku fáze ověřování. Pokud se pro specifikaci vyvíjí více funkcí (např. Core Specification), může být žádoucí integrovat funkce do jediného konceptu po dokončení testování IOP.

BSTS bude znovuview specifikace 0.9/CR a testovací dokumenty pro soulad s pokyny pro návrh Bluetooth. Pak bude BARB znovuview specifikace 0.9/CR následovaná později plánem testu IOP (jak je popsáno v části 4.3.1). Jakmile WG předloží BARB specifikaci 0.9/CR k reviziviewBSTS jej zpřístupní všem členům znovuview a informovat všechny členy o jeho dostupnosti. Od tohoto okamžiku v procesu vývoje specifikace bude BSTS zpřístupňovat návrhy specifikace předložené BARB všem členům s pravidelnými upozorněními zasílanými všem členům.

Pokud jde o vylepšení specifikace, pracovní skupina doporučí představenstvu, zda by předchozí verze specifikace měly být zastaralé nebo zrušené, včetně technických důvodů doporučení.

BARB bude znovuview analýza WG týkající se souladu specifikace 0.9/CR s požadavky uvedenými ve FRD, jakýchkoli potenciálních bezpečnostních problémů, jakýchkoli regulačních problémů, souladu s architekturou Bluetooth a pro vylepšení specifikace shody s požadavky na zpětnou kompatibilitu popsanými v části 3.3.2 .XNUMX. Pokud BARB zjistí jakékoli potenciální bezpečnostní problémy, BARB uvědomí BSTS znovuview a koordinace se skupinou bezpečnostních expertů; a pokud BARB identifikuje jakékoli regulační důsledky, BARB vyrozumí BSTS, aby review a koordinovat s regulačním výborem a právním poradcem Bluetooth SIG. BARB musí specifikaci 0.9/CR buď schválit, nebo zamítnout na základě svého technického úsudku a zvážení faktorů popsaných v tomto odstavci.

ZISZ bude znovuview testovací dokumenty 0.9/CR s přihlédnutím k analýze pokrytí testem. BTI musí schválit nebo zamítnout zkušební dokumenty 0.9/CR.

Poté, co BARB schválí specifikaci 0.9/CR, WG předloží plán testování IOP BARB k opětovnémuview.

Specifikace 0.9 / CR schválená BARB je předložena představenstvu za účelem schválení zahájení testování IOP a zveřejnění specifikace 0.9 / CR všem členům.

Pro zdůraznění potenciálních právních problémů mohou pracovní skupiny požádat o upřesněníview právním zástupcem společnosti Bluetooth SIG (právní review) před kogentní právní review probíhá během fáze přijímání/schvalování. Nicméně, pro vylepšení specifikace, právní review by mělo být provedeno na Integrovaném ČR (na rozdíl od Zkráceného ČR) a toto by mělo být předem naplánováno s co největším předstihem, aby byly dostupné zdroje.

Plán zkoušek IOP

WG vypracuje písemný plán testu IOP, který musí splňovat všechny níže definované požadavky pro použití během fáze ověřování na akcích testu IOP. Pracovní skupiny musí předložit plán testů IOP společnosti BARB k reviziview před začátkem testu IOP. U jednoduchých vylepšení specifikací (zejména těch, která nevyžadují úpravu nebo přidávání jakýchkoliv testovacích případů do sady testů) nemusí být testování IOP potřeba a WG může podat žádost BARB o prominutí testování IOP pomocí definovaného procesu. v části 4.4.

Plán zkoušek IOP musí obsahovat:

Testovací případy k ověření všech nových povinných, volitelných a podmíněných funkcí
Alespoň jeden testovací případ pro každý operační kód
Alespoň jeden testovací případ pro každý parametr
Alespoň jeden testovací případ pro každý typ paketu
Testovací případy zpětné kompatibility pro vylepšení specifikací, aby byly u všech vylepšených funkcí splněny požadavky uvedené v části 3.3.2 (viz také část 4.3.1.1).
Testovací případy, kdy je IUT vystaven hodnotám mimo definované rozsahy nebo aspektům chování považovaným za neplatné nebo neočekávané (testovací případy neplatného chování). Mějte na paměti, že se očekává, že iniciátorem neplatného chování bude tester, jako je PTS nebo jiný testovací nástroj.
Jakákoli dočasně přidělená čísla (vybraná v koordinaci s BSTS, aby se zabránilo překrývání při nadcházejících testovacích událostech IOP), která mají být použita při testovací události IOP, jak je popsáno v části 4.3.1.2.
Identifikace požadovaného počtu nezávislých implementací, které musí projít každým testovacím případem, s přihlédnutím k požadavkům na pokrytí popsaným v oddíle 4.3.1.3
Identifikace případných testovacích případů v testovací sadě, o nichž se WG domnívá, že by měly být vyloučeny, a odůvodnění jejich vyloučení. Mezi ně obvykle patří: • Testovací případy budoucího korektury (např. Běžné testy, aby bylo možné vyhovět možným budoucím doplňkům, jako jsou další charakteristiky, rozšiřující charakteristiky nebo použití bitů nebo polí RFU).
• Testovací případy, které jsou podmnožinou dalších zahrnutých testů
• Obecné testovací případy, které jsou prakticky identické s testy, které běží pro několik dalších specifikací (např. Spouštění běžných chybových kódů)
• Testovací případy se stejným testovacím účelem jako testovací případy, které běží přes jiný transport (např. Testovací případ BR / EDR, který je podobný testovacímu případu LE)
• Robustnost nebo zátěžové testování implementace

Plán testů IOP může také zahrnovat testy, které jsou jedinečné pro testování IOP, jako jsou testovací případy typu end-to-end, které spojují složitější sekvence, které se mohou podobat typickému uživatelskému scénáři.

Ačkoli není vyžadováno schválení zkušebního plánu IOP (s vědomím, že plán zkoušek IOP bude i nadále upravován a vylepšován s každou událostí zkoušky IOP), je vyžadováno schválení zkušebního protokolu IAR ze strany BARB (viz část 5.1.1) . Pokud plán zkoušek IOP nesplňuje všechny požadavky definované v oddíle 4.3.1, měla by pracovní skupina před začátkem zkušebních událostí IOP předložit souhrn všech známých odchylek a zdůvodnění každé odchylky BARB.

Plán testování IOP a testovací případy by měly být primárně založeny na obsahu testovacích dokumentů přidružené specifikace.

Aby byly testovací události IOP efektivní, měla by pracovní skupina mít plán testování IOP a všechny související testovací případy dokončené a dostupné implementátorům v ideálním případě alespoň jeden měsíc před první testovací událostí IOP.

Plánování zpětného testování kompatibility
Pro vylepšení specifikací musí testování IOP zpětné kompatibility vzít v úvahu ověření proti všem aktivním a zastaralým verzím specifikace, protože tyto specifikace a funkce běžně používané v produktech Bluetooth mohou mít velmi dlouhou životnost (např. vozidla). WG musí analyzovat vhodnou úroveň potřebného testování zpětné kompatibility (pokud existuje), včetně toho, které verze testovat a testy, které je třeba provést, a poskytnout tuto analýzu BARB. BARB musí znovuview analýzu a doporučení změn (pokud existují) pro pracovní skupinu, aby je začlenila do plánu testování IOP.

Členům účastnícím se zpětného testování kompatibility se doporučuje, aby přinesli starší zařízení, která byla kvalifikována oproti předchozím verzím specifikací. Pracovní skupina musí hlásit jakékoli chyby zpětné kompatibility v protokolu o zkoušce IOP. Členským společnostem se rovněž doporučuje, aby provedly zpětné testování kompatibility ve svých vlastních laboratořích mimo místo konání testovací události IOP a aby případné problémy se specifikacemi nahlásily pracovní skupině.

Dočasná přiřazená čísla použitá při testování IOP
Aby bylo možné koordinovat dočasné přiřazení přidělených čísel, která budou použita při testovací události IOP, je nutné konzultovat BSTS a BARB, aby nedocházelo k překrývání nebo střetům s jinými specifikacemi. Tyto dočasné hodnoty musí být zahrnuty do plánu zkoušek IOP a nebudou přiřazeny k použití žádnými přijatými specifikacemi.

Pro testování IOP, kde se navrhuje jedna nebo více nových 16bitových hodnot UUID, jsou pro testování IOP vyhrazeny hodnoty v rozsahu 0x7F00 až 0x7FFF.

Pro testování IOP, kde se navrhuje jedna nebo více nových hodnot Fixed Protocol Service Multiplexer (PSM), budou použity hodnoty začínající od konce platného rozsahu od 0x0000 do 0x007F, jak je uvedeno ve Specifikaci jádra.

Požadavky na pokrytí
Pracovní skupina musí BARBu prokázat, že každý testovací případ prošel požadovaným počtem (jak je popsáno v následujících částech) nezávislých implementací. Jakákoli žádost pracovní skupiny o výjimky z požadovaného počtu nezávislých implementací musí být uvedena v plánu zkoušek IOP, který je předložen BARB.

Implementace se považují za vzájemně nezávislé, pokud všechny části, které jsou relevantní pro validaci, byly vyvinuty nezávisle, tj. Různými týmy (které nemusí nutně pocházet od různých společností). BSTS může pomoci při hodnocení, zda lze prototypy považovat za navzájem nezávislé, aby byla zachována anonymita a důvěrnost podrobností implementace.

Všimněte si, že testovací nástroje, včetně PTS, nejsou považovány za nezávislé implementace.

Základní specifikace požadavků na pokrytí IOP
Funkce Specifikace jádra obvykle definuje jednu nebo více rolí, kde je každá role navržena tak, aby spolupracovala s jednou nebo více jinými rolemi nebo případně sama se sebou.

Pro každou dvojici rolí, které jsou navrženy pro vzájemnou spolupráci, musí být prokázáno, že alespoň tři nezávislé implementace každé role spolupracují se třemi nezávislými implementacemi doplňkové role.

Pro každou roli, která může spolupracovat s jiným zařízením ve stejné roli, musí alespoň tři nezávislé implementace této role prokázat, že mohou v dané roli vzájemně komunikovat.

Specifikace služby Požadavky na pokrytí IOP
Alespoň tři nezávislé implementace služby musí prokázat, že spolupracují s alespoň jednou implementací klienta, což může být PTS.

Profile a požadavky na pokrytí IOP specifikace protokolu
Profile a specifikace protokolu typicky definují jednu nebo více rolí, kde každá role je navržena tak, aby spolupracovala s jednou nebo více dalšími rolemi nebo případně sama se sebou.

Pro každou dvojici rolí, které jsou navrženy pro vzájemnou spolupráci, musí alespoň dvě nezávislé implementace každé role prokázat, že spolupracují se dvěma nezávislými implementacemi doplňkové role.

Pro každou roli, která může spolupracovat s jiným zařízením ve stejné roli, musí alespoň tři nezávislé implementace této role prokázat, že v dané roli vzájemně interagují.

Požadavky na pokrytí IOP podle specifikace modelu
Alespoň tři nezávislé implementace modelu serveru nebo řídicího modelu musí prokázat, že spolupracují s alespoň jednou implementací klienta (což může být PTS), a alespoň jedna implementace modelu klienta musí prokázat, že spolupracuje s alespoň jednou implementací modelu serveru a PTS.

Číslování verzí specifikací

Během 0.9/CR Stage, WG musí připravit doporučení, které předloží představenstvu ohledně čísla verze, která se má použít na specifikaci, až bude přijata.

Verze specifikací lze rozdělit na dva typy: plné verze, které obsahují nové nebo aktualizované funkce, a verze pro údržbu (známé také jako „dot-Z verze“), které integrují technickou a redakční chybu, ale neobsahují nové ani aktualizované verze. funkce. Verze s úplným vydáním mají dvoudílná čísla v podobě XY, například 2.1 nebo 5.0, zatímco verze s údržbou mají trojdílná čísla v podobě XYZ, například 2.1.2. Hodnota Z nemůže být 0.

U všech dvou verzí je jedna označována jako „vyšší verze“ a druhá jako „nižší verze“. To se určuje podle následujících pravidel:

Pokud se komponenty X liší, pak je s vyšší hodnotou X „vyšší verze“.
Pokud jsou komponenty X stejné, ale komponenty Y se liší, je ta s vyšší hodnotou Y „vyšší verze“.
Pokud jsou komponenty XY stejné, ale komponenty Z se liší, je ta s vyšší hodnotou Z „vyšší verze“. Dvoudílné číslo XY je pro tento účel považováno za třídílné číslo XY0.

Napřample, následující čísla verzí budou v pořadí od nejnižší verze po nejvyšší verzi: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. U CSS každá aktualizace zvyšuje pouze složku X čísla verze.

Předpoklady schválení představenstva
Na konci fáze vývoje specifikací musí být před předložením specifikace 0.9 / CR představenstvu ke schválení splněny následující požadavky:

Pracovní skupina dokončila analýzu pokrytí testu.
BSTS dokončila reviewspecifikace 0.9/CR a testovací dokumenty.
BARB schválil specifikaci 0.9 / CR.
BARB schválil CSS CR (pokud specifikace vyžaduje nové položky), které mohou být vloženy do zkráceného CR specifikace.
BARB schválil GSS CR a MDP CR (pokud specifikace vyžaduje nové položky).
BTI schválila sadu testů 0.9/CR, ICS a TCRL spolu s IXIT (za předpokladu, že IXIT je potřeba k provádění testů v testovací sadě). TCRL je v tomto případě volitelnétage pro aktualizace základní specifikace.
Pracovní skupina předložila plán testů IOP společnosti BARB k přepracováníview (pokud se BARB nevzdá testování).

Dokumenty předložené představenstvu musí obsahovat specifikaci schválenou BARB 0.9 / CR a představení představenstvu, které musí obsahovat:

Jakékoli známé žádosti o upuštění od testování IOP nebo některý z požadavků definovaných v části 4.3.1
Seznam transportů, které specifikace podporuje (např. BR / EDR, LE atd.)
Pro vylepšení specifikace jakékoli výjimky z požadavků na zpětnou kompatibilitu (popsané v části 3.3.2), které požaduje WG
Pro vylepšení specifikace doporučení pracovní skupiny pro číslo verze, které se má použít na přijatou specifikaci
Pro vylepšení specifikace je doporučení WG na konci životnosti pro předchozí verzi přijaté specifikace, včetně všech technických důvodů, proč je nebo není doporučeno ukončení nebo stažení jakékoli předchozí verze specifikace, a odůvodnění pro doporučení
Jakékoli nevyřešené vážné obavy ze strany členů BARB nebo ZISZ (např. důvody pro jakékoli Nehlasování během schvalování, obavy vyplývající z opětovnéhoview zkušebních dokumentů nebo obavy, že specifikace 0.9/CR je mimo rozsah FRD nebo charty)
Stav přípravy Profile Tuning Suite (PTS) nebo další potřebné nástroje spojené s přijetím, které připravuje BSTS

Představenstvo se může rozhodnout schválit specifikaci 0.9 / CR pro testování IOP, jak to vyžadují stanovy [2], než BTI schválí zkušební dokumenty 0.9 / CR a než pracovní skupina potvrdí, že plán zkoušek IOP splňuje požadavky definované v části 4.3.1. 0.9. Správní rada může také podmínit svůj souhlas se specifikací 0.9 / CR pro testování IOP na základě schválení zkušebních dokumentů XNUMX / CR ze strany BTI.

0.9/CR Stage výstupní požadavky
0.9/CR Stage je dokončeno a fáze validace začíná, když představenstvo schválí zahájení testování IOP.

4.4 Zproštění procesu vývoje specifikací

Pracovní skupina může požadovat vzdání se jednoho nebo více z následujících kroků procesu:

0.5/DIPD Stage
0.7/FIPD Stage
Testování IOP v rámci ověřovací fáze

K žádosti o prominutí musí WG použít šablonu procesního prominutí poskytnutou Bluetooth SIG [8] a předložit žádost o prominutí každému výboru (tj. BARB nebo BTI), který je povinen znovuview nebo schválit návrh specifikace nebo související zkušební dokumenty v stage, že WG navrhuje prominutí, a každý z těchto výborů musí žádost o prominutí schválit.

Žádost o vzdání se práva musí obsahovat následující:

Identifikace stage(y), kterých se chce WG vzdát
Odůvodnění, proč stage(s) by mělo být upuštěno
Identifikace každého výboru (tj. ZISZ a/nebo BARB), který je povinen review a schválit žádost o prominutí

Výbor, který zvažuje vzdání se práva, může požadovat, aby zástupce pracovní skupiny před předložením žádosti o vzdání se práva učinil prezentaci, aby ospravedlnil vzdání se SMPD procesu.

Pokud výjimka požaduje upuštění od několika kroků a část výjimky je zamítnuta a část je schválena, musí odpověď výboru uvést, které kroky v žádosti o výjimku byly schváleny a které byly zamítnuty. Pokud je žádost o zproštění povinnosti zamítnuta, oznámení o zamítnutí musí obsahovat důvody zamítnutí.

5. Fáze ověřování

Během Validační fáze bude WG provádět testování IOP na specifikaci 0.9/CR s cílem dodat zprávu o testu IOP pro BARB review a schválení. Kdykoli je to možné, testování IOP vylepšení specifikací by mělo být provedeno proti integrovanému návrhu specifikace. Kromě toho člen Review, jak vyžadují stanovy [2], začíná v této fázi.

Pokud specifikace (nebo vylepšení) nevyžaduje testování IOP, může být upuštěno od testování IOP ve fázi ověřování pomocí postupu popsaného v části 4.4.

V průběhu testování IOP (což může být jedna nebo více událostí) by WG měla sledovat problémy pomocí systému sledování problémů Bluetooth SIG a opakovat začlenění aktualizací návrhu specifikace, testovacích dokumentů a plánu testování IOP. Jakmile skončí testování IOP, WG musí dokončit aktualizace návrhu specifikace a testovacích dokumentů, aby se vyřešily všechny problémy, a připravit a odeslat zprávu o testu IOP společnosti BARB k opětovnému posouzení.view a schválení. To je znázorněno na obrázku 5.1.

Během ověřovací fáze může začít několik činností. Tyto činnosti mohou probíhat souběžně a zahrnují následující:

Specifikace 0.9/CR schválená představenstvem je zpřístupněna všem členům prostřednictvím BSTS s oznámením o zahájení členstvíview období vyžadované stanovami.
Všechny požadované aktualizace jsou začleněny do CSS (které mohou být vloženy do zkráceného CR specifikace).
Definice charakteristik nebo deskriptorů jsou začleněny do specifikace GSS a také do PTS pro testování IOP.
Definice vlastností sítě jsou začleněny do specifikace MDP i PTS pro testování IOP.
BSTS umožňuje registraci platformy IOP a nástroj pro zadávání výsledků v rámci přípravy na testování IOP.
Testování IOP, je-li požadováno (viz část 5.1).
Review připomínky a otázky, včetně těch, které byly předloženy v důsledku testování IOP, jsou zpracovány a změny jsou zapracovány do návrhu specifikace.

5.1 Testování IOP

Primárním cílem testování IOP je ověřit specifikaci napřample, kontrola správnosti a nejednoznačnosti v textu, reviewřešení jakýchkoli zásadních chyb a opomenutí v návrhu a poskytování ověření proti dříve stanoveným požadavkům vyvinutým dříve v procesu vývoje specifikace. Testování IOP může vést ke změnám návrhu specifikace a k dokončení všech požadovaných testů může být zapotřebí více událostí testu IOP.

Je důležité dát členům mimo WG možnost zúčastnit se testování IOP, protože poskytují nezávislé view specifikace a může odhalit oblasti nejednoznačnosti ve specifikaci, které nemusí být zřejmé členům pracovní skupiny, kteří návrh vypracovali. Před každou testovací akcí IOP zpřístupní BSTS podrobnosti akce, nejnovější návrh specifikace, testovací sadu a plán testování IOP a uvědomí všechny členy ideálně měsíc před každou akcí. Aktualizovaný návrh specifikace, testovací sada a plán testování IOP používané při testu IOP by měly být k dispozici nejméně jeden týden před každou akcí.

Během testování IOP se párové kombinace platforem pokusí provést testy a účastníci testování IOP zaznamenají výsledky úspěšného / neúspěšného každého testu a komentáře. Anonymizované shrnutí těchto výsledků (s odkazem např. Na „Platformu A“, „Platformu B“ atd.) A jakékoli komentáře budou shromážděny během testovacích akcí IOP a dány k dispozici členům WG během IOP a po něm testovací událost. V případě, že jsou potřebné další informace, aby bylo možné lépe porozumět jakýmkoli komentářům nebo selháním, ke kterým došlo během testování IOP, může BSTS působit jako prostředník pro shromažďování dalších informací od předkládajícího člena.

Pokud je to možné, měl by být PTS aktualizován, aby podporoval testování IOP s platformami ve všech vrstvách nad rozhraním hostitelského řadiče (HCI), a měl by být přítomen na testovacích událostech IOP pro tyto vrstvy. Na testovacích událostech IOP mohou být také přítomny další testovací nástroje. Do protokolu o zkoušce IOP by měl být zahrnut souhrn výsledků testování pomocí PTS nebo jiných testovacích nástrojů (pokud existují).

Testování IOP bude otevřeno všem členům, kteří chtějí poskytnout prototypovou implementaci, Bluetooth SIG však může podmínit účast přijetím dohod s Bluetooth SIG (včetně dohod o účasti a důvěrnosti). Pracovní skupina odpovídá za zpracování a řešení problémů objevených během testování IOP a aktualizaci příslušných dokumentů; Změny schválené WG musí být zahrnuty jako aktualizace návrhu specifikace a zkušebních dokumentů pro použití při každé zkoušce IOP.

Před ověřovací fází mohou pracovní skupiny provádět předběžné testování IOP na událostech, které jsou přístupné pouze pro členy pracovní skupiny, avšak výsledky neformálního testování nemusí být zahrnuty do výsledků testu IOP.

Může se stát, že budou dodrženy všechny kroky vedoucí k první testovací události IOP, včetně oznámeného data a umístění IOP s úmyslem zahájit testování IOP, ale schválení BoD nebylo zajištěno před zahájením testovací události. V tomto případě může představenstvo povolit zahrnutí výsledků testů, které byly shromážděny před schválením představenstvem pro zahájení testování IOP, za předpokladu, že shromážděné výsledky byly založeny na stejné specifikaci a testovací sada byla schválena představenstvem.

Testování IOP není vyžadováno pro vylepšení specifikací CSS, GSS nebo MDP.

Protokol o zkoušce IOP
Po dokončení testování IOP musí WG předložit zprávu o testu IOP společnosti BARB s cílem prokázat, že požadovaný počet nezávislých platforem prošel požadovanými testy. BARB musí znovuview a schválí nebo zamítne zprávu o testu IOP a oznámí WG, zda je potřeba další testování IOP, před předložením balíčku specifikací návrhu hlasování představenstvu. BSTS a WG musí zajistit, aby se ve zprávě o testu IOP neobjevily žádné informace identifikující člena, než zprávu předloží BARB.

Protokol o zkoušce IOP musí obsahovat:

Seznam všech testovacích událostí IOP, ke kterým došlo během ověřovací fáze, včetně jejich dat a umístění.
Počet členských společností a nezávislých platforem, které se účastnily každé události IOP, včetně toho, zda byl použit PTS.
Seznam specifikací, testovací sady a verzí plánu testování IOP použitých při každé události.
Shrnutí uvádějící, zda všechny testovací případy splňovaly minimální kritéria pro splnění kritérií.
Souhrn veškerých odchylek od požadavků plánu zkoušek IOP definovaných v oddíle 4.3.1 a odůvodnění každé odchylky.
Souhrn pokrytí PTS pro testovací případy v testovací sadě.
Seznam všech testovacích případů (včetně testů zpětné kompatibility) z plánu zkoušek IOP, počet testovacích testů, počet selhání testů a to, zda byla u každého testovacího případu splněna minimální kritéria, včetně vysvětlení, proč nebyly splněny nějaké požadavky se setkal.
Souhrn problémů, komentářů a otázek ke každé události (včetně těch filed proti specifikaci během testování IOP) a dopad na specifikaci a zkušební dokumenty.

5.2 Požadavky na ukončení validační fáze

Fáze ověřování je dokončena a fáze schválení / přijetí začíná, když BARB schválí protokol o zkoušce IOP (pokud BARB nezruší testování) a budou splněny všechny následující požadavky:

BSTS zpřístupnila schválenou specifikaci 0.9/CR všem členům pro Member Review jak to vyžadují stanovy a informovalo všechny členy o jeho dostupnosti.
Všechny problémy, které byly identifikovány během testování IOP a které mají dopad na test, byly začleněny a testovány.
Pracovní skupina dokončila testování IOP (pokud se BARB od testování nezřekla).

6. Fáze přijetí / schválení

Během fáze přijetí/schvalování se dokončuje specifikace a související testovací dokumenty, je přijato schválení BARB, BQRB a ZISZ, je vydáno oznámení o navrhovaném datu přijetí spolu s konečnou verzí návrhu specifikace předloženou představenstvu k přijetí ( Hlasovací návrh) a konečný balíček specifikací je předložen představenstvu. Po minimální době trvání Member Review byla splněna požadovaná stanovami [2]), představenstvo zváží specifikaci k přijetí ke dni přijetí. Po přijetí je specifikace zveřejněna a kvalifikační systém je aktivován. Fáze přijetí/schvalování je znázorněna na obrázku 6.1.

6.1 Návrh hlasování

Návrh hlasování je vytvořen začleněním aktualizací (poskytnutých ve fázi ověřování) do požadovaných dokumentů se specifikacemi a přípravou konečného návrhu nové specifikace. Pro vylepšení specifikací vytvoří BSTS integrovanou specifikaci integrací jednoho nebo více CR do dříve přijaté vyšší verze specifikace (viz část 4.3.2), pokud ještě není dokončena před ověřovací fází.

Pokud během této fáze dojde ke změnám ve specifikaci a WG, BARB nebo BTI určí, že jakákoli změna vyžaduje další testování IOP, specifikace se vrátí do části testování IOP ve fázi ověřování, aby WG provedla další testy. Během fáze přijetí / schválení budou před datem přijetí přijaty následující dokumenty, které budou představenstvu poskytnuty:

Návrh hlasování
Všechny podpůrné specifikace (tj. CSS, GSS, MDP) požadované pro příslušný typ specifikace (nebo vylepšení), pokud nebyly dříve přijaty
Pro vylepšení specifikací sledovaná změna přijaté verze specifikace, která zobrazuje změny navržené v hlasovacím návrhu
Popis WG všech požadavků na zpětnou kompatibilitu (jak je popsáno v části 3.3.2), které nebyly splněny, a odůvodnění případných výjimek
Popis všech požadavků plánu testu IOP (jak je popsáno v části 4.3.1), které nebyly splněny od pracovní skupiny, a zdůvodnění jakýchkoli odchylek spolu se zprávou o testu IOP (kterou lze poskytnout poskytnutím odkazu na kopii na Bluetooth SIG webweb)
Doporučení pracovní skupiny pro ukončení podpory nebo stažení jakékoli předchozí verze (verzí) přijaté specifikace spolu s odůvodněním, zdůrazňujícím změny od 0.9/CR Stage doporučení ke konci životnosti
Souhrn změn funkcí nebo funkcí od specifikace 0.9 / CR (pokud existují) připravený pracovní skupinou
Shrnutí, připravené BARB, obav vznesených členy BARB, že specifikace vypracovaná WG je nad rámec charty schválené představenstvem (pokud existuje)
Seznam zbývajících nevyřešených právních problémů z právní review (pokud existuje)
Sada testů schválená BTI spolu se shrnutím testovacího pokrytí specifikace hlasovacího návrhu schváleným WG. V případě nově přidané nebo upravené funkce bez pokrytí testem je vyžadováno písemné odůvodnění opomenutí
ICS a IXIT schválené BTI (pokud to vyžaduje specifikace)
TCRL schválila jak BTI, tak BQRB
Zpráva připravená BSTS společně s BTI týkající se stavu připravenosti nástroje (např. PTS a další testovací nástroje, Bluetooth Launch Studio), včetně toho, zda testovací nástroje nepodporují žádné testovací případy v TCRL
Souhrn všech potřebných přidělených čísel připravený pracovní skupinou
Kontrolní seznam pro přijetí připravený BSTS a WG, který ukazuje, že všechny výstupy v této části byly dokončeny
Všechny ostatní informace požadované představenstvem

Během fáze přijetí / schválení by pracovní skupina měla používat systém sledování problémů Bluetooth SIG k zachycení problémů a komentářů proti specifikaci návrhu a testovacím dokumentům, aby byly zohledněny při finalizaci specifikace hlasovacího návrhu. Pro vylepšení specifikace musí být začleněny všechny příslušné schválené chyby (tj. Schválené chyby ještě nejsou integrovány) a musí být identifikovány pomocí sledovaných změn.

WG musí předložit konečný návrh specifikace BSTS k právnímu posouzeníview. Pro nové specifikace platí právní review bude obsahovat celou specifikaci. Pro vylepšení specifikace, review se zaměří především na změněné části specifikace. Účelem právního review je především identifikovat právní rizika, která by WG měla zvážit a snažit se je vyřešit. Právní zpětná vazba bude kategorizována podle závažnosti. Pokud je volitelný právní review byla provedena na 0.9/CR Stage, verze, která je předložena k právní review musí ukazovat jako sledované změny všechny změny, které byly provedeny od této verze (generované buď WG nebo BSTS). Po ukončení právní reviewWG a BSTS se dohodnou na zpětné vazbě, která bude začleněna do návrhu specifikace. Pokud existují nějaké nevyřešené právní připomínky z právního review na návrhu specifikace může předseda PS požádat o čas na programu jednání představenstva k dohodě o řešení.

Souběžně s právní review, WG musí předložit návrh specifikace BARB k přepracováníview. Při prvním předložení BARB, BSTS oznámí všem členům, že návrh specifikace byl předložen BARB k opětovnémuview a že je k dispozici také pro Member Review. Pokud WG předloží aktualizace návrhu specifikace pro BARB re-reviewBSTS bude pravidelně zasílat dodatečná upozornění všem členům.

Po dokončení BARB reviewWG a BARB se dohodnou na zpětné vazbě, která bude začleněna do návrhu specifikace.

Pokud právní review má za následek jakékoli podstatné změny, dodatečné review od BARB může být vyžadováno. Podobně, pokud BARB review povede k jakýmkoli podstatným změnám, BSTS určí, zda další právní review těchto změn je vyžadováno. Po ukončení právní review a BARB review, BARB musí návrh hlasování schválit nebo zamítnout.

Pokud některé zkušební dokumenty vyžadují aktualizaci, BSTS bude WG pomáhat s aktualizací zkušebních dokumentů. ZISZ musí zkušební dokumenty buď schválit, nebo zamítnout. Pokud to BTI schválí, bude BTI pomáhat s dokončením TCRL a doručit tento dokument BQRB spolu s přidruženými ICS, IXIT a Test Suite. BSTS odhadne datum zasedání představenstva, kdy má představenstvo hlasovat o přijetí návrhu hlasování (datum přijetí), a poskytne jej ZISZ pro použití v TCRL. Schválení specifikace BARB, schválení BTI všech zkušebních dokumentů (včetně testovací sady, TCRL, ICS a IXIT) a schválení BRLR TCRL musí proběhnout v den přijetí nebo dříve.

BSTS bude informovat všechny členy o dokončení a dostupnosti návrhu hlasování a datu přijetí. Datum přijetí bude stanoveno nejdříve 60 dnů poté, co byli členové informováni o specifikaci 0.9/CR schválené představenstvem, pokud Člen Review lhůtu zkrátí představenstvo v souladu se stanovami a nejméně 14 dnů po oznámení o datu přijetí členům v souladu se stanovami. V případech, kdy bylo do návrhu hlasování začleněno více CR, začíná člen Review je datum, kdy byli členové informováni o nejnovějším CR schváleném představenstvem.

Poté, co je členům poskytnuto oznámení o datu přijetí, jsou povoleny opravy tiskových chyb schválené představenstvem v hlasovacím návrhu. Časová osa přijetí specifikace je znázorněna na obrázku 6.2.

6.2 Přiřazená čísla

Bluetooth SIG udržuje veřejně dostupnou sadu přiřazených čísel na Bluetooth SIG Assigned Numbers webmísto [7]. Tato přiřazená čísla jsou seskupena do různých číselných prostorů (související sada čísel bez duplikátů). Přiřazená čísla se mohou překrývat s jinými přiřazenými čísly v různých číselných prostorech, ale žádné číslo v rámci číselného prostoru není dovoleno znovu použít. Různé číselné prostory jsou definovány ve specifikaci, která definuje použití přiřazených čísel.

Poté, co BARB schválí zprávu o zkoušce IOP, WG předloží BARB požadavek na přidělení nových čísel v rámci číselných prostorů požadovaných konečnou specifikací. BARB bude znovuview požadavek a spolupracovat s BSTS na určení přidělených čísel. Po schválení BARB naplánuje BSTS zveřejnění přidělených čísel tak, aby byla veřejně dostupná na Bluetooth SIG Assigned Numbers webmísto [7] do jednoho týdne od přijetí specifikace.

Po zveřejnění přidělených čísel na Bluetooth SIG Assigned Numbers webna místě nebo v rámci přijaté specifikace, přiřazená čísla jsou zamýšlena jako neměnná (aby se neměnila ani hodnota, ani význam). Pokud se z nějakého důvodu stanou nepoužitelnými, stanou se vyhrazenými hodnotami a není povoleno je znovu použít.

6.3 Požadavky na ukončení fáze přijetí / schválení

Fáze schválení / přijetí je dokončena, když představenstvo přijalo specifikaci a byly dokončeny následující činnosti po přijetí:

BSTS zveřejnila konečná přidělená čísla na Bluetooth SIG webmísto.
Společnost BSTS zveřejnila přijatou specifikaci na Bluetooth SIG webmísto
BSTS zpřístupnila všechny podpůrné dokumenty (např. CSS, GSS, MDP) požadované pro příslušnou specifikaci veřejně na Bluetooth SIG webmísto.
BSTS zpřístupnila související testovací dokumenty všem členům Bluetooth SIG webmísto.
Pro vylepšení specifikací vytvořila BSTS informativní verzi se sledováním změn dříve přijaté verze specifikace se všemi změnami provedenými nově přijatou verzí a zpřístupnila ji všem členům na Bluetooth SIG. webmísto.
BSTS povolil kvalifikační systém.
BSTS informoval všechny členy o dostupnosti přijaté specifikace a všech podpůrných dokumentů.

Bluetooth SIG plánuje dokončit tyto aktivity po přijetí do jednoho týdne po přijetí specifikace.

7. Fáze údržby specifikace

Fáze údržby specifikace začíná po dokončení fáze přijetí / schválení. Pokud jsou nalezeny problémy (např. Nejasnosti ve formulaci nebo technické chyby) se specifikací nebo souvisejícími zkušebními dokumenty, musí být zdokumentovány vytvořením návrhů chyb pomocí nástroje Bluetooth SIG Errata. Opravy chyb specifikace budou zpracovány, roztříděny a schváleny podle EPD [3]. Oprava Test Suite je zpracována a kategorizována podle TSTO [5]. Pokud dojde ke konfliktu mezi SMPD a EPD nebo TSTO, má přednost SMPD.

Oprava specifikace musí být použita pouze k opravě technických nebo redakčních chyb v konečně přijatých specifikacích Bluetooth. Přidávání, změny a odstraňování funkcí lze provádět pouze prostřednictvím procesu vylepšení specifikací definovaného dříve v tomto dokumentu.

7.1 Zrychlený proces opravy

Pokud je chyba schválena podle procesu definovaného v EPD [3], WG, BARB nebo BSTS mohou doporučit, aby byla považována za naléhavou a měla by být urychlena. Když k tomu dojde, BSTS spolu s WG nebo BARB předloží doporučení představenstvu. Představenstvo rozhodne, zda doporučení přijme nebo odmítne. Pokud bude doporučení přijato, BSTS okamžitě začlení schválenou chybu do šablony chyb [8] a bude spolupracovat s odpovědnou WG na dokončení urychlené opravy chyb, která bude předložena WG k opětovnémuview a schválení.

Konecview zrychleného procesu erratum je znázorněno na obrázku 7.1.

Následující dokumenty musí být vyplněny a dány k dispozici představenstvu před datem přijetí:

Koncept schválený BARBem Expedited Errata Correction.
Popis WG jakýchkoli požadavků na zpětnou kompatibilitu (jak je popsáno v části 3.3.2), které nebyly splněny, a odůvodnění případných výjimek.
Seznam zbývajících nevyřešených právních problémů z právní review (pokud existuje).
Testovací sada schválená BTI, ICS a IXIT (pokud to vyžaduje erratum).
TCRL schválený BTI a BQRB (pokud to vyžaduje erratum).
Zpráva vyplněná BSTS společně s BTI týkající se stavu připravenosti nástroje (např. PTS a další testovací nástroje, Bluetooth Launch Studio), včetně toho, zda testovací nástroje nepodporují testovací případy v TCRL a vysvětlení (pokud to vyžaduje erratum ).
Kontrolní seznam pro přijetí vyplněný BSTS a WG, který ukazuje, že všechny výstupy v této části byly dokončeny.
Všechny ostatní informace požadované představenstvem.

BSTS bude spolupracovat s odpovědnou pracovní skupinou na dokončení návrhu urychlené opravy chyb a vytvoření verze, kterou předloží odpovědné pracovní skupině k opětovnémuview a schválení.

WG musí předložit urychlenou opravu chyb BSTS k právnímu řešeníview. Po ukončení právní review, WG a BSTS se dohodnou na zpětné vazbě, která bude začleněna do Urychlené opravy chyb. Pokud existují nějaké nevyřešené právní připomínky z právního review o urychlené nápravě chyb může předseda PS požádat o čas na programu jednání představenstva, aby si vyžádal vyjádření představenstva k řešení.

Souběžně s právní review, WG musí předložit urychlenou opravu chyb společnosti BARB k opětovnému zasláníview. Jakmile bude urychlená oprava Errata odeslána BARB, BSTS ji zpřístupní všem členům, aby ji mohli znovuview a informovat všechny členy o jeho dostupnosti. Po dokončení BARB review, WG a BARB se dohodnou na zpětné vazbě, která bude začleněna do Urychlené opravy chyb.

Pokud některé zkušební dokumenty vyžadují aktualizaci, bude BSTS pomáhat pracovní skupině s aktualizací testovacích dokumentů. Po schválení dokumentů o zkoušce ZISZ bude společnost BTI pomáhat s dokončením TCRL a předá dokument společnosti BQRB spolu s příslušnými ICS, IXIT a testovací sadou. BSTS odhadne datum přijetí a poskytne jej BTI pro použití v TCRL. Schválení BARB u Expedited Errata Correction, BTI schválení všech testovacích dokumentů (včetně testovací sady, TCRL, ICS a IXIT podle potřeby) a BQRB schválení TCRL musí dojít v den přijetí nebo dříve.

BSTS bude informovat všechny členy o dokončení a dostupnosti Expedited Errata Correction a navrhovaném datu přijetí. Datum přijetí bude stanoveno a oznámeno všem členům v souladu se stanovami [2] a datum přijetí bude nejméně 14 dní po obdržení oznámení členům. Poté, co bude členům poskytnuto oznámení o navrhovaném datu přijetí, může představenstvo schválit opravy typografických chyb ve zrychlené korekci opravy, aniž by poskytlo dodatečné oznámení o navrhovaném datu přijetí a počkalo požadovaných 14 dní.

Bluetooth SIG veřejně zpřístupní přijatou Expedited Errata Correction a plánuje tak učinit do jednoho týdne po přijetí. Oznámení o jeho dostupnosti vydá BSTS všem členům.

Proces urychlené eratum je dokončen, když představenstvo přijalo korekci urychlené errata a byly dokončeny následující činnosti po přijetí:

Společnost BSTS zveřejnila přijatou urychlenou opravu chyb a související testovací dokumenty (pokud to chyba vyžaduje) na Bluetooth SIG. webmísto.
BSTS povolil kvalifikační systém (pokud to vyžaduje erratum).
BSTS informoval všechny členy o dostupnosti přijaté urychlené korekce.

Po dokončení těchto aktivit bude naplánována integrace Errata Correction do ovlivněných specifikací buď jako součást plánovaného vylepšení specifikací, nebo v nadcházejícím vydání údržby, jak je popsáno v části 7.2.

7.2 Proces uvolnění údržby (specifikace .Z)

Přibližně jednou ročně BSTS určí, zda existují nějaké schválené errata (označované jako Errata Corrections), které jsou klasifikovány jako technické / vysoké nebo technické / kritické a které ještě musí být začleněny do textu jakékoli aktivní specifikace (tj. přijatá specifikace, která nebyla zastaralá ani zrušena). Definice klasifikace errata najdete v příloze A. Vlastník specifikace (buď WG objednaný k udržení specifikace, nebo BARB, pokud není WG objednaný k udržení specifikace) může také požádat o dřívější vydání údržby aktivní specifikace, do které by zahrnoval jakoukoli schválenou opravu. Na základě stanovení BSTS nebo požadavku vlastníka specifikace bude zahájen proces uvolnění údržby.

Konecview proces uvolňování údržby je znázorněn v části Error! Referenční zdroj nebyl nalezen.

Na začátku procesu uvolnění údržby BSTS společně s vlastníkem specifikace, BARB a BTI vytvoří a předloží představenstvu plán pro začlenění oprav Errata do publikované verze specifikace. Navrhovaný plán musí indikovat, zda budou Errata Corrections začleněny do údržbového vydání specifikace (tj. Verze .Z) nebo vylepšení specifikace, které již probíhá (tj. Verze XY). Navrhovaný plán by měl zohlednit, zda byly mezi verzemi přijatých specifikací přidány nějaké nové povinné funkce, odhadovaný čas, kdy je plánováno přijetí dalšího vylepšení specifikací, a další faktory.

Po schválení plánu představenstvem bude BSTS spolu s vlastníkem specifikace pokračovat v začlenění všech technických / středních, technických / vysokých a technických / kritických chybových oprav do návrhu specifikace označované jako „koncept uvolnění údržby“. Pokud jde o redakční nebo technické opravy / opravy s nízkou Errata, pokud se Errata Correction vztahuje na více než jednu verzi specifikace, BSTS, pokud představenstvo nerozhodne jinak, integruje tyto chyby do nejnovější verze s vyšší specifikací při příští aktualizaci této verze . Kromě konceptu Errata Corrections nelze do konceptu Release Release zahrnout žádné změny. Každý koncept vydání údržby musí identifikovat všechny začleněné opravy Errata pomocí sledování změn, aby ukázal navrhované změny dříve přijaté verze publikované specifikace.

Načasování navrhovaného začlenění pro každou opravu Errata do konceptu Release Release bude záviset na dopadu Test Suite: všechny opravy Errata, které nemají dopad Test Suite, mohou být začleněny hned, ale Errata opravy, které mají dopad na Test Suite budou zpracovány tak, aby se časování shodovalo s aktualizací TCRL.

BTI a BSTS stanoví lhůtu pro zahrnutí oprav Errata s dopadem Test Suite do konceptu Release Release. Tato lhůta je obvykle 3 až 6 měsíců před plánovaným datem schválení dalšího významného vydání TCRL. Opravy Errata s dopadem Test Suite, které zmeškají termín pro zařazení, budou zpracovány jako součást příštího ročního vydání TCRL. Pokud tedy není požadováno dřívější vydání, maximální doba pro technické / vysoké nebo technické / kritické opravy chyb, které mají být zahrnuty do aktualizace specifikace, je přibližně 15 až 18 měsíců.

Vlastník specifikace musí předložit návrh vydání údržby, který schválil jako konečný pro právní záležitostiview. Právní review se zaměří především na změněné části specifikace. Po ukončení právní review, vlastník specifikace a BSTS se dohodnou na zpětné vazbě, která bude začleněna do návrhu vydání údržby. Pokud existují nějaké nevyřešené právní připomínky z právního review na návrhu uvolnění z údržby může vlastník specifikace požádat o čas na agendě představenstva, aby si vyžádal vyjádření představenstva k řešení.

Souběžně s právní review, vlastník specifikace musí BARB předložit návrh na vydání údržby k reviziview. Jakmile bude návrh na vydání údržby předložen BARB, BSTS jej zpřístupní všem členům, aby si jej mohli znovuview a informovat všechny členy o jeho dostupnosti. Po dokončení BARB review, vlastník specifikace a BARB se dohodnou na zpětné vazbě, která bude začleněna do návrhu specifikace.

U oprav Errata, které mají dopad na testovací dokumenty, a kde bude příslušná testovací chyba zpracována včas pro nadcházející vydání TCRL, bude BSTS spolupracovat s vlastníkem specifikace a BTI na aktualizaci testovacích dokumentů. Po schválení zkušebních dokumentů ZISZ BSTS odhadne datum přijetí a poskytne navrhované datum přijetí BTI pro použití v TCRL. Společnost BTI dodá TCRL na BQRB spolu s příslušnými ICS, IXIT a testovací sadou. Schválení specifikace BARB, schválení BTI všech zkušebních dokumentů (včetně příslušných testovacích sad, TCRL, ICS a IXIT) a schválení BRLR TCRL musí proběhnout v den přijetí nebo dříve.

BSTS bude informovat všechny členy o dokončení a dostupnosti návrhu hlasování a navrhovaném datu přijetí. Datum přijetí bude stanoveno a oznámeno všem členům v souladu se stanovami a datum přijetí bude alespoň 14 dnů po oznámení členům o oznámení. Poté, co je členům poskytnuto oznámení o navrhovaném datu přijetí, může představenstvo schválit opravy typografických chyb v návrhu hlasování, aniž by poskytlo dodatečné oznámení o navrhovaném datu přijetí a počkalo požadovaných 14 dní.

Následující dokumenty musí být vyplněny a dány k dispozici představenstvu před datem přijetí:

Návrh hlasování
Změněná verze hlasovacího návrhu, která zobrazuje všechny změny přijaté verze specifikace, která má stejnou hodnotu XY (např. Pokud je hlasovací návrh navržen jako verze 1.4.2, změny budou sledovány oproti 1.4.1 verze specifikace)
Doporučení vlastníka specifikace k ukončení nebo stažení jakékoli předchozí verze přijaté specifikace spolu s odůvodněním
Seznam zbývajících nevyřešených právních problémů z právní review (pokud existuje)
Testovací sada, ICS a IXIT schválené BTI (pokud to vyžaduje vydání údržby)
TCRL schválený BTI a BQRB (pokud to vyžaduje vydání pro údržbu)
Zpráva vyplněná BSTS společně s BTI týkající se stavu připravenosti nástroje (např. PTS a další testovací nástroje, Bluetooth Launch Studio) včetně případných testovacích případů v TCRL, které nejsou testovacími nástroji podporovány, a vysvětlení (pokud to vyžaduje údržba uvolnění)
Kontrolní seznam pro přijetí vyplněný BSTS a vlastníkem specifikace, který ukazuje, že všechny výstupy v této části byly dokončeny
Všechny ostatní informace požadované představenstvem

Proces uvolnění údržby je dokončen, když představenstvo přijme návrh hlasování a budou dokončeny následující činnosti po přijetí:

Společnost BSTS zveřejnila přijatou specifikaci a související testovací dokumenty (pokud to vyžaduje vydání údržby) na Bluetooth SIG webmísto.
BSTS zpřístupnila všem členům Bluetooth SIG informativní verzi dříve přijaté specifikace se všemi změnami začleněnými do nově přijaté verze se sledováním změn. webmísto.
BSTS povolil kvalifikační systém.
BSTS informoval všechny členy o dostupnosti přijaté specifikace a podpůrných dokumentů.

Bluetooth SIG plánuje dokončit tyto aktivity po přijetí do jednoho týdne po přijetí specifikace.

Po dokončení těchto činností zůstane specifikace ve fázi Údržba specifikace, dokud nebude specifikace zastaralá nebo zrušena, jak je definováno v části 8.

8. Specifikace Fáze konce životnosti

Specifikace mohou být zastaralé nebo stažené, pokud jsou nahrazeny novějšími verzemi, které budou technicky nedostatečné, nebo z jiných důvodů. Zastaralé a stažené specifikace se archivují a již se neaktualizují. U zastaralých a stažených specifikací se v kvalifikačním programu Bluetooth zachází odlišně.

Kterýkoli člen, skupina nebo výbor může do BSTS (prostřednictvím e-mailu na adresu

specification.manager@bluetooth.com) kdykoli. BSTS může také doporučit ukončení podpory nebo stažení specifikace a související časové osy. BSTS předá doporučení BARB a skupině nebo výboru odpovědnému za udržování specifikace pro review a zpětná vazba.

BARB a odpovědná skupina nebo výbor vyhodnotí doporučení k zamítnutí nebo stažení specifikace a zváží následující (nevyčerpávající) kritéria:

Existuje v předchozí verzi specifikace funkce, která je zastaralá nebo by se neměla používat?
Byla do pozdějších verzí přidána nová povinná funkce?
Existují nedostatky v dřívějších verzích, které zhoršují provoz nebo interoperabilitu, které byly opraveny v novějších verzích a jsou nutné k prosazení stávajících uživatelských scénářů?
Existují další funkce v novějších verzích, které jsou nutné pro vývoj nových uživatelských scénářů?
Existuje v pozdějších verzích vylepšená použitelnost a interoperabilita?
Existují v novějších verzích bezpečnostní vylepšení?

BARB a příslušná skupina nebo výbor mohou navrhnout alternativní doporučení.

Po obdržení zpětné vazby od BARB nebo skupiny či výboru odpovědného za udržování specifikace, BSTS předloží doporučení a zpětnou vazbu představenstvu k posouzení. Představenstvo může vyzvat skupinu nebo výbor, které jsou odpovědné za udržování dotčených specifikací, aby se setkaly a projednaly doporučení. Představenstvo zváží doporučení a zpětnou vazbu a může s návrhem souhlasit nebo jej upravit. Představenstvo bude požadovat, aby BSTS informovala všechny členy o návrzích na ukončení podpory nebo stažení specifikací a souvisejících časových plánů po dobu 30 dnů.view aby všichni členové mohli poskytnout další zpětnou vazbu před přijetím konečného rozhodnutí.

Představenstvo zváží zpětnou vazbu od členů. Jakmile představenstvo schválí ukončení podpory nebo stažení specifikace, oznámí BSTS všem členům rozhodnutí a související časovou osu.

8.1 Ukončení podpory

Po ukončení podpory specifikace dojde k následujícímu:

Specifikace již nebude aktualizována.
Odpovědná pracovní skupina bude znovuview všechny zbývající chyby zapsané proti zastaralé specifikaci, aby bylo možné určit, zda se vztahují na jiné specifikace. Chyby mohou být odmítnuty v systému chyb a přepsány podle příslušné specifikace (specifikací).
Pracovní skupina nebo BSTS vytvoří errata k aktualizaci veškerých nezbytných odkazů na zastaralé specifikace v jiných specifikacích.
ZISZ aktualizuje příslušné dokumenty o zkouškách tak, aby naznačovaly ukončení podpory specifikace.
BSTS aktualizuje Bluetooth SIG webstránky s pokyny ohledně alternativní specifikace(í), které se mají použít.
Novou errata již nelze odeslat podle zastaralé specifikace.
Specifikace nebude uvedena v žádných budoucích specifikacích.
BSTS archivuje verzi specifikace označené jako zastaralá, aby měli členové přístup k historickým účelům.

8.2 Odstoupení od smlouvy

Jakmile je specifikace stažena, kromě kroků, které platí pro ukončení podpory, dojde k následujícímu:

ZISZ aktualizuje příslušné zkušební dokumenty tak, aby naznačovaly stažení specifikace.
BSTS aktualizuje Bluetooth SIG webstránky s pokyny ohledně alternativní specifikace(í), které se mají použít.
BSTS archivuje verzi specifikace označené jako stažená, aby měli členové přístup k historickým účelům.

Správní rada se může rozhodnout, že specifikaci okamžitě stáhne, aniž by nejdříve upustila od specifikace.

9. Zpracování bílé knihy

Bílé knihy jsou vytvářeny pouze pro informační účely. Následující proces white paper se vztahuje na všechny pracovní skupiny Bluetooth, EG, SG a výbory. Tato část se nevztahuje na informační dokumenty pro použití pouze v rámci Bluetooth SIG.

Tento proces je znázorněn na obrázku 9.1 níže.

Předtím, než jakákoli skupina nebo výbor zahájí práci na bílé knize, kterou má v úmyslu zveřejnit Bluetooth SIG, připraví skupina nebo výbor jak navrhovanou aktualizaci charty, která jasně definuje navrhovaný obsah bílé knihy, tak prezentaci bílé knihy.

Prezentace návrhu bílé knihy musí obsahovat minimálně:

Potřeba bílého papíru
Shrnutí navrhovaného obsahu bílé knihy
Vysvětlení, proč se obsah nedoporučuje zahrnout jako součást specifikace
Zamýšlené publikum
Jakékoli plány údržby (tj. Může být nutný odhadovaný čas před dalším vydáním této zprávy)
Doporučení, jak zacházet s předchozími verzemi bílé knihy, pokud existují (např. Archivace)

Aktualizace charty a prezentace návrhu white paper musí být předloženy pro BARB review. Při review a schválení aktualizace charty BARB, BSTS předloží aktualizaci charty představenstvu ke schválení spolu s podpůrnou prezentací návrhu bílé knihy.

Pokud představenstvo schválí aktualizaci charty, může skupina nebo výbor pokračovat v přípravě bílé knihy.

Když skupina nebo výbor dokončí vývoj bílé knihy, BSTS provede redakční reviziview pro soulad s Pokyny pro vytváření návrhů Bluetooth.

Po vyřešení připomínek BSTS musí skupina předložit bílou knihu BSTS k právnímu posouzeníview. Po ukončení právní review, skupina a BSTS se dohodnou na zpětné vazbě, která bude začleněna do bílé knihy. Pokud existují nějaké nevyřešené právní připomínky z právního review na bílé knize může předseda skupiny požádat o čas na programu jednání představenstva, aby si vyžádal vyjádření představenstva k řešení.

Souběžně s právní review, skupina musí předložit white paper společnosti BARB k reviziview. V rámci jejich reviewBARB může doporučit, zda by jakákoli část bílé knihy měla být z bílé knihy odstraněna a začleněna do specifikace v souladu s postupem v části 3. BARB se může také rozhodnout předložit bílou knihu k přepracování jiným skupinám nebo výborům.view. Po dokončení BARB review, skupina a BARB se dohodnou na zpětné vazbě, která bude začleněna do bílé knihy.

Poté, co BARB schválí bílou knihu, bude redakční skupina nebo výbor představen bílé knize schválené BARB představenstvu ke schválení.

Proces bílé knihy je dokončen, když představenstvo schválilo bílou knihu a byly dokončeny následující činnosti po schválení:

Společnost BSTS zveřejnila schválenou bílou knihu na Bluetooth SIG webmísto.
BSTS upozorní všechny členy schválené bílé knihy.
Pokud je dokument white paper vylepšení existujícího dokumentu white paper, archivuje BSTS verzi dokumentu, která bude pro členy přístupná pro historické účely.

Bluetooth SIG plánuje dokončit činnosti po schválení do jednoho týdne po schválení bílé knihy.

10. Reference

Odkazované dokumenty Bluetooth jsou k dispozici na Bluetooth webmísto http://www.bluetooth.com.

Pokyny pro vytváření Bluetooth (k dispozici na stránce Šablony a dokumenty pracovní skupiny na adrese https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Stanovy společnosti Bluetooth SIG, Inc. (k dispozici na stránce Governing Documents na adrese https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Dokument Specifikace Bluetooth Errata Process (k dispozici na stránce Šablony a dokumenty pracovní skupiny na adrese https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Zpracování dokumentu pracovní skupiny (k dispozici na stránce Šablony a dokumenty pracovní skupiny na adrese https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Test strategie a terminologie skončilview dokument (dostupný na stránce Požadavky kvalifikačního testu na adrese https://www.bluetooth.com/specifications/qualification-test-requirements)
Specifikace ZISZ Review Kontrolní seznam procesu (dostupný na stránce Šablony a dokumenty pracovní skupiny na adrese https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Přiřazená čísla Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Šablony a dokumenty pracovní skupiny (k dispozici na stránce Šablony a dokumenty pracovní skupiny na adrese https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Doplněk specifikace GATT (GSS) (k dispozici na stránce Specifikace GATT na adrese https://www.bluetooth.com/specifications/gatt)
Odeslat nápad na novou specifikaci https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Zkratky a zkratky

Tabulka A: Zkratky a zkratky

Dodatek A - Klasifikace závažnosti chyb

Tato příloha shrnuje pokyny pro klasifikaci závažnosti pro chyby specifikace. Tato tabulka bude přidána k budoucí revizi EPD a poté bude tato část odstraněna.

Přečtěte si více o této příručce a stáhněte si PDF:

Dokument specifikace procesu správy (SMPD) - Optimalizované PDF
Dokument specifikace procesu správy (SMPD) - Původní PDF

Máte otázky týkající se vašeho manuálu? Pište do komentářů!

Reference

Uživatelská příručka