სპეციფიკაციის მართვის პროცესის დოკუმენტი (SMPD)

Bluetooth® პროცესის დოკუმენტი

• შესწორება: V27
• შესწორების თარიღი: 2019-05-17
•  კავშირი ელ.ფოსტით: BARB-feedback@blu Bluetooth.org

რეზიუმე:
ეს დოკუმენტი განსაზღვრავს განვითარების პროცესებს Bluetooth სპეციფიკაციების და თეთრი ფურცლების შექმნისა და გაუმჯობესებისთვის.

გადასინჯვის ისტორია

უახლესი ვერსიის ავტორები

ეს დოკუმენტი, მიუხედავად მისი სათაურისა და შინაარსისა, არ არის Bluetooth სპეციფიკაცია, რომელსაც ექვემდებარება Bluetooth SIG Inc. ("Bluetooth SIG") და მისი წევრების მიერ Bluetooth პატენტის / საავტორო უფლებების სალიცენზიო შეთანხმებისა და Bluetooth სავაჭრო ნიშნის სალიცენზიო ხელშეკრულების საფუძველზე გაცემული ლიცენზიები.

წინამდებარე დოკუმენტი შეთავაზებულია "როგორც არის" და BLUETOOTH SIG, მისი წევრები და მათი პარტნიორები არ წარმოადგენენ რაიმე სახის წარმომადგენლობას ან გარანტიებს და გააუქმებენ ყველა გარანტიას, გამოხატვას ან გამოყენებას, მათ შორის, ნებისმიერი ფორმით პასუხისმგებლობის საკითხს, ამ დოკუმენტის შინაარსი შეცდომებისგან თავისუფალია.

რამდენადაც კანონით არ არის აკრძალული, BLUETOOTH SIG, მისი წევრები და მათი თანამშრომლები უარყოფენ ამ დოკუმენტის გამოყენებასთან დაკავშირებულ ყველა პასუხისმგებლობას და ამ დოკუმენტში შეტანილ ნებისმიერი სხვა ინფორმაციას, რომელშიც შედის შეთავაზება, ჩარევა, ან სპეციალური, არაპირდაპირი, თანმიმდევრული, შემთხვევითი ან პენიტენციური ზიანის მიყენება, რაც გამოწვეულია პასუხისმგებლობის თეორიით, და თუნდაც bluetootth ნიშანი, მისი წევრები, ან მათი დამხმარე პაციენტები

ეს დოკუმენტი Bluetooth SIG– ის საკუთრებაა. ეს დოკუმენტი შეიძლება შეიცავდეს ან მოიცავდეს საგანს, რომელიც წარმოადგენს Bluetooth SIG- ის და მისი წევრების ინტელექტუალურ საკუთრებას. ამ დოკუმენტის წარდგენა არ იძლევა ლიცენზიას Bluetooth SIG– ის ან მისი წევრების რომელიმე ინტელექტუალურ საკუთრებაზე.

ეს დოკუმენტი შეიძლება შეიცვალოს გაფრთხილების გარეშე.

საავტორო უფლებები © 2004–2019 Bluetooth SIG, Inc. Bluetooth სიტყვის ნიშანი და ლოგოები ეკუთვნის Bluetooth SIG, Inc. სხვა მესამე მხარის ბრენდებს და სახელებს მათი შესაბამისი მფლობელების საკუთრებაა.

 

1. შესავალი

სპეციფიკაციების მართვის პროცესის დოკუმენტი (SMPD) აღწერს პროცესებს, რომლებიც სპეციფიკაციის ავტორებმა და ხელახლაviewმკვლევარებმა უნდა დაიცვან ახალი სპეციფიკაციების შემუშავება და არსებული სპეციფიკაციების გაძლიერება (ანუ ფუნქციონირების დამატება ან ამოღება ან სპეციფიკური ფუნქციონირების შეცვლა მიღებულ სპეციფიკაციებში), მიღებული სპეციფიკაციების შესანარჩუნებლად და მიღებული სპეციფიკაციების სიცოცხლის ბოლომდე მართვის მიზნით. გარდა ამისა, ეს დოკუმენტი აღწერს შექმნის პროცესს, ხელახლაviewთეთრი ქაღალდების დამტკიცება.

სპეციფიკაციების შემუშავების პროცესში არსებობს განსხვავებები ახალი სპეციფიკაციების შემუშავებასა და არსებული სპეციფიკაციების გაუმჯობესებას შორის ამ ამოცანების მოცულობაში არსებული განსხვავებებით; ამ განსხვავებებში ხაზგასმულია ამ დოკუმენტში.

სპეციფიკაციის შემუშავების პროცესი მოიცავს:

• მოთხოვნების ფაზა (აღწერილია მე -3 ნაწილში) ფუნქციური მოთხოვნების დასადგენად
• განვითარების ფაზა (აღწერილია მე -4 ნაწილში) განსახორციელებლად და ხელახლაview სპეციფიკაციები
• ვალიდაციის ფაზა (აღწერილია მე -5 ნაწილში) სპეციფიკაციების დასადასტურებლად თავსებადი პროტოტიპის (IOP) ტესტირების საშუალებით
• შვილად აყვანის / დამტკიცების ფაზა (აღწერილია მე -6 ნაწილში) სპეციფიკაციების წარსადგენად Bluetooth SIG– ის დირექტორთა საბჭოსთვის (საბჭოსთვის) მიღებისთვის / დამტკიცებისთვის

სპეციფიკაციის Errata პროცესის დოკუმენტი (EPD) [3] აღწერს პროცესს შეთავაზებისა და ხელახლაviewდაზუსტება errata და მათი დამტკიცება Errata შესწორებების სახით (როგორც განსაზღვრულია შინაგანაწესით [2]) მიღებული სპეციფიკაციების შესაბამისად. თუ სხვაგვარად არ არის მითითებული, ამ SMPD– ში ყველა მითითება შეცდომებზე ნიშნავს სპეციფიკურ შეცდომებს.

1.1 პრეცედენტი

Bluetooth SIG, Inc.- ის შინაგანაწესი და წესდება და წევრობის ხელშეკრულებები [2] უპირატესობას ანიჭებს ამ დოკუმენტებსა და SMPD- ში არსებულ წინააღმდეგობრივ შინაარსს. ამ დოკუმენტში არსებული ყველაფრის მიუხედავად, საბჭო იტოვებს საბოლოო შეხედულებისამებრ და უფლებამოსილებას მიიღოს ზომები და მიიღოს გადაწყვეტილებები მაშინაც კი, თუ ამ მოქმედებებსა და გადაწყვეტილებებს არ მოყვება ან არ ეწინააღმდეგება რაიმე ამ დოკუმენტში, და ამ დოკუმენტში არაფერი ზღუდავს ან არ ზღუდავს საბჭოს დამოუკიდებელ უფლებამოსილებას. და შეხედულებისამებრ.

თუ SMPD- ში მოცემულ ტექსტს შორის რაიმე წინააღმდეგობაა, ტექსტს უპირატესობა ენიჭება.

1.2 მითითებული ჯგუფები და კომიტეტები

ამ დოკუმენტში მითითებულია ჯგუფების შემდეგი ტიპები: სასწავლო ჯგუფები (SG), ექსპერტთა ჯგუფები (EG) და სამუშაო ჯგუფები (WG). სამუშაო ჯგუფს ასევე შეიძლება ჰქონდეს ქვეჯგუფი, რომელიც ანგარიშს უწევს სამუშაო ჯგუფს. ანალოგიურად, ამ დოკუმენტში მითითებულია შემდეგი ტიპის კომიტეტები: Bluetooth Architectural Review დაფა (BARB), Bluetooth ტესტი და თავსებადობა (BTI) და Bluetooth კვალიფიკაცია 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– ის ძირითადი სპეციფიკაციაზე. სპეციფიკაციები, როგორიცაა ტრადიციული პროfileს; ტრადიციული პროტოკოლები; და GATT– ზე დაფუძნებული პროfiles, GATT– ზე დაფუძნებული სერვისები და GATT– ზე დაფუძნებული პროტოკოლები ყველა დამოკიდებულია ძირითადი მახასიათებლების მახასიათებლებზე. სხვა სპეციფიკაციები, როგორიცაა Mesh Model სპეციფიკაციები, დამოკიდებულია Mesh Pro– ზეfile სპეციფიკაცია, რომელიც თავის მხრივ დამოკიდებულია ძირითად სპეციფიკაციაზე.

Core Specification Supplement (CSS) დაზუსტება განსაზღვრავს მონაცემთა ტიპებს, მონაცემთა ფორმატებს და საერთო პროსfile და სერვისის შეცდომის კოდები, რომლებიც გამოიყენება ძირითადი სპეციფიკაციებით და სხვა სპეციფიკაციებით და თავისთავად არ განსაზღვრავს რაიმე ქცევას.

GATT სპეციფიკაციის დანართი (GSS) სპეციფიკაცია განსაზღვრავს დამახასიათებელ და აღწერილ ფორმატებს, რომლებიც გამოიყენება Profiles და მომსახურება და თავად არ განსაზღვრავს რაიმე ქცევას.
Mesh Device Properties (MDP) სპეციფიკაცია განსაზღვრავს mesh თვისებებს, რომლებიც გამოიყენება Mesh Pro– ს მიერfile და Mesh Model სპეციფიკაციები და თავად არ განსაზღვრავს რაიმე ქცევას.

 

2. დასრულდაview

ეს განყოფილება უზრუნველყოფს ზედსview პროცესების შესახებ და არ არის გამიზნული ყველა დეტალის შეტანა.

დიაგრამა 2.1 გვიჩვენებს ექვსი ძირითადი ფაზის შემადგენლობას სპეციფიკაციების მართვის პროცესში.

პირველი ოთხი ეტაპი ხდება სპეციფიკაციის შემუშავების პროცესში და მოიცავს მოთხოვნების ფაზას (განყოფილება 3), განვითარების ფაზას (განყოფილებას 4), დამტკიცების ფაზას (განყოფილებას 5) და მიღებას / დამტკიცების ფაზას (განყოფილება 6). მას მოსდევს შვილად აყვანის შემდგომი ორი ეტაპი: სპეციფიკაციის შენარჩუნების ფაზა (ნაწილი 7) და სპეციფიკაციის სიცოცხლის ბოლომდე ეტაპი (ნაწილი 8).

დიაგრამა 2.2 ასახავს დაზუსტების შემუშავების პროცესში მოცემული ოთხი ფაზის დეტალებს. ნაცრისფერი ყუთები მიუთითებს ძირითადი მიღებებით თითოეული ფაზისთვის. ნარინჯისფერი ყუთები აჯამებს პროცესის ეტაპებს.

მოთხოვნების ფაზაში (აღწერილია მე -3 ნაწილში), ახალი სამუშაოს დაწყების წინადადება (ახალი სამუშაო წინადადება (NWP)) იწყებს სპეციფიკაციის შემუშავების პროცესს მომხმარებლის სცენარების განსაზღვრით, რომლებიც ჩართული იქნება ახალი სამუშაოს გაგრძელების შემთხვევაში. NWP დამტკიცების შემთხვევაში, დანიშნული ჯგუფი ქმნის ფუნქციონალური მოთხოვნების დოკუმენტს (FRD). მას შემდეგ, რაც FRD დამტკიცდება და მიენიჭება ჯგუფს, იწყება განვითარების ფაზა.

განვითარების ფაზის დროს (აღწერილია მე -4 ნაწილში), სპეციფიკაციის განვითარება პროგრესირებს s თანმიმდევრობითtages (0.5/DIPD- დან 0.9/CR) დამთავრდა სპეციფიკაციის სრული პროექტით. 0.9/CR სპეციფიკაცია ხელმისაწვდომია ყველა წევრისთვის, შემდეგ წარედგინება საბჭოს, რომელიც სპეციფიკაციას განიხილავს დასამტკიცებლად. დამტკიცების შემდეგ იწყება ვალიდაციის ეტაპი.

სპეციფიკაციების შემუშავების ვალიდაციის ფაზის განმავლობაში (აღწერილია მე –5 ნაწილში), საბჭოს მიერ დამტკიცებული 0.9/CR სპეციფიკაცია ხელმისაწვდომია ყველა წევრისათვის ხელახლაview და შეამოწმეთ და წევრი Review დაწყებულია დადასტურება ხდება ურთიერთთანამშრომლობის (IOP) ტესტირების საშუალებით წევრების მიერ აგებულ პროტოტიპებს შორის. მას შემდეგ, რაც IOP ტესტირება დასრულდება (თუ საჭიროა სპეციფიკაციისთვის) და BARB დაამტკიცებს IOP ტესტის ანგარიშს, მაშინ იწყება შვილად აყვანის/დამტკიცების ეტაპი.

მიღება / დამტკიცების ფაზის განმავლობაში (აღწერილია მე -6 ნაწილში) დაზუსტებულია სპეციფიკაცია და მასთან დაკავშირებული ტესტის დოკუმენტები; მიიღება BARB, BQRB და BTI დამტკიცებები; საბოლოო დაზუსტების პაკეტი წარედგინება საბჭოს, რომელიც განიხილავს სპეციფიკაციების მიღებას (ანუ საბოლოო დამტკიცებას).

შეიძლება საჭირო გახდეს სპეციფიკაციის დაბრუნება წინა ფაზაზეtagთუ მნიშვნელოვანი ცვლილებები მოხდება. ზოგიერთ შემთხვევაში, ასევე შესაძლებელია იყოს ფაზის ნაწილის მიტოვება, როგორც ეს აღწერილია 4.4 ნაწილში.

სპეციფიკაციის ტექნიკური ფაზა (აღწერილია მე -7 ნაწილში) იწყება საბჭოს მიერ სპეციფიკაციის მიღების შემდეგ. ამ ფაზის განმავლობაში მიიღება მიღებულ სპეციფიკაციაში აღმოჩენილი პოტენციური შეცდომების შესახებ ინფორმაცია და ფასდება და (საჭიროების შემთხვევაში) ხდება დაზუსტებების შეცდომები დაზუსტებებში. სპეციფიკაციის ტექნიკური ფაზა გრძელდება მანამ, სანამ სპეციფიკაცია არ ცდება ან ამოღებულია (იხილეთ შემდეგი პუნქტის სპეციფიკაციის სიცოცხლის ბოლო ფაზა).

სიცოცხლის ბოლოს ფაზის სპეციფიკაცია (აღწერილია მე -8 ნაწილში) აღწერს მიღებული სპეციფიკაციების ცვეთისა და ამოღების პროცესს.

 

3. მოთხოვნების ფაზა

მოთხოვნების ფაზა იწყება ან NWP (რომელიც აცხადებს მუშაობის დაწყების სურვილს ერთ ან რამდენიმე მომხმარებლის სცენარზე) ან იმის დადგენის შემდეგ, რომ სასურველი ახალი ნამუშევარი უკვე დაფარულია მათი WG წესდებით. თუ WG- ს სურს დაიწყოს ახალი სამუშაო, რომელიც, მისი აზრით, უკვე არის მისი GP ქარტიის ფარგლებში, WG- მ უნდა დაიცვას 3.1 ნაწილში განსაზღვრული პროცესი, რომ უშუალოდ დაიწყოს FRD- ის შემუშავება. ყველა სხვა სამუშაო საგნისთვის, სამუშაო ჯგუფმა უნდა დაიცვას 3.2 ნაწილში განსაზღვრული პროცესი. FRD განსაზღვრავს ფუნქციური მოთხოვნების ფარგლებს, რომლებიც გამოიყენება განვითარების ფაზაში სპეციფიკაციების შესაქმნელად. მოთხოვნების ეტაპი ასახულია ნახაზზე 3.1.

3.1 ახალი სამუშაო, რომელიც მოიცავს სამუშაო ჯგუფის წესდებას

როდესაც WG- ს სურს დაიწყოს ახალი სამუშაო და გონივრულად თვლის, რომ მისი ფუნქციონალური დამატება უკვე შედის მისი WG ქარტიის ფარგლებში, WG- მ შეიძლება დაიწყოს მუშაობა FRD- ზე, იმ პირობით, რომ ისინი დაუყოვნებლივ აცნობებენ BARB- ს. სამუშაო ჯგუფი BARB– სთვის გაგზავნილ შეტყობინებაში შეიტანს შემოთავაზებული ახალი სამუშაოს აღწერას და სამუშაო ჯგუფის წესდების ასლს, რომელშიც გამოკვეთილი იქნება ენა, რაც მათ უფლებას მისცემს დაიწყონ ახალი სამუშაო.

თუ BARB უარყოფს სამუშაო ჯგუფის ანალიზს, ჯგუფმა უნდა შეწყვიტოს მუშაობა FRD– ზე და განაგრძოს NWP პროცესი, რომელიც აღწერილია 3.2 ნაწილში. თუ BARB დაამტკიცებს სამუშაო ჯგუფის ანალიზს, სამუშაო ჯგუფი დაუყოვნებლივ შეატყობინებს BSTS- ს (ელექტრონული ფოსტის საშუალებით specification.manager@bluetooth.com) და BSTS დაამატებს საკითხს საბჭოს შემდეგ დღის წესრიგში

სამუშაო ჯგუფი BSTS– სთვის შეტყობინებაში შეიტანს იმავე ინფორმაციას, რომელიც BARB– ს მიაწოდა. თუ საბჭო უარყოფს სამუშაო ჯგუფის ანალიზს, ჯგუფმა უნდა შეწყვიტოს მუშაობა FRD– ზე და განაგრძოს NWP პროცესი, რომელიც აღწერილია 3.2 ნაწილში. თუ საბჭო დაამტკიცებს სამუშაო ჯგუფის ანალიზს, ჯგუფმა შეიძლება გააგრძელოს მუშაობა FRD– ზე, როგორც ეს აღწერილია 3.3 ნაწილში.

3.2 ახალი სამუშაო წინადადება (NWP)

ნებისმიერ წევრს, WG, SG ან EG– ს შეუძლია შექმნას და წარადგინოს NWP (Bluetooth SIG– ის საშუალებით webსაიტი [10]). NWP უნდა შეიცავდეს, სულ მცირე, ინფორმაციას შემდეგში, ოფიციალური შაბლონის გამოყენებით [8]:

• მომხმარებლის სცენარები
• წევრების ვალდებულება განავითაროს FRD და რა სფეროში (ებ) ი (მაგ., კონტრიბუტორი, ავტორი, რეviewჰო, პროტოტიპი)
• FRD სამუშაოების შემოთავაზებული ხელმძღვანელობა
• შემოთავაზებული ჯგუფური დავალება FRD სამუშაოსთვის
• პირველადი ავტორების ელ.ფოსტის მისამართი

შენიშვნა: NWP პროცესის შესახებ მითითებები ხელმისაწვდომია Bluetooth SIG– ზე webსაიტი [10].

NST– ის განვითარების პროცესში BSTS შეასრულებს შემდეგ დავალებებს:

• მიაწოდეთ ავტორ (ებ) ს მიღების დადასტურება (როგორც წესი, მიღებიდან შვიდი კალენდარული დღის განმავლობაში) და აღწერეთ შემდეგი ნაბიჯები.
• საჭიროების შემთხვევაში, იმუშავეთ ავტორთან (ავტორებთან) ისე, რომ NWP იყოს მკაფიო და სრული. ამას შეიძლება დასჭირდეს NWP- ის რამდენიმე გამეორება.
• თუ NWP შეიცავს განცხადებებს მიღებულ Bluetooth სპეციფიკაციებში შეცდომების შესახებ, იმუშავეთ ავტორთან file შეცდომების სისტემაში შესვლა.
• თუ შენიშნა, რომ NWP პოტენციურად ახდენს სამუშაოების დუბლირებას, რომელიც უკვე მიმდინარეობს ან უკვე დასრულებულია, აცნობეთ სხვა ნამუშევრის ავტორ (ებ) ს მათი შესაფასებლად.
• განათავსეთ NWP NWP– ში webსაიტი ხელმისაწვდომია ყველა წევრისთვის.
• აცნობეთ ყველა წევრს, რომ NWP ხელმისაწვდომია ხელახლაview და არის თუ არა საჭირო დამატებითი წევრების ვალდებულება FRD– ის შემუშავებისათვის.

წევრებს შეუძლიათ დაუკავშირდნენ ავტორ (ავტორებს) კითხვების დასასმელად ან NWP– ს შესახებ გამოხმაურება.

მინიმუმ სამმა წევრმა კომპანიამ უნდა აიღოს ვალდებულება, რომ მონაწილეობა მიიღოს მიღებული FRD– ის დასრულებაში, რომ NWP გახდეს საბჭოს დამტკიცების კანდიდატი, და მინიმუმ ერთი წევრი კომპანია უნდა იყოს ასოცირებული ან პრომოუტერის წევრი. საბჭოს მიერ NWP– ის დამტკიცების შემდეგ, საბჭო გადასცემს NWP– ს არსებულ ყველა წევრ WG ქვეჯგუფს ან SG– ს, რათა იმუშაოს FRD– ზე (აღწერილია ნაწილში 3.3). თუ შესაბამისი WG ქვეჯგუფი ან SG არ არსებობს, ის შეიძლება შეიქმნას.

NWP- ებისთვის, რომლებსაც აქვთ საკმარისი წევრების ვალდებულება, BSTS შეასრულებს შემდეგ დამატებით დავალებებს:

• NWP– ს დამტკიცების წინადადებით, სულ მცირე, 13 დღით ადრე, შეატყობინეთ BARB– ს და ჯგუფს, რომელზეც რეკომენდებულია NWP– ის დანიშვნა, NWP– ს დამტკიცების შესახებ. ეს კეთდება იმისთვის, რომ უზრუნველყოს უკუკავშირი ისეთ სფეროებში, როგორიცაა შემოთავაზებული ჯგუფი, არის თუ არა NWP უკვე არსებული სამუშაოები და ა.შ.
• შეავსეთ NWP გამგეობაში.

1. თუ NWP წარდგენილია წევრების მიერ, რომლებიც არ არიან ასოცირებულ ჯგუფთან, მოაწყვეთ, რომ ერთ-ერთმა წევრმა წარუდგინოს NWP საბჭოს.
2. თუ NWP წარდგენილია ჯგუფის მიერ, შეთანხმდით, რომ ჯგუფის თავმჯდომარემ NWP წარუდგინოს საბჭოს.
3. საბჭოს სხდომაზე მოიწვიეთ BARB თავმჯდომარე და ჯგუფის თავმჯდომარეები, რომლებსაც ურჩევენ NWP.
4. თუ NWP დამტკიცებულია და დანიშნულია საბჭოს მიერ, აცნობეთ ჯგუფს, რომელიც მას ენიჭება; ავტორები); NWP– ში განსაზღვრული წევრები, რომლებიც ვალდებულნი არიან შეიმუშაონ შესაბამისი FRD; და თუ NWP შემოთავაზებულია ჯგუფის მიერ, შედეგის ჯგუფი და შემდეგი ნაბიჯები.

მას შემდეგ, რაც NWP დამტკიცდება საბჭოს მიერ, განაახლეთ სტატუსი NWP– ზე webსაიტი.

ნებისმიერი NWP შეიძლება უარყოს საბჭომ თავისი შეხედულებისამებრ, მაგampთუმცა, რესურსების შეზღუდვის გამო, თუ სამუშაო უკვე სრულად არის დასრულებული, მუშაობა არ შედის Bluetooth SIG– ის მარეგულირებელი დოკუმენტების ფარგლებს გარეთ (მაგ., პროგრამირების პროგრამირების ინტერფეისი (API)) [2], ან თუ შემოთავაზებული სამუშაო უნდა იყოს fileდ როგორც შეცდომა. თუ NWP უარყოფილია, BSTS შეატყობინებს ავტორს, წევრებს, რომლებიც მითითებულია NWP– ში, როგორც ვალდებულნი შეიმუშაონ შესაბამისი FRD და, თუ NWP შემოთავაზებულია ჯგუფის მიერ, ჯგუფს. შეტყობინება შეიცავს უარის თქმის ნებისმიერ მიზეზს. ავტორს (წევრებს), ერთგულ წევრებს ან ჯგუფს შეუძლიათ მოითხოვონ დრო საბჭოს დღის წესრიგში, რომ გაასაჩივრონ უარყოფა.

თუ წევრს ან ჯგუფს სურს შემოგთავაზოთ მიღებული მახასიათებლის მახასიათებლის ამოღება, ჯგუფმა ან წევრმა უნდა მოამზადოს NWP. NWP უნდა შეიცავდეს გავლენის ანალიზს, რომელიც ექნება მოცილებას უკანა თავსებადობასა და თავსებადობაზე, სატესტო შემთხვევებზე ზემოქმედების ანალიზის ჩათვლით.

NSS არ არის საჭირო CSS, GSS ან MDP სპეციფიკაციების გაუმჯობესებისთვის: ჩვეულებრივ, CSS, GSS ან MDP სპეციფიკაციების განახლებები ხდება სხვა სპეციფიკაციების განახლებებისგან, რომლებსაც აქვთ საკუთარი NWP.

3.3 ფუნქციური მოთხოვნების დოკუმენტი (FRD)

FRD განსაზღვრავს ფუნქციურ მოთხოვნებს მომხმარებლის სცენარების დასაწყებად. FRD უნდა შეიცავდეს ინფორმაციას მინიმუმ შემდეგზე, [8] მოცემული ოფიციალური შაბლონის გამოყენებით:

• მომხმარებლის სცენარები
• ფუნქციური მოთხოვნები მომხმარებლის სცენარების საფუძველზე
• წევრის ვალდებულება შეიმუშაოს მიღებული სპეციფიკა (ებ) ი
• წევრების მიერ არჩევითი პროტოტიპის მხარდაჭერა მოსალოდნელი როლების შესრულებაში
• რეკომენდაციას უწევს ჯგუფს, რომ შეიმუშაოს სპეციფიკაციები

FRD განვითარება

FRD- ს ქმნის ყველა წევრ WG ქვეჯგუფს ან SG წევრებს BSTS- ის სარედაქციო მხარდაჭერით. ნებისმიერ წევრს, რომელიც დაინტერესებულია FRD– ის განვითარებაში მონაწილეობით, შეუძლია შეუერთდეს ჯგუფს.

FRD– მ უნდა მიუთითოს მინიმუმ ორი ასოციაციის ან პრომოუტერის დონის წევრი კომპანიისგან, რომ მიიღონ მონაწილეობა მიღებული სპეციფიკაციების შემუშავებაში. WG ან SG, რომლებიც წარმოადგენენ FRD– ს, უნდა შეეცადონ ფართო მხარდაჭერა მიიღონ ჯგუფის წევრი კომპანიებისგან, რომლებიც წარმოადგენენ FRD– ში განსაზღვრულ მიზნობრივ ინდუსტრიულ სეგმენტს.

FRD– ში შემოთავაზებული ახალი ფუნქციონირება უნდა იყოს მხარდაჭერილი რაც შეიძლება მეტ ტრანსპორტზე და არსებულ მოწყობილობაზე. ეს მოიცავს, მაგალითადample, GATT– ზე დაფუძნებული პროfileმომსახურება და მომსახურება როგორც ძირითადი ტარიფის/მონაცემთა გაფართოებული განაკვეთის (BR/EDR), ასევე Bluetooth დაბალი ენერგიის (LE) ტრანსპორტზე. თუ ახალ ფუნქციონირებას არ გააჩნია საკმარისი წევრების მხარდაჭერა ტრანსპორტისათვის, მაგampიმის გამო, რომ წევრების ვალდებულება არ არის განსაზღვრული ტრანსპორტის გამოყენება ან პოტენციურად არასაკმარისი რაოდენობის IOP სატესტო პლატფორმები ერთი ან მეტი როლისთვის, ამ ტრანსპორტის მხარდაჭერა შეიძლება გამოირიცხოს FRD– დან.

თუ სხვაგვარად არ არის გამართლებული, ახალი ფუნქციონირება, პროfileდა სერვისები უნდა შეესაბამებოდეს 3.3.2 პუნქტში აღწერილ უკანა თავსებადობის მოთხოვნებს.

WG ან SG უნდა წარუდგინოს FRD BARB– ს ხელახლაview და მოწონება. ბარბმა უნდა დაამტკიცოს ან უარყოს FRD მისი საინჟინრო გადაწყვეტილების საფუძველზე. BARB– ის მიერ დამტკიცების შემთხვევაში, FRD ხელმისაწვდომი იქნება ყველა წევრისთვის და მისი ხელმისაწვდომობის შესახებ შეტყობინება გაცემული იქნება BSTS– ის მიერ.

FRD არ არის საჭირო CSS, GSS ან MDP სპეციფიკაციების გაუმჯობესებისათვის: როგორც წესი, CSS, GSS ან MDP სპეციფიკაციების განახლებები გამოწვეულია სხვა სპეციფიკაციების განახლებებით, რომლებსაც აქვთ საკუთარი FRD.

ჩამორჩენილი თავსებადობის მოთხოვნები

უკანა თავსებადობა BR / EDR– სთვის

BR / EDR ოპერაციისთვის, ჩამორჩენილი თავსებადობის მოთხოვნა განისაზღვრება როგორც Bluetooth / Core Specification v1.1 და უფრო ახალი ვერსიის BR / EDR ნაწილთან ურთიერთქმედება.

ჩამორჩენილი თავსებადი Bluetooth დაბალი ენერგიისთვის

LE ოპერაციისთვის, ჩამორჩენილი თავსებადობის მოთხოვნა განისაზღვრება, როგორც Bluetooth Core Specification v4.0 და უფრო ახალი ვერსიის LE ნაწილთან ურთიერთქმედება.

უკუ შესაბამისობა სპეციფიკაციებისათვის, გარდა ძირითადი მახასიათებლებისა

Bluetooth– ის ძირითადი სპეციფიკაციის გარდა სხვა სპეციფიკაციებისთვის, მოცემული ვერსიის უკანა თავსებადობა უნდა შენარჩუნდეს ყველა ადრინდელ ვერსიასთან, რომლებსაც აქვთ ერთი და იგივე ძირითადი ვერსიის ნომერი. ყოფილიample, 1.3 ვერსია უნდა იყოს თავსებადი 1.2, 1.1 და 1.0 ვერსიებთან, მაგრამ ვერსია 2.0 შეიძლება არ იყოს თავსებადი 1.0, 1.1, 1.2 და 1.3 ვერსიებთან. გაითვალისწინეთ, რომ ძირითადი სპეციფიკაციის ძირითადი ვერსიის ნომრის გაზრდა არ გულისხმობს წინა ვერსიებთან უკუსვლის თავსებადობის ნაკლებობას.

გათავისუფლება ჩამორჩენილი თავსებადობის მოთხოვნებისგან

WG ან SG– ს შეუძლია შესთავაზოს კონკრეტული ფუნქციონირების განთავისუფლება უკუთავსებადობის მოთხოვნისგან, თუ დასაბუთება არსებობს. ყოფილიampმაგალითად, თუ ნაჩვენებია, რომ ფუნქციონალურობას აქვს დაბალი ბაზრის მიღების მაჩვენებლები ან, ურთიერთთანამშრომლობის საკითხების გამო, უმჯობესია ამოიღონ ან შეცვალონ ფუნქციონირება, ვიდრე შეცვალონ ფუნქციონირება. WG ან SG უნდა შეიცავდეს FRD– ში ჩამორჩენილი თავსებადობის გამონაკლისს, რომელიც დამტკიცებულია BARB– ის მიერ FRD– ის დამტკიცების შემდეგ. BARB– ით დამტკიცებული ნებისმიერი გამონაკლისი წარედგინება საბჭოს დასამტკიცებლად 0.9/CR S– ზეtage.

3.4 სამუშაო ჯგუფის წესდება

როდესაც BARB ამტკიცებს FRD- ს, რომელიც შესთავაზა მიენიჭოს არსებულ WG- ს, ამ ჯგუფმა უნდა მოამზადოს მისი წესდების განახლების პროექტი, რათა ახალი ფუნქციონირება დაამატოს მოქმედებას (გარდა იმ შემთხვევისა, როდესაც საბჭომ ადრე დაამტკიცა WG- ს ანალიზი, რომ WG წესდების განახლება ხდება არ არის საჭირო). ამასთან, როდესაც BARB დაამტკიცებს FRD– ს, რომელიც შესთავაზებენ ახალ ჯგუფს, BARB– მა და წევრებმა, რომლებიც დაინტერესებულნი არიან FRD– ით აღწერილი ფუნქციონირებით, უნდა მოამზადონ წესდების პროექტი ახალი WG– სთვის, ახალი ფუნქციონირებით, რომლებიც წესდების სფეროში შედის. .

მას შემდეგ რაც მომზადდება ახალი ან განახლებული WG ქარტია, ის უნდა წარედგინოს BARB– ს ხელახლაview და მოწონება. მას შემდეგ რაც BARB დაამტკიცებს წესდებას, ახალი ან განახლებული WG წესდების პროექტი წარედგინება საბჭოს დასამტკიცებლად.

საბჭოს წესდების დამტკიცებისთანავე, სამუშაო ჯგუფმა, რომელსაც საბჭომ მიანიჭა სპეციფიკაციების შემუშავების სამუშაო, მჭიდროდ უნდა ითანამშრომლოს ჯგუფთან, რომელმაც მოამზადა FRD, თუ საჭიროა რაიმე ახალი განახლება ან განმარტება ამ FRD– ს შესახებ. თუ განვითარების ფაზის განმავლობაში საჭიროა FRD განახლება, 3.3 და ამ ნაწილში აღწერილი პროცესები უნდა დაიცვას; ამასთან, სპეციფიკაციის შემუშავება შეიძლება მოხდეს FRD და WG ქარტიის განახლებების პარალელურად.

3.5 მოთხოვნები ფაზის გასასვლელი მოთხოვნები

მოთხოვნების ფაზა დასრულებულია და განვითარების ფაზა იწყება, როდესაც სამუშაო ჯგუფის წესდება FRD– სთვის აუცილებელი მასშტაბის დამტკიცებით ან დამტკიცებულია საბჭოს მიერ და შესრულდება შემდეგი მოთხოვნები:

• NWP ან დამტკიცებულია საბჭოს მიერ, ან საბჭო შეთანხმებულია, რომ NWP არ არის საჭირო.
• FRD და შესაბამისი WG ქარტია დამტკიცებულია BARB– ის მიერ.

 

4. განვითარების ფაზა

განვითარების ფაზის განმავლობაში, მინიჭებული სამუშაო ჯგუფები ქმნიან ახალ სპეციფიკაციას და / ან აძლიერებენ არსებულ სპეციფიკაციას. FRD განსაზღვრავს ახალი ან გაუმჯობესებული Bluetooth სპეციფიკაციის მოთხოვნებს. დაუშვებელია რაიმე ფუნქციონირება სპეციფიკაციაში, რომელიც გონივრულად არ უკავშირდება FRD– ის მოთხოვნებს. მიზანი არის 0.9 / CR სპეციფიკაციის შექმნა, რომელიც მზადაა ვალიდაციის ფაზისთვის (აღწერილია მე -5 ნაწილში) განვითარების ფაზის დასრულების შემდეგ.
განვითარების ფაზის დროს, სპეციფიკაცია (ან სპეციფიკაციის გაუმჯობესება) წინ უსწრებს სამ სtagეს.

ახალი სპეციფიკაციისთვის სამი სtagეს არის:

• 0.5 სtage
• 0.7 სtage
• 0.9 სtage

სპეციფიკაციის გასაუმჯობესებლად, სამი სtagეს არის:

• გაუმჯობესების შეთავაზების დოკუმენტის პროექტი (DIPD) სtage
• საბოლოო გაუმჯობესების წინადადების დოკუმენტი (FIPD) სtage
• ცვლილების მოთხოვნა (CR) Stage

თითოეული სtage აღწერილია შემდგომ ქვეგანყოფილებებში. ქვემოთ მოყვანილი სურათი 4.1 ასახავს სხვადასხვა დოკუმენტს, რომელსაც სამუშაო ჯგუფი მოამზადებს თითოეულ შეხვედრაზეtage.

სურათი 4.1: დასრულდაview სპეციფიკაციის სtagეს ხდება განვითარების ფაზაში

BARB– ის როლი სპეციფიკაციების შემუშავების პროცესში არის სამუშაო ჯგუფებისათვის რჩევების და ტექნიკური დახმარების გაწევა. სამუშაო ჯგუფებს, ნებისმიერ დროს, შეუძლიათ თხოვნით მიმართონ BARB– ს ტექნიკური რჩევის შესახებ სპეციფიკაციების შემუშავებასთან და არქიტექტურულ კონცეფციებთან დაკავშირებით, რომლებიც გამოყენებული იქნება სპეციფიკაციაში. სამუშაო ჯგუფებს განსაკუთრებით ურჩევენ BARB– ისგან ადრეული უკუკავშირის გამოთხოვას იმ მახასიათებლებისთვის, რომლებსაც უფრო რთული არქიტექტურული მოსაზრებები აქვთ.

4.1 0.5/DIPD სtage

0.5/DIPD ს დროსtagე, WG შეიმუშავებს შემდეგს ოფიციალური შაბლონების გამოყენებით [8]:

1. ახალი სპეციფიკაციისთვის, 0.5 სპეციფიკაციის პროექტი, რომელიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:

• არქიტექტურა FRD- ში მითითებული მოთხოვნების დასაფარავად
• პროტოკოლებისთვის, მომსახურების წვდომის წერტილები განისაზღვრება
• მომსახურების, დაუცველი მონაცემებისა და ქცევისთვის
• პროfiles, გამოვლენილი პროტოკოლები და განსაზღვრული ფუნქციონირება

2. სპეციფიკაციის გაუმჯობესების მიზნით, DIPD პროექტი, რომელიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:

• ფონი: სამუშაოს მოცულობა, სამუშაოს წარმართვის მიზნები და როგორ ჯდება ამ კონკრეტული წინადადება
• დასრულდაview წინადადება: DIPD– ს მიერ მოწოდებული გაფართოებული ფუნქციონირების (დამატებითი მოქნილობა, გაუმჯობესებული შესრულება და ა.შ.) რეზიუმე, რომელშიც მოცემულია მკაფიო აღწერა იმის შესახებ, თუ როგორ ჯდება ახალი ფუნქციონირება ახლანდელი სპეციფიკაციის ვერსიაში. თუ სამუშაო ჯგუფმა შეაფასა მრავალი წინადადება, ეს წინადადებები უნდა შეიცავდეს, რათა BARB– ს მიეცეს შესაძლებლობა დაადგინოს, გაკეთდა თუ არა საკმარისი სათანადო გულმოდგინება სასურველი წინადადების არჩევაში.
• მოთხოვნების გაშუქება: წინადადებაში მოცემული ფუნქციური მოთხოვნების დაფარვის შეჯამება სისტემის შესაბამის მოთხოვნებთან და ასოცირებულ FRD– ში მოცემული გამოყენების სცენარების მითითებით
• Პრობლემის განსაზღვრება: წინადადება (ებ) ით გადაჭრილი პრობლემების განცხადება
• შერჩევის კრიტერიუმები: განცხადება შერჩევის / შესრულების კრიტერიუმების შესახებ ასოცირებული შეფასების მეტრიკიდან, რომელიც ხელმძღვანელობდა შერჩევის პროცესს
• არჩევანის დასაბუთება: შეფასების შეფასების მეტრიკის შემოწმება, რომელიც ამართლებს არჩევანს წინადადებებს შორის და გამოავლენს ურთიერთსაწინააღმდეგო ურთიერთობებს
• აღწერა: ფუნქციონალური და გაფართოებული ოქმების აღწერა. ამ განყოფილებას შეუძლია მოერგოს სხვადასხვა საჭიროებებს შესაბამისი ქვე-სექციების დამატებით.

3. ტესტის სტრატეგია: Bluetooth– ის საკვალიფიკაციო პროგრამის ნაწილის შემოწმება (ან შემოწმება) შემოთავაზებული ფუნქციონირების აღწერა და მისი შემოწმების ფუნქციონალური მახასიათებლების შემოწმება (მაგ. მოლოდინი ქვედა ტესტერზე ან ზემო ტესტერზე) და თუ ტესტები მიეკუთვნება როგორც შესაბამისობის ან თავსებადობის ტესტებს, ან ორივე მათგანის კომბინაციას). ეს შეიძლება იყოს ცალკეულ დოკუმენტში ან ცალკეულ განყოფილებაში 0.5/DIPD სპეციფიკაციის ფარგლებში. ტესტის სტრატეგიაში გამოსაყენებელი კონვენციები აღწერილია ტესტის სტრატეგიასა და ტერმინოლოგიის დასრულებაშიview დოკუმენტი (TSTO) [5].

დოკუმენტების პირველადი აუდიტორია ამ სtage არის WG წევრები და BARB რომლებიც ხელახლაview არქიტექტურული წინადადებები და მოთხოვნების გაშუქება და BTI ვინც ხელახლაviewარის ტესტის სტრატეგია. უმეტეს შემთხვევაში, დოკუმენტები ამ სtage არ არის გამიზნული ტექსტის შემცველი, რომელიც დაგეგმილია საბოლოო სპეციფიკაციაში შესასვლელად.

BSTS უნდა ხელახლაview ყველა დოკუმენტი Bluetooth- ის შემუშავების სახელმძღვანელოსთან შესაბამისობისათვის [1] და იმ საკითხების იდენტიფიცირება, რომელთა გადაწყვეტაც საჭიროა სამუშაო ჯგუფისათვის. ბარბი უნდა ხელახლაview 0.5/DIPD სპეციფიკაცია. სპეციფიკაციის გასაუმჯობესებლად, BARB ასევე უნდა ხელახლაview DIPD ქვეპუნქტში 3.3.2 აღწერილი ჩამორჩენილი თავსებადობის მოთხოვნებთან შესაბამისობისათვის. BTI უნდა ხელახლაview ტესტის სტრატეგია.

ბარბმა უნდა დაამტკიცოს ან უარყოს 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 სtage გასასვლელი მოთხოვნები

0.5/DIPD Stage არის სრული და 0.7/FIPD Stage იწყება მაშინ, როდესაც დაკმაყოფილებულია გასასვლელი მოთხოვნები:

• BSTS დასრულდა ხელახლაview0.5/DIPD დაზუსტება და ტესტირების სტრატეგია.
• BARB– მა დაამტკიცა 0.5 / DIPD სპეციფიკაცია.
• BTI– მ დაასრულა თავისი ხელახალი მუშაობაview ტესტის სტრატეგიის.
• BSTS– მ დაამტკიცა დამტკიცებული 0.5 / DIPD სპეციფიკაცია ასოცირებული და პრომოუტერის ყველა წევრისთვის.

4.2 0.7/FIPD სtage

დროს 0.7/FIPD სtagე, WG შეიმუშავებს შემდეგს ოფიციალური შაბლონების გამოყენებით [8]:

1. ახალი სპეციფიკაციისთვის, 0.7 სპეციფიკაციის პროექტი, რომელიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:

• ყველა ცვლილების აღწერა, რომელიც განხორციელდა BARB– ის მიერ დამტკიცებული 0.5 – ის შემდეგ, მათ შორის ახალი ან შეცვლილი წინადადებები, შერჩევის კრიტერიუმები და არჩევანის დასაბუთება. ცვლილებები უნდა იყოს აღწერილი დეტალების იმავე დონეზე, როგორც ეს საჭიროა 0.5 ს -შიtage.
• ყველა ფუნქციონალური მოთხოვნა FRD– დან.

2. სპეციფიკაციის გაუმჯობესების მიზნით, FIPD პროექტი, რომელიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:

• BARB– ის მიერ დამტკიცებული DIPD– ის შემდგომ განხორციელებული ყველა ცვლილების აღწერა, მათ შორის ახალი ან შეცვლილი წინადადებები, შერჩევის კრიტერიუმები და არჩევანის დასაბუთება. ცვლილებები უნდა იყოს აღწერილი დეტალების იმავე დონეზე, როგორც ეს საჭიროა DIPD S- შიtage.
• საჭიროების შემთხვევაში, შემდგომი განვითარებული ადგილები, რომლებიც აღწერილია 4.1 ნაწილში DIPD– ს შესახებ.
• გაუმჯობესების დასრულებული აღწერა.
• განახლებული არქიტექტურული აღწერა.
• ყველა ფუნქციონალური მოთხოვნა FRD– დან.

3. 0.7 / FIPD ტესტის დოკუმენტები, რომლებიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:

• Test Suite, რომელიც შედგება ტესტის მიზნების ჩამონათვალისაგან, როგორც ეს აღწერილია TSTO- ში [5].
• განხორციელების შესაბამისობის განცხადება (ICS), როგორც აღწერილია TSTO- ში [5].

სპეციფიკაციების დამატების მიზნით, Test Suite და ICS შეიძლება მოწოდებული იქნას როგორც ცალკეული დოკუმენტები, ან დამატებითი განყოფილებები FIPD– ში.

ამ ს -ში წარმოებული დოკუმენტების პირველადი აუდიტორიაtage არის WG წევრები და BARB რომლებიც ხელახლაview ფუნქციის სრული აღწერა ან გაუმჯობესება, ტექსტის ჩათვლით, რომელიც დაგეგმილია საბოლოო სპეციფიკაციაში შესასვლელად. BTI არის აუდიტორიის ხელახალიview სატესტო დოკუმენტების.

BSTS ხელახლაview 0.7/FIPD სპეციფიკაციის ახალი ან შეცვლილი ნაწილები და სატესტო დოკუმენტები Bluetooth- ის შემუშავების სახელმძღვანელოსთან შესაბამისობისთვის, მათ შორის Bluetooth SIG- ის მიერ დადგენილი ენის კონვენციების ჩათვლით. ბარბი ხელახლაview 0.7/FIPD სპეციფიკაცია.

BSTS დაეხმარება WG- ს 0.7 / FIPD ტესტის დოკუმენტების მომზადებაში TSTO- ს შესაბამისად [5].

BTI უნდა ხელახლაview 0.7/FIPD ტესტის დოკუმენტები. სამუშაო ჯგუფმა უნდა მიაწოდოს BTI- ს 0.7/FIPD სპეციფიკაცია, როგორც ხელახალი მითითებაview0.7/FIPD სატესტო დოკუმენტების შემოტანა, რომელსაც BTI ხელახლა მიიღებსview BTI სპეციფიკაციის შესაბამისად Review პროცესის ჩამონათვალი [6].

მას შემდეგ, რაც BARB დაასრულა თავისი ხელახალიview 0.7/FIPD სპეციფიკაციისა და BTI– მ დაასრულა თავისი ხელახალიview 0.7/FIPD ტესტის დოკუმენტებიდან BSTS გახდის რეviewed 0.7/FIPD სპეციფიკაცია ხელმისაწვდომია ყველა ასოცირებული და პრომოუტერის წევრისთვის.

0.7/FIPD სtage არ არის საჭირო CSS, GSS ან MDP სპეციფიკაციების გასაუმჯობესებლად.

0.7/FIPD სtage გასასვლელი მოთხოვნები

0.7/FIPD სtage არის სრული და 0.9/CR Stage იწყება მაშინ, როდესაც დაკმაყოფილებულია გასასვლელი მოთხოვნები:

• BSTS დასრულდა ხელახლაviewშეიტანეთ 0.7/FIPD სპეციფიკაცია და ტესტირების დოკუმენტები.
• ბარბმა დაასრულა ხელახლაview0.7/FIPD სპეციფიკაციის გათვალისწინებით.
• BTI დასრულდა ხელახლაview0.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]:

1. ახალი დაზუსტებისთვის, 0.9 სპეციფიკაციის შინაარსის სრული პროექტი, რომელიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:

• BARB-re– დან განხორციელებული ყველა ცვლილების აღწერაviewed 0.7 სპეციფიკაცია (ან მას შემდეგ, რაც 0.5 სპეციფიკაცია, თუ 0.7 სპეციფიკაცია წარმოებული იყო მოხსნილი), მათ შორის ახალი ან
• შეცვლილი წინადადებები, შერჩევის კრიტერიუმები და არჩევანის დასაბუთება. ცვლილებები უნდა იყოს აღწერილი დეტალების იმავე დონეზე, როგორც ეს საჭიროა 0.5 ს -შიtagე და 0.7 სtage.

2. სპეციფიკაციის გაუმჯობესების მიზნით:

• ან ინტეგრირებული CR, რომელიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:
• BARB-re– დან განხორციელებული ყველა ცვლილების აღწერაviewed FIPD (ან DIPD– ის შემდეგ, თუ FIPD იქნა მოხსნილი) ახალი ან შეცვლილი წინადადებების, შერჩევის კრიტერიუმებისა და არჩევანის დასაბუთების ჩათვლით. ცვლილებები უნდა იყოს აღწერილი დეტალების იმავე დონეზე, როგორც ეს საჭიროა DIPD S- შიtage და FIPD Stage.
• ყველა ცვლილება, რომელიც შესთავაზეს ადრე მიღებულ სპეციფიკაციებს, ცვლილებების თვალის დევნების გამოყენებით.
• ყველა დამტკიცებული ტექნიკური შეცდომა (თითოეული ერატუმის მითითებით, ერტუმის ნომრით), ნაჩვენებია ცვლილების მიკვლევის გამოყენებით, რომელიც ჯერ კიდევ არ არის ჩასმული ადრე მიღებული სპეციფიკაციის ვერსიაში და ზემოქმედების ტექსტი, რომელიც ასოცირდება სპეციფიკაციის გაუმჯობესებასთან; ან სხვაგვარად აისახება IOP ტესტირებაზე.

3. ან შემოკლებული CR, რომელიც მინიმუმ უნდა შეიცავდეს ინფორმაციას შემდეგზე:

• BARB-re– დან განხორციელებული ყველა ცვლილების აღწერაviewed FIPD (ან DIPD– ის შემდეგ, თუ FIPD იქნა მოხსნილი) ახალი ან შეცვლილი წინადადებების, შერჩევის კრიტერიუმებისა და არჩევანის დასაბუთების ჩათვლით. ცვლილებები უნდა იყოს აღწერილი დეტალების იმავე დონეზე, როგორც ეს საჭიროა DIPD S- შიtage და FIPD Stage.
• ყველა ცვლილება, რომელიც შემოთავაზებულია თითოეულ დაზარალებულ მონაკვეთში და სპეციფიკაციის პუნქტში, რომლის შეცვლაც შესთავაზებს CR.
• ყველა დამტკიცებული ტექნიკური შეცდომა (თითოეული შეცდომით, რომელზეც მითითებულია არასწორი რიცხვი), ნაჩვენებია მარკირების გამოყენებით, რომელიც ჯერ კიდევ არ არის ჩასმული ადრე მიღებული სპეციფიკაციის ვერსიაში და ზემოქმედების ტექსტი, რომელიც ასოცირდება სპეციფიკაციის გაუმჯობესებასთან; ან სხვაგვარად აისახება IOP ტესტირებაზე.

4. CSS CR (თუ სპეციფიკაციები მოითხოვს ახალ ჩანაწერებს), რომელიც შეიძლება ჩასმული იყოს სპეციფიკაციის შემოკლებულ CR– ში.
5. GSS CR (თუ დაზუსტება მოითხოვს ახალ მასალას), რომელიც შეიძლება იყოს ჩასმული სპეციფიკაციის შემოკლებულ CR- ში.
6. MDP CR (თუ სპეციფიკაციები მოითხოვს ახალ ჩანაწერებს), რომელიც შეიძლება ჩასმული იყოს სპეციფიკაციის შემოკლებულ CR– ში.
7. 0.9 / CR ტესტის დოკუმენტები, რომლებიც უნდა შეიცავდეს ინფორმაციას, [8] –ში მოცემული ოფიციალური შაბლონის გამოყენებით შემდეგზე:

• 0.9 / CR Test Suite, რომელიც მოიცავს შინაარსის საცდელ შემთხვევებსა და მასთან დაკავშირებულ Test Case Mapping Table (TCMT), როგორც აღწერილია TSTO [5].
• 0.9 / CR ICS, როგორც აღწერილია TSTO- ში [5].
• თუ ტესტების კონფიგურაცია მოითხოვს სპეციფიკურ პარამეტრებს Implementation Under Test (IUT), 0.9 / CR Implementation eXtra ინფორმაცია ტესტირებისთვის (IXIT).
• 0.9 / CR საცდელი შემთხვევის მითითების სია (TCRL) (სურვილისამებრ Core Specification განახლებებისთვის).

8. ტესტის დაფარვის ანალიზი, რომელიც მიუთითებს, თუ რომელი სპეციფიკაციების მოთხოვნები არის ტესტირებული ან არ არის ტესტირებული 0.9 / CR Test Suite- ში (სპეციფიკაციების გაუმჯობესებისთვის, ტესტის დაფარვის ანალიზს მხოლოდ ახლად დამატებული და ზემოქმედების ფუნქციონალი უნდა ჰქონდეს და არა არა-ზემოქმედების არეები ორიგინალი სპეციფიკაცია).
9. IOP ტესტის გეგმა.

სპეციფიკაციების დამატებისთვის, Test Suite, ICS და IXIT შეიძლება მოწოდებული იქნას როგორც ცალკეული დოკუმენტები, ან როგორც დამატებითი განყოფილებები შემოკლებული CR– ში.

უმეტეს შემთხვევაში, ინტეგრირებული ან შემოკლებული CR უნდა ემყარებოდეს სპეციფიკაციის ადრე მიღებულ ვერსიას, მაგრამ ის ასევე შეიძლება ეფუძნებოდეს უახლეს შუალედურ პროექტს. შუალედური მონახაზის უახლესი დაზუსტების ვერსიის ნომერი უნდა იყოს ვერსიის ნომერი, რომელიც ასოცირდება გაყინული დოკუმენტის იმ ვერსიასთან, რომელიც დროთა განმავლობაში არ შეიცვლება. წინააღმდეგ შემთხვევაში, დამატებითი საიდენტიფიკაციო ინფორმაცია (როგორიცაა დოკუმენტის თარიღი და ა URL მუდმივ ადგილას) უნდა იყოს მითითებული კონკრეტული "საბაზისო" ვერსიის დასადგენად. შუალედური მონახაზის გამოყენების შემთხვევაში, უნდა შეიცავდეს ნებისმიერი ცვლილება, რომელიც პირდაპირ არ უკავშირდება CR– ს მოცემულ განყოფილებაში, რომელიც CR– ს ცვლის, მაგრამ არ არის ნაჩვენები მარკირების გამოყენებით. თუ შუალედური მონახაზის შესაბამისი ნაწილი მოგვიანებით განახლდება, CR უნდა განახლდეს, რომ ასახოს შუალედური პროექტის განახლებები.

იდეალურ შემთხვევაში, შემოკლებული CR მასალა ინტეგრირებულია სრული დაზუსტებისა და სრული ტესტის დოკუმენტებში, შესაბამისად, დამტკიცების ფაზამდე, მაგრამ ისინი ასევე შეიძლება ინტეგრირდეს დამტკიცების ფაზის დასაწყისში. თუ მრავალი მახასიათებლის შემუშავება ხდება სპეციფიკაციისთვის (მაგ., ძირითადი სპეციფიკაცია), სასურველია თვისებების ინტეგრირება ერთ პროექტში IOP ტესტირების დასრულების შემდეგ.

BSTS ხელახლაview 0.9/CR სპეციფიკაცია და სატესტო დოკუმენტები Bluetooth შედგენის სახელმძღვანელოსთან შესაბამისობისათვის. შემდეგ ბარბი ხელახლაview 0.9/CR სპეციფიკაცია, რასაც მოჰყვა მოგვიანებით IOP ტესტის გეგმა (როგორც ეს აღწერილია ქვეთავში 4.3.1). მას შემდეგ, რაც 0.9/CR სპეციფიკაცია WG– მ წარადგინა BARB– ში ხელახლაview, BSTS გახდის მისაწვდომს ყველა წევრისთვის ხელახლაview და აცნობოს ყველა წევრს მისი ხელმისაწვდომობის შესახებ. ამ მომენტიდან სპეციფიკაციების შემუშავების პროცესში, BSTS გახდის 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 სპეციფიკაცია მისი საინჟინრო გადაწყვეტილების საფუძველზე და ამ პარაგრაფში აღწერილი ფაქტორების გათვალისწინებით.

BTI ხელახლაview 0.9/CR ტესტის დოკუმენტები ტესტის დაფარვის ანალიზის გათვალისწინებით. BTI– მ უნდა დაამტკიცოს ან უარყოს 0.9/CR ტესტის დოკუმენტები.

მას შემდეგ რაც BARB დაამტკიცებს 0.9/CR სპეციფიკაციას, WG წარუდგენს IOP ტესტის გეგმას BARB– ს ხელახლაview.

BARB– ის მიერ დამტკიცებული 0.9 / CR სპეციფიკაცია წარედგინება საბჭოს, რომ დაადასტუროს IOP ტესტირება და ყველა წევრისთვის 0.9 / CR სპეციფიკაციის გამოქვეყნება.

პოტენციური იურიდიული საკითხების ხაზგასასმელად, სამუშაო ჯგუფებს შეუძლიათ მოითხოვონ დაზუსტებაview Bluetooth SIG– ის იურიდიული კონსულტანტის მიერ (იურიდიული რეview) სანამ სავალდებულო სამართლებრივი რეview ხდება შვილად აყვანის/დამტკიცების ფაზის დროს. თუმცა, სპეციფიკაციის გაუმჯობესების მიზნით, სამართლებრივი რეview უნდა გაკეთდეს ინტეგრირებული CR– ით (განსხვავებით შემოკლებული CR– ისგან) და ეს წინასწარ უნდა დაიგეგმოს რაც შეიძლება ადრე, რათა რესურსები იყოს ხელმისაწვდომი.

IOP ტესტის გეგმა

WG შეიმუშავებს წერილობითი IOP ტესტის გეგმას, რომელიც უნდა აკმაყოფილებდეს ქვემოთ მოცემულ ყველა მოთხოვნას IOP ტესტირების ღონისძიებებზე Validation Phase დროს გამოსაყენებლად. WG– ებმა უნდა წარადგინონ IOP ტესტის გეგმა BARB– ზე ხელახლაview სანამ IOP ტესტი მოვლენა (ები) დაიწყება. სპეციფიკური მახასიათებლების გასაუმჯობესებლად (განსაკუთრებით ისეთები, რომლებიც არ საჭიროებენ რაიმე ტესტის შემთხვევის შეცვლას ან დამატებას საცდელ კომპლექტში), IOP ტესტირება შეიძლება არ იყოს საჭირო და WG– მ შეიძლება წარუდგინოს მოთხოვნა BARB– ს უარი თქვას IOP ტესტირებისგან განსაზღვრული პროცესის გამოყენებით პუნქტში 4.4.

IOP ტესტის გეგმა უნდა შეიცავდეს:

1. შეამოწმეთ შემთხვევები, რომ გადაამოწმოთ ყველა ახალი სავალდებულო, არასავალდებულო და პირობითი მახასიათებელი
2. მინიმუმ ერთი საცდელი შემთხვევა თითოეული ოპერაციული კოდისთვის
3. მინიმუმ ერთი საცდელი შემთხვევა თითოეული პარამეტრისთვის
4. მინიმუმ ერთი საცდელი შემთხვევა თითოეული პაკეტის ტიპისთვის
5. ჩამორჩენილი თავსებადობის ტესტის შემთხვევები დაზუსტების გაუმჯობესებისთვის, ისე, რომ 3.3.2 ნაწილში ჩამოთვლილი მოთხოვნები დაკმაყოფილდეს ყველა გაუმჯობესებული ფუნქციონირებისთვის (აგრეთვე იხილეთ ნაწილი 4.3.1.1).
6. ტესტის შემთხვევები, როდესაც IUT ექვემდებარება მნიშვნელობებს განსაზღვრულ ფარგლებს გარეთ ან ქცევითი ასპექტები, რომლებიც მიიჩნევა არასწორი ან მოულოდნელი (ქცევის არასწორი ტესტის შემთხვევები). გაითვალისწინეთ, რომ მოსალოდნელია ისეთი ტესტერი, როგორიცაა PTS ან სხვა საცდელი ინსტრუმენტი, ნებისმიერი არასწორი ქცევის ინიციატორი.
7. ნებისმიერი დროებითი მინიჭებული ნომრები (შერჩეულია BSTS– თან კოორდინაციით, რათა თავიდან აიცილოთ გადახურვა მომავალი IOP ტესტის მოვლენებზე) გამოსაყენებელი IOP ტესტის ღონისძიებაზე, როგორც აღწერილია ნაწილში 4.3.1.2.
8. საჭირო რაოდენობის დამოუკიდებელი განხორციელების იდენტიფიკაცია, რომელიც უნდა გაიაროს თითოეული საცდელი შემთხვევა, ნაწილი 4.3.1.3 – ში აღწერილი დაფარვის მოთხოვნების გათვალისწინებით.
9. Test Suite– ში ნებისმიერი საცდელი შემთხვევის იდენტიფიკაცია, რომელიც ჯგუფის აზრით, უნდა გამოირიცხოს და მათი გარიყვის დასაბუთება. ეს ჩვეულებრივ მოიცავს: • მომავალი კორექტირების ტესტების შემთხვევებს (მაგ., საერთო ტესტებს ისე, რომ შესაძლო მომავალი დამატებები იყოს განთავსებული, მაგალითად, დამატებითი მახასიათებლები, გაფართოების მახასიათებლები, ან გამოყენებულია Reserve for Future Use (RFU) ბიტების ან ველების გამოყენება).
   • ტესტის შემთხვევები, რომლებიც სხვა შედის ტესტების ქვეჯგუფად
   • ზოგადი საცდელი შემთხვევები, რომლებიც პრაქტიკულად იდენტურია ტესტებისა, რომლებიც ემსახურება რამდენიმე სხვა სპეციფიკაციას (მაგ., შეცდომის საერთო კოდების გააქტიურება)
   • შეამოწმეთ შემთხვევები, იგივე ტესტირების მიზნით, როგორც საცდელი შემთხვევები, რომლებიც სხვა ტრანსპორტს გადააბიჯებენ (მაგ., BR / EDR საცდელი შემთხვევა, რომელიც მსგავსია LE საცდელი შემთხვევისა)
   • განხორციელების სიმტკიცე ან სტრესული ტესტი

IOP ტესტის გეგმა შეიძლება ასევე მოიცავდეს ტესტებს, რომლებიც უნიკალურია IOP ტესტირებისთვის, როგორიცაა ბოლოს და ბოლოს საცდელი შემთხვევები, რომლებიც აერთიანებს უფრო რთულ თანმიმდევრობებს, რომლებიც შეიძლება ჰგავდეს ტიპიურ მომხმარებლის სცენარს.

მიუხედავად იმისა, რომ IAR ტესტის გეგმის BARB დამტკიცება არ არის საჭირო (იმის გაგებით, რომ IOP ტესტის გეგმა შეიცვლება და გაუმჯობესდება IOP ტესტის ყოველი ღონისძიების დროს), IAR ტესტის დასკვნის BARB დამტკიცება საჭიროა (იხ. ნაწილი 5.1.1) . თუ IOP ტესტის გეგმა არ აკმაყოფილებს 4.3.1 ნაწილში განსაზღვრულ ყველა მოთხოვნას, WG– მა უნდა წარუდგინოს BARB– ს ნებისმიერი ცნობილი ვარიანტისა და თითოეული ვარიანტის საფუძველი, სანამ IOP ტესტის ღონისძიება (ებ) ი დაიწყება.

IOP ტესტის გეგმა და საცდელი შემთხვევები, უპირველეს ყოვლისა, უნდა ემყარებოდეს მასთან დაკავშირებულ სპეციფიკაციების ტესტის დოკუმენტებს.

IOP ტესტის ღონისძიებების ეფექტურობის მისაღებად WG– ს უნდა ჰქონდეს IOP ტესტის გეგმა და მასთან დაკავშირებული ყველა ტესტი შემთხვევა დასრულებული და ხელმისაწვდომი უნდა იყოს განმახორციელებლებისთვის იდეალურად IOP ტესტის ჩატარებამდე ერთი თვით ადრე.

დაგეგმილი თავსებადობის ტესტირების დაგეგმვა
სპეციფიკაციის გასაუმჯობესებლად, IOP ტესტირება ჩამორჩენილი თავსებადობისას უნდა ითვალისწინებდეს გადამოწმებას სპეციფიკაციის ყველა აქტიური და მოძველებული ვერსიის წინააღმდეგ, რადგან Bluetooth- ის პროდუქტებში ჩვეულებრივ აღმოჩენილ ამ სპეციფიკაციებსა და ფუნქციურობას შეიძლება ჰქონდეს ძალიან დიდი სიცოცხლე (მაგ. მანქანები). WG– მ უნდა გააანალიზოს ჩამორჩენილი თავსებადობის ტესტირების შესაბამისი დონე (ასეთის არსებობის შემთხვევაში), მათ შორის რომელი ვერსიის შესამოწმებლად და ტესტების შესასრულებლად და მიაწოდოს ეს ანალიზი BARB– ს. ბარბი უნდა ხელახლაview ანალიზი და რეკომენდაცია გაუწიოს ცვლილებებს (ასეთის არსებობის შემთხვევაში) სამუშაო ჯგუფისათვის IOP ტესტირების გეგმაში.

წევრების მონაწილეები, რომლებიც მონაწილეობენ ჩამორჩენილ თავსებადობის ტესტირებაში, მოუწოდებენ ჩამოიტანონ მემკვიდრეობითი მოწყობილობები, რომლებსაც აქვთ კვალიფიკაცია წინა სპეციფიკაციების (ვერსიების) შესაბამისად. სამუშაო ჯგუფმა უნდა შეატყობინოს IOP ტესტის ანგარიშში თავსებადი ჩამორჩენილი უკმარისობის შესახებ. წევრ კომპანიებს ასევე ეძლევათ რეკომენდაცია ჩაატარონ ჩამორჩენილი თავსებადობის ტესტირება საკუთარ ლაბორატორიებში IOP ტესტის ადგილის გარეთ და მოახდინონ სამუშაო ჯგუფისთვის ინფორმაცია.

IOP ტესტირებაში გამოყენებული დროებითი მინიჭებული რიცხვები
BSTS და BARB უნდა გაიარონ კონსულტაცია მინიჭებული ნომრების დროებითი მინიჭების კოორდინაციისთვის, რომლებიც გამოყენებული იქნება IOP ტესტის ღონისძიებაზე, რომ არ მოხდეს სხვა სპეციფიკაციების გადაფარვა ან შეჯახება. ეს დროებითი მნიშვნელობები უნდა იყოს გათვალისწინებული IOP ტესტის გეგმაში და გამოყენებული არ იქნება ნებისმიერი მიღებული სპეციფიკაციით.

IOP ტესტირებისთვის, სადაც შემოთავაზებულია ერთი ან მეტი 16 ბიტიანი UUID მნიშვნელობები, მნიშვნელობები 0x7F00- დან 0x7FFF დიაპაზონში მოცემულია IOP ტესტირებისთვის.

IOP ტესტირებისთვის, სადაც შემოთავაზებულია ერთი ან მეტი ახალი ფიქსირებული პროტოკოლის სერვისის მულტიპლექსორის (PSM) მნიშვნელობები, გამოყენებული იქნება მნიშვნელობები მოქმედი დიაპაზონის ბოლოდან 0x0000 – დან 0x007F– მდე, როგორც ეს მითითებულია ძირითადი სპეციფიკაციით.

დაფარვის მოთხოვნები
WG– მ უნდა უზრუნველყოს BARB– ის მტკიცებულება, რომ დამოუკიდებელმა განხორციელების საჭირო რაოდენობამ (როგორც აღწერილია შემდეგ სექციებში) გაიარა თითოეული საცდელი შემთხვევა. WG ნებისმიერი თხოვნა, გამონაკლისი საჭირო რაოდენობის დამოუკიდებელი დანერგვისგან, მითითებული უნდა იყოს IOP ტესტის გეგმაში, რომელიც წარედგინება BARB.

განხორციელება ითვლება ერთმანეთისგან დამოუკიდებლად, სანამ ყველა ნაწილი, რომელიც შესაბამისობაშია ვალიდაციასთან, შემუშავებულია დამოუკიდებლად, ანუ სხვადასხვა გუნდის მიერ (რომლებიც სულაც არ მოდის სხვადასხვა კომპანიებიდან). BSTS– ს შეუძლია დაეხმაროს იმის შეფასებაში, შესაძლებელია თუ არა პროტოტიპების განხილვა ერთმანეთისგან დამოუკიდებლად, რათა შეინარჩუნოს განხორციელების დეტალების ანონიმურობა და კონფიდენციალურობა.

გაითვალისწინეთ, რომ ტესტის ინსტრუმენტები, მათ შორის PTS, არ ითვლება დამოუკიდებელ დანერგვად.

ძირითადი სპეციფიკაცია IOP დაფარვის მოთხოვნები
Core Specification ფუნქცია, როგორც წესი, განსაზღვრავს ერთ ან მეტ როლს, სადაც თითოეული როლი მიზნად ისახავს ურთიერთქმედებას ერთ ან მეტ სხვა როლთან ან შესაძლოა საკუთარ თავთან.

თითოეული წყვილი როლისთვის, რომლებიც მიზნად ისახავს ერთმანეთთან ურთიერთქმედებას, თითოეული როლის მინიმუმ სამი დამოუკიდებელი განხორციელება უნდა იყოს ნაჩვენები, რომ ერთმანეთთან ურთიერთქმედება დამატებითი როლის სამი დამოუკიდებელი განხორციელება.

თითოეული როლისთვის, რომელსაც შეუძლია ურთიერთქმედება სხვა მოწყობილობასთან იმავე როლით, ამ როლის მინიმუმ სამმა დამოუკიდებელმა განხორციელებამ უნდა აჩვენოს, რომ მათ ამ როლში ერთმანეთთან ურთიერთობა შეუძლიათ.

მომსახურების სპეციფიკაცია IOP დაფარვის მოთხოვნები
მინიმუმ სამმა დამოუკიდებელმა სერვისულმა დანერგვამ უნდა წარმოაჩინოს, რომ ისინი ურთიერთქმედებენ მინიმუმ ერთ კლიენტთან, რომელიც შეიძლება იყოს PTS.

პროfile და პროტოკოლის სპეციფიკა IOP დაფარვის მოთხოვნები
პროfile და პროტოკოლის სპეციფიკაციები, როგორც წესი, განსაზღვრავს ერთ ან მეტ როლს, სადაც თითოეული როლი შექმნილია ერთი ან რამდენიმე სხვა როლის, ან შესაძლოა თავისთავად ურთიერთქმედებისათვის.

თითოეული წყვილი როლისთვის, რომლებიც მიზნად ისახავს ერთმანეთთან ურთიერთქმედებას, თითოეული როლის მინიმუმ ორმა დამოუკიდებელმა განხორციელებამ უნდა აჩვენოს, რომ ისინი ურთიერთქმედებენ დამატებითი როლის ორ დამოუკიდებელ განხორციელებაზე.

თითოეული როლისთვის, რომელსაც შეუძლია ურთიერთქმედება სხვა მოწყობილობასთან იმავე როლში, ამ როლის მინიმუმ სამმა დამოუკიდებელმა განხორციელებამ უნდა აჩვენოს, რომ ისინი ურთიერთქმედებენ ერთმანეთთან ამ როლში.

მოდელის სპეციფიკაცია IOP დაფარვის მოთხოვნები
მინიმუმ სამმა დამოუკიდებელმა სერვერის მოდელის ან მართვის მოდელის დანერგვამ უნდა აჩვენოს, რომ ისინი ურთიერთქმედებენ მინიმუმ ერთ კლიენტთან (რომელიც შეიძლება იყოს PTS) და მინიმუმ ერთმა კლიენტის მოდელის დანერგვამ უნდა აჩვენოს, რომ იგი ურთიერთქმედებს მინიმუმ ერთი სერვერული მოდელის დანერგვასთან და PTS- სთან.

სპეციფიკაციის ვერსიის ნუმერაცია

დროს 0.9/CR სtagე, სამუშაო ჯგუფმა უნდა მოამზადოს რეკომენდაცია, რომ წარუდგინოს საბჭოს იმ ვერსიის ნომრის შესახებ, რომელიც გამოიყენება სპეციფიკაციაში მიღებისას.

სპეციფიკაციების ვერსიები ორ ტიპად იყოფა: სრული გამოშვების ვერსიები, რომლებიც მოიცავს ახალ ან განახლებულ მახასიათებლებს, და ტექნიკური გამოშვების ვერსიები (ასევე ცნობილი როგორც "dot-Z ვერსიები"), რომლებიც აერთიანებს ტექნიკურ და სარედაქციო შეცდომებს, მაგრამ არ შეიცავს ახალ ან განახლებულ მახასიათებლები. სრული გამოშვების ვერსიებს აქვთ ორი ნაწილის ნომრები XY სახით, მაგალითად, 2.1 ან 5.0, ხოლო ტექნიკური გამოშვების ვერსიებს აქვთ სამნაწილიანი ნომრები XYZ სახით, მაგალითად 2.1.2. Z- ის მნიშვნელობა არ შეიძლება იყოს 0.

ნებისმიერი ორი ვერსიისთვის ერთი მოიხსენიება როგორც "უმაღლესი ვერსია", ხოლო მეორე "ქვედა ვერსია". ეს განისაზღვრება შემდეგი წესების შესაბამისად:

• თუ X კომპონენტები განსხვავდება, უფრო მაღალი X მნიშვნელობის მქონე არის "უმაღლესი ვერსია".
• თუ X კომპონენტები იგივეა, მაგრამ Y კომპონენტები განსხვავდება, უფრო მაღალი Y მნიშვნელობის მქონე არის "უმაღლესი ვერსია".
• თუ XY კომპონენტები იგივეა, მაგრამ Z კომპონენტები განსხვავდება, უფრო მაღალი Z მნიშვნელობის მქონე არის "უმაღლესი ვერსია". ამ მიზნით, სამნაწილიანი XY განიხილება, როგორც სამნაწილიანი ნომერი XY.

მაგample, შემდეგი ვერსიის ნომრები იქნება ყველაზე დაბალიდან ყველაზე მაღალ ვერსიამდე: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. CSS– ისთვის, თითოეული განახლება ზრდის ვერსიის ნომრის მხოლოდ X კომპონენტს.

საბჭოს დამტკიცების წინაპირობები
სპეციფიკაციების შემუშავების ფაზის ბოლოს უნდა შესრულდეს შემდეგი მოთხოვნები, სანამ საბჭოს დასამტკიცებლად წარედგინება 0.9 / CR სპეციფიკაცია:

• ჯგუფმა დაასრულა ტესტის გაშუქების ანალიზი.
• BSTS დასრულდა ხელახლაview0.9/CR სპეციფიკაციისა და სატესტო დოკუმენტების შეტანა.
• BARB– მა დაამტკიცა 0.9 / CR სპეციფიკაცია.
• BARB– მა დაამტკიცა CSS CR (თუ სპეციფიკაციის მიხედვით მოითხოვება ახალი ჩანაწერები), რომელიც შეიძლება ჩასმული იყოს სპეციფიკაციის შემოკლებულ CR– ში.
• BARB– მა დაამტკიცა GSS CR და MDP CR (თუ სპეციფიკაციის მიხედვით მოითხოვება ახალი ჩანაწერები).
• BTI– მ დაამტკიცა 0.9/CR სატესტო კომპლექტი, ICS და TCRL, IXIT– თან ერთად (იმ პირობით, რომ IXIT არის საჭირო ტესტის კომპლექტში ტესტების შესასრულებლად). TCRL არის არჩევითი ამ stage ძირითადი მახასიათებლების განახლებებისთვის.
• სამუშაო ჯგუფმა წარადგინა IOP ტესტის გეგმა BARB– ზე ხელახლაview (თუ ტესტირებაზე უარი არ თქვა ბარბმა).

დოკუმენტაციაში წარმოდგენილი დოკუმენტები უნდა შეიცავდეს BARB– ის მიერ დამტკიცებულ 0.9 / CR სპეციფიკაციებს და საბჭოს წინაშე წარდგენილ დოკუმენტებს, რომლებიც უნდა შეიცავდეს:

• ნებისმიერი ცნობილი მოთხოვნა IOP– ის ტესტირების გაუქმების შესახებ ან 4.3.1 ნაწილში განსაზღვრული ნებისმიერი მოთხოვნა
• ტრანსპორტის სია, რომელსაც სპეციფიკაცია უჭერს მხარს (მაგ., BR / EDR, LE და ა.შ.)
• სპეციფიკაციის გაუმჯობესების მიზნით, ნებისმიერი გამონაკლისი ჩამორჩენილი თავსებადობის მოთხოვნებიდან (აღწერილი 3.3.2 ნაწილში), რომელსაც ითხოვს GP.
• სპეციფიკაციის გაუმჯობესების მიზნით, WG– ს რეკომენდაცია ვერსიის ნომრის შესახებ, გამოყენებულ იქნას სპეციფიკაციებზე
• სპეციფიკაციის გაუმჯობესების მიზნით, WG- ის სიცოცხლის ბოლოს რეკომენდაცია მიღებული სპეციფიკაციის წინა ვერსი (ებ) ისთვის, ტექნიკური ტექნიკური მიზეზების ჩათვლით, თუ რატომ არის რეკომენდებული ან არ არის რეკომენდებული სპეციფიკაციის რომელიმე წინა ვერსიის ცვეთის ან მოხსნა, და დასაბუთება რეკომენდაციისთვის
• BARB ან BTI წევრების ნებისმიერი გადაუჭრელი სერიოზული შეშფოთება (მაგ. დამტკიცების დროს ხმის მიცემის არანაირი მიზეზი, შეშფოთებაview სატესტო დოკუმენტები, ან შეშფოთება იმისა, რომ 0.9/CR სპეციფიკაცია არ არის FRD ან წესდების ფარგლებს გარეთ)
• პროს მომზადების სტატუსიfile Tuning Suite (PTS) ან შვილად აყვანისთან დაკავშირებული სხვა აუცილებელი ინსტრუმენტები, რომლებიც მომზადებულია BSTS– ის მიერ

საბჭოს შეუძლია აირჩიოს 0.9 / CR სპეციფიკაცია IOP ტესტირებისათვის, ამას მოითხოვს წესდება 2 საბჭომ ასევე შეიძლება განაპირობოს 0.9 / CR სპეციფიკაციის დამტკიცება IOP ტესტირებისთვის BTI– ს მიერ 4.3.1 / CR ტესტის დოკუმენტების დამტკიცებით.

0.9/CR სtage გასასვლელი მოთხოვნები
0.9/CR სtage დასრულებულია და ვალიდაციის ეტაპი იწყება მაშინ, როდესაც საბჭო დაამტკიცებს IOP ტესტირების დაწყებას.

4.4 სპეციფიკაციების შემუშავების პროცესის გაუქმება

სამუშაო ჯგუფმა შეიძლება მოითხოვოს უარი თქვას პროცესის შემდეგი ნაბიჯებიდან ერთზე ან რამდენიმეზე:

• 0.5/DIPD Stage
• 0.7/FIPD სtage
• IOP ტესტირება ვალიდაციის ფაზაში

უარის თქმის მოთხოვნით, WG– მ უნდა გამოიყენოს Bluetooth SIG– ის მიერ მოწოდებული პროცესზე უარის თქმის შაბლონი და წარუდგინოს უარის თხოვნა თითოეულ კომიტეტს (ანუ BARB ან BTI), რომელიც საჭიროა ხელახლაview ან დაამტკიცოს სპეციფიკაციის პროექტი ან მასთან დაკავშირებული სატესტო დოკუმენტები სtagე, რომ WG გვთავაზობს უარის თქმას და თითოეულმა კომიტეტმა უნდა დაამტკიცოს უარის თხოვნა.

უარის თქმის მოთხოვნა უნდა შეიცავდეს შემდეგს:

• ს -ის იდენტიფიკაციაtagე (ებ) ის, რომ WG– ს სურს უარი თქვას
• გამართლება რატომ სtage (s) უნდა იყოს მოხსნილი
• თითოეული კომიტეტის (ანუ BTI და/ან BARB) იდენტიფიკაცია, რომელიც საჭიროა ხელახლაview და დაამტკიცოს უარის თხოვნა

უარის თქმის საკითხის განხილვისას კომიტეტმა შეიძლება მოითხოვოს ჯგუფის წარმომადგენლის მიერ პრეზენტაციის წარდგენა SMPD პროცესზე უარის თქმის შესახებ, სანამ გადაწყვეტილებას მიიღებს უარის თქმის შესახებ.

თუ უარი ითხოვს უარი თქვას მრავალი ნაბიჯით, უარი ნაწილი უარყოფილია და ნაწილი დამტკიცებულია, კომიტეტის პასუხი უნდა მიუთითოს უარი თქვის მოთხოვნის რომელ ეტაპზეა დამტკიცებული და რომელი უარყოფილია. უარის თქმის თხოვნაზე უარის თქმის შემთხვევაში, უარის თქმის შესახებ შეტყობინება უნდა შეიცავდეს უარის თქმის მიზეზებს.

5. დამტკიცების ფაზა

ვალიდაციის ფაზის განმავლობაში, WG შეასრულებს IOP ტესტირებას 0.9/CR სპეციფიკაციაზე BARB re– ის IOP ტესტის ანგარიშის მიწოდების მიზნით.view და მოწონება. შეძლებისდაგვარად, სპეციფიკაციის გაუმჯობესების IOP ტესტირება უნდა ჩატარდეს ინტეგრირებული სპეციფიკაციის პროექტის წინააღმდეგ. გარდა ამისა, წევრმა რეview, როგორც ამას შინაგანაწესი მოითხოვს [2], იწყება ამ ფაზაში.

თუ სპეციფიკაცია (ან გაფართოება) არ საჭიროებს IOP– ს ტესტირებას, მაშინ IOP– ის ტესტირება ვალიდაციის ფაზაში შეიძლება უარი თქვას 4.4 ნაწილში აღწერილი პროცესის გამოყენებით.

IOP ტესტირების მსვლელობისას (რომელიც შეიძლება იყოს ერთი ან მეტი მოვლენა), სამუშაო ჯგუფმა უნდა ადევნოს თვალყური პრობლემებს Bluetooth SIG– ის საკითხების თვალთვალის სისტემის გამოყენებით და განმეორდეს, რომ შეიტანოს განახლებები პროექტის სპეციფიკაციის, სატესტო დოკუმენტების და IOP სატესტო გეგმის შესახებ. მას შემდეგ, რაც IOP ტესტირება დასრულდება, WG– მ უნდა შეავსოს სპეციფიკაციებისა და სატესტო დოკუმენტების განახლებები ყველა საკითხის მოსაგვარებლად და მოამზადოს და წარუდგინოს IOP ტესტის ანგარიში BARB– ს განმეორებითview და მოწონება. ეს ნაჩვენებია ნახაზზე 5.1.

ვალიდაციის ფაზაში რამდენიმე მოქმედება შეიძლება დაიწყოს. ეს საქმიანობა შეიძლება მოხდეს პარალელურად და მოიცავს შემდეგს:

• საბჭოს მიერ დამტკიცებული 0.9/CR სპეციფიკაცია ხელმისაწვდომია ყველა წევრისათვის BSTS– ით, წევრის დაწყების შესახებ შეტყობინებითview პერიოდი, რომელიც მოთხოვნილია შინაგანაწესით.
• ნებისმიერი საჭირო განახლება შედის CSS– ში (რომელიც შეიძლება ჩაწერილი იყოს სპეციფიკაციის შემოკლებულ CR– ში).
• დამახასიათებელი ან აღწერითი განმარტებები შედის GSS სპეციფიკაციაში, ასევე PTS IOP ტესტირებისთვის.
• ქსელის თვისებების განმარტებები შედის MDP სპეციფიკაციაში, ისევე როგორც PTS IOP ტესტირებისთვის.
• BSTS საშუალებას იძლევა IOP პლატფორმის რეგისტრაციისა და შედეგების შესვლის ინსტრუმენტისთვის, IOP ტესტირებისთვის მოსამზადებლად.
• IOP ტესტირება, საჭიროების შემთხვევაში (იხ. ნაწილი 5.1).
• Review კომენტარები და საკითხები, მათ შორის IOP- ის ტესტირების შედეგად წარმოდგენილი, დამუშავებულია და ცვლილებები შეტანილია სპეციფიკაციის პროექტში.

5.1 IOP ტესტირება

IOP ტესტირების პირველადი მიზანი არის სპეციფიკაციის დადასტურება, მაგample, ტექსტის შიგნით სიზუსტისა და გაურკვევლობის შემოწმება, reviewდიზაინის ნებისმიერი ფუნდამენტური შეცდომისა და გამოტოვებისათვის და დადასტურების უზრუნველყოფა ადრე დადგენილი მოთხოვნების შესაბამისად, რომელიც შემუშავდა ადრე სპეციფიკაციის შემუშავების პროცესში. IOP ტესტირებამ შეიძლება გამოიწვიოს ცვლილებები სპეციფიკაციის პროექტში და შეიძლება საჭირო გახდეს IOP ტესტის მრავალი ღონისძიება ყველა საჭირო ტესტირების დასასრულებლად.

მნიშვნელოვანია, რომ მიეცით წევრებს WG– ს გარეთ მონაწილეებს შესაძლებლობა მიიღონ მონაწილეობა IOP ტესტირებაში, რადგან ისინი უზრუნველყოფენ დამოუკიდებელს view დაზუსტება და დაზუსტება ისეთ სფეროებში, რომლებიც არ შეიძლება იყოს აშკარა სამუშაო ჯგუფის წევრებისათვის, რომლებმაც შეიმუშავეს პროექტი. IOP– ის ყოველი სატესტო მოვლენის დაწყებამდე, BSTS გახდის ღონისძიების დეტალებს, უახლეს სპეციფიკაციებს, ტესტირების კომპლექტს და IOP ტესტის გეგმას და იდეალურად აცნობებს ყველა წევრს ყოველი მოვლენის დაწყებამდე ერთი თვით ადრე. განახლებული პროექტის სპეციფიკაცია, ტესტი Suite და IOP ტესტი გეგმა, რომელიც გამოიყენება IOP სატესტო ღონისძიებაზე, ხელმისაწვდომი უნდა იყოს ყოველ ღონისძიებამდე მინიმუმ ერთი კვირით ადრე.

IOP ტესტირების დროს, პლატფორმების წყვილთა კომბინაციები შეეცდება შეასრულოს ტესტები და IOP ტესტირების მონაწილეები ჩაწერენ თითოეული ტესტის და კომენტარის ჩაბარების / ჩავარდნის შედეგებს. ამ შედეგების ანონიმური შეჯამება (მაგალითად, „პლატფორმა A“, „პლატფორმა B“ და ა.შ.) და ნებისმიერი კომენტარი, შეიკრიბება IOP ტესტის დროს და ხელმისაწვდომი იქნება WG წევრებისათვის IOP– ის განმავლობაში და მის შემდეგ. ტესტის ღონისძიება. იმ შემთხვევაში, თუ საჭიროა დამატებითი ინფორმაცია IOP- ის ტესტირების დროს წარმოქმნილი კომენტარის ან წარუმატებლობის უკეთ გასაგებად, BSTS– ს შეუძლია შუამავალი გახდეს, რომ წარადგინოს დამატებითი ინფორმაცია მომწოდებელი წევრისგან.

თუ შესაძლებელია, PTS უნდა განახლდეს, რათა ხელი შეუწყოს IOP ტესტირებას პლატფორმებთან მასპინძლის კონტროლერის ინტერფეისის (HCI) ზემოთ ყველა ფენაში და იმყოფებოდეს IOP ტესტის ღონისძიებებზე ამ ფენებისათვის. ტესტირების სხვა საშუალებები შეიძლება ასევე იყოს IOP ტესტის ღონისძიებებზე. ტესტირების შედეგების რეზიუმე PTS- ით ან სხვა ტესტი საშუალებებით (ასეთის არსებობის შემთხვევაში) უნდა შეიტანოს IOP ტესტის ანგარიშში.

IOP ტესტირება ღია იქნება ყველა წევრისთვის, ვისაც სურს უზრუნველყოს პროტოტიპის დანერგვა, თუმცა Bluetooth SIG– მა შეიძლება მონაწილეობა განაპირობოს Bluetooth SIG– თან ხელშეკრულებების მიღებით (მონაწილეობისა და კონფიდენციალურობის ხელშეკრულებების ჩათვლით). სამუშაო ჯგუფი პასუხისმგებელია IOP ტესტირების დროს აღმოჩენილი საკითხების დამუშავებასა და მოგვარებაზე და დაზარალებული დოკუმენტების განახლებაზე; WG– ს მიერ დამტკიცებული ცვლილებები უნდა შეიცავდეს როგორც განახლებებს სპეციფიკაციის პროექტში და ტესტის დოკუმენტებში, თითოეული IOP ტესტის შემთხვევაში.

დადასტურების ფაზამდე, სამუშაო ჯგუფებს შეუძლიათ ჩაატარონ IOP წინასწარი ტესტირება ღონისძიებებზე, რომლებიც მხოლოდ GP ჯგუფის წევრებს შეუძლიათ, თუმცა არაფორმალური ტესტირების შედეგები არ შეიძლება იყოს IOP ტესტის შედეგებში.

შეიძლება მოხდეს, რომ დაიცვას IOP ტესტის პირველი ღონისძიებამდე მიმავალი ყველა ეტაპი, მათ შორის გამოცხადებული IOP თარიღი და ადგილმდებარეობა, IOP ტესტირების დაწყების მიზნით, მაგრამ საბჭოს დამტკიცება არ იყო უზრუნველყოფილი სატესტო ღონისძიების დაწყებამდე. ამ შემთხვევაში, საბჭომ შეიძლება დაუშვას ტესტის შედეგების ჩართვა, რომლებიც შეგროვდა საბჭოს დამტკიცებამდე, IOP ტესტირების დასაწყებად, იმ პირობით, რომ შეგროვებული შედეგები ემყარება იმავე სპეციფიკაციებს და საბჭოს მიერ დამტკიცებული Test Suite.

IOP ტესტირება არ არის საჭირო CSS, GSS ან MDP სპეციფიკაციების გაუმჯობესებისთვის.

IOP ტესტის დასკვნა
IOP ტესტირების დასრულების შემდეგ, სამუშაო ჯგუფმა უნდა წარუდგინოს IOP ტესტის ანგარიში BARB– ს, რათა აჩვენოს, რომ დამოუკიდებელმა პლატფორმების საჭირო რაოდენობამ გაიარა საჭირო ტესტები. ბარბი უნდა ხელახლაview და ამტკიცებს ან უარყოფს IOP ტესტის ანგარიშს და შეატყობინებს WG– ს, თუ საჭირო იქნება IOP– ის დამატებითი ტესტირება ხმის მიცემის პროექტის სპეციფიკაციის პაკეტის საბჭოში წარდგენამდე. BSTS და WG უნდა დარწმუნდნენ, რომ წევრის საიდენტიფიკაციო ინფორმაცია არ გამოჩნდება IOP ტესტის ანგარიშში ანგარიშის BARB– ს წარდგენამდე.

IOP ტესტის ანგარიში უნდა შეიცავდეს:

• IOP ტესტის ყველა ღონისძიების სია, რომლებიც მოხდა ვალიდაციის ფაზის განმავლობაში, მათი თარიღებისა და ადგილმდებარეობების ჩათვლით.
• წევრი კომპანიებისა და დამოუკიდებელი პლატფორმების რაოდენობა, რომლებიც მონაწილეობდნენ IOP- ის თითოეულ ღონისძიებაში, მათ შორის იყო გამოყენებული თუ არა PTS.
• სპეციფიკაციების, Test Suite და IOP ტესტის გეგმის ვერსიების ჩამონათვალი, რომლებიც გამოიყენება თითოეულ ღონისძიებაზე.
• აღმასრულებელი რეზიუმე, რომელშიც ნათქვამია, აკმაყოფილებდა თუ არა ყველა სატესტო შემთხვევა მინიმალური ჩაბარების კრიტერიუმებს.
• IOP ტესტის გეგმის მოთხოვნებიდან ნებისმიერი ვარიანტის შეჯამება, რომელიც განისაზღვრება 4.3.1 ნაწილში და თითოეული ვარიანტის საფუძველი.
• Test Suite- ში სატესტო შემთხვევების PTS გაშუქების რეზიუმე.
• IOP ტესტის გეგმიდან ყველა სატესტო შემთხვევების ჩამონათვალი (ჩამორჩენილი ჩამორჩენილი ტესტების ჩათვლით), ტესტის ჩაბარების რაოდენობა, ტესტის ჩავარდნების რაოდენობა და თუ არა მინიმალური კრიტერიუმების დაცვა ტესტის შემთხვევაში, განმარტება, თუ რატომ არ იყო მოთხოვნები შეხვდა.
• საკითხების, კომენტარების და კითხვების შეჯამება თითოეულ ღონისძიებაზე (მათ შორის filed სპეციფიკაციის საწინააღმდეგოდ IOP ტესტირების დროს) და ზემოქმედება სპეციფიკაციაზე და ტესტირების დოკუმენტებზე.

5.2. ვალიდაციის ფაზის გასვლის მოთხოვნები

ვალიდაციის ფაზა დასრულებულია და დამტკიცების / მიღების ფაზა იწყება, როდესაც BARB– მა დაამტკიცა IOP ტესტის დასკვნა (თუ ტესტირება არ იქნა უარყოფილი BARB– ის მიერ) და ყველა შემდეგი მოთხოვნა დაკმაყოფილდა:

• BSTS– მა დაამტკიცა 0.9/CR სპეციფიკაცია ყველა წევრისათვის წევრი Re– სთვისview როგორც ამას მოითხოვს შინაგანაწესი და აცნობებს ყველა წევრს მის ხელმისაწვდომობაზე.
• ყველა საკითხი, რომელიც გამოვლინდა IOP ტესტირების დროს და რომელსაც აქვს ტესტის გავლენა, ჩაირთო და შემოწმდა.
• WG– მა დაასრულა IOP ტესტირება (თუ BARB– მა უარი თქვა ტესტირებაზე).

 

6. შვილად აყვანის / დამტკიცების ფაზა

შვილად აყვანის/დამტკიცების ფაზის დროს ხდება სპეციფიკაციისა და მასთან დაკავშირებული სატესტო დოკუმენტების დასრულება, მიიღება BARB, BQRB და BTI დამტკიცება, მიიღება შეტყობინება შემოთავაზების მიღების თარიღთან ერთად, სპეციფიკაციის პროექტის საბოლოო ვერსიასთან ერთად, რომელიც წარედგინება საბჭოს დასამტკიცებლად ( ხმის მიცემის პროექტი) და საბოლოო სპეციფიკაციის პაკეტი წარედგინება საბჭოს. წევრი რე მინიმალური ხანგრძლივობის შემდეგview მოთხოვნილია შინაგანაწესით [2]) დაკმაყოფილებულია, საბჭო განიხილავს შვილად აყვანის სპეციფიკაციას შვილად აყვანის თარიღზე. მიღების შემდეგ, გამოქვეყნდება სპეციფიკაცია და ჩართულია საკვალიფიკაციო სისტემა. შვილად აყვანის/დამტკიცების ეტაპი ილუსტრირებულია ფიგურაში 6.1.

6.1 ხმის მიცემის პროექტი

კენჭისყრის პროექტი იქმნება განახლებების (გადამოწმების ფაზაში მოცემული) საჭირო სპეციფიკაციების დოკუმენტებში ჩართვით და ახალი სპეციფიკაციების საბოლოო პროექტის მომზადებით. სპეციფიკაციების დამატების მიზნით, BSTS შექმნის ინტეგრირებულ დაზუსტებას ერთი ან მეტი CR (ების) ინტეგრირებით ადრე მიღებული სპეციფიკაციის უფრო მაღალ ვერსიაში (იხ. ნაწილი 4.3.2), თუ ის ჯერ არ დასრულებულა ვალიდაციის ფაზამდე.

თუ ამ ფაზაში შეიტანეს ცვლილებები სპეციფიკაციაში, ხოლო WG, BARB ან BTI განსაზღვრავს, რომ ნებისმიერი ცვლილება მოითხოვს IOP– ის დამატებით ტესტირებას, სპეციფიკაცია დაუბრუნდება WG– ს ვალიდაციის ფაზის IOP– ის ტესტირების ნაწილს, დამატებითი ტესტების შესასრულებლად. მიღების / დამტკიცების ფაზის განმავლობაში, შემდეგი დოკუმენტები დასრულდება და მიიღება გამგეობისთვის, მიღებამდე:

• ხმის მიცემის პროექტი
• ყველა დამხმარე სპეციფიკაცია (მაგ., CSS, GSS, MDP), რაც საჭიროა შესაბამისი სპეციფიკაციის (ან გაფართოების) ტიპისთვის, თუ ეს ადრე არ იყო მიღებული
• სპეციფიკაციების დამატებისთვის, მიღებული სპეციფიკაციის ვერსიის თვალყური ადევნებული ვერსია, რომელიც აჩვენებს კენჭისყრის პროექტში შემოთავაზებულ ცვლილებებს.
• WG– ს აღწერა ნებისმიერი ჩამორჩენილი თავსებადობის მოთხოვნების შესახებ (როგორც აღწერილია 3.3.2 ნაწილში), რომლებიც არ არის შესრულებული და ნებისმიერი შეღავათების დასაბუთება
• WG– სგან IOP ტესტის გეგმის ნებისმიერი მოთხოვნის აღწერა (როგორც აღწერილია ქვეთავში 4.3.1), რომელიც არ დაკმაყოფილდა და ნებისმიერი გადახრის დასაბუთება IOP ტესტის ანგარიშთან ერთად (რომელიც შეიძლება უზრუნველყოფილი იყოს ასლის ბმულის მიწოდებით Bluetooth SIG webსაიტი)
• WG– ს რეკომენდაცია მიღებული სპეციფიკაციის ნებისმიერი წინა ვერსიის (ვერსიის) გაუქმების ან გაუქმების შესახებ დასაბუთებასთან ერთად, რომელიც ხაზს უსვამს ცვლილებებს 0.9/CR S– დანtagსიცოცხლის დასრულების რეკომენდაცია
• ჯგუფის მიერ მომზადებული რეზიუმე მახასიათებლების ან ფუნქციონალური ცვლილებების შესახებ 0.9 / CR სპეციფიკაციიდან (ასეთის არსებობის შემთხვევაში)
• BARB– ის მიერ მომზადებული რეზიუმე, BARB– ის წევრების მიერ წამოჭრილი შეშფოთების შესახებ, რომ GP– ს მიერ წარმოდგენილ სპეციფიკაციას სცილდება საბჭოს მიერ დამტკიცებული წესდების (ასეთის არსებობის შემთხვევაში)
• სამართლებრივი გადასახადებიდან დარჩენილი გადაუჭრელი სამართლებრივი საკითხების ჩამონათვალიview (ასეთის არსებობის შემთხვევაში)
• BTI– ს მიერ დამტკიცებული ტესტის სუიტა, WG– ს მიერ დამტკიცებული რეზიუმე, კენჭისყრის პროექტის სპეციფიკაციის ტესტის გაშუქების შესახებ. ტესტის გაშუქების გარეშე ახლად დამატებული ან შეცვლილი ფუნქციონირების შემთხვევაში საჭიროა გამოტოვების წერილობითი დასაბუთება
• BTI– ს მიერ დამტკიცებული ICS და IXIT (თუ ამას მოითხოვს სპეციფიკაცია)
• TCRL დამტკიცებულია BTI– სა და BQRB– ის მიერ
• BSTS– ის მიერ მომზადებული ანგარიში BTI– სთან დაკავშირებით ინსტრუმენტის მზადყოფნის სტატუსთან დაკავშირებით (მაგ., PTS და სხვა საცდელი საშუალებები, Bluetooth Launch Studio), მათ შორის, თუ TCRL– ში რაიმე საცდელი შემთხვევა არ არის მხარდაჭერილი საცდელი საშუალებებით
• სამუშაო ჯგუფის მიერ მომზადებული რეზიუმე ყველა საჭირო მინიჭებული ნომრის შესახებ
• BSTS- ისა და WG- ს მიერ მომზადებული შვილად აყვანის ჩამონათვალი, რომელიც აჩვენებს, რომ ამ მონაკვეთის ყველა პროდუქტი დასრულებულია
• საბჭოს მიერ მოთხოვნილი ყველა სხვა ინფორმაცია

მიღების / დამტკიცების ფაზის განმავლობაში, WG– მ უნდა გამოიყენოს Bluetooth SIG– ის საკითხის მონიტორინგის სისტემა, რათა დააფიქსიროს საკითხები და კომენტარები სპეციფიკაციის და სატესტო დოკუმენტების საწინააღმდეგოდ, რათა მათ აღრიცხონ კენჭისყრის სპეციფიკაციის პროექტის დასრულებისას. სპეციფიკაციის გასაუმჯობესებლად, ყველა შესაბამისი დამტკიცებული ერტა (ანუ ის, რაც ჯერ კიდევ არ არის ინტეგრირებული), უნდა იყოს ჩართული და მათი იდენტიფიცირება ხდება თვალყური ადევნებული ცვლილებების გამოყენებით.

WG– მ უნდა წარუდგინოს სპეციფიკაციის საბოლოო პროექტი BSTS– ს იურიდიული განსახილველადviewრა ახალი სპეციფიკაციებისთვის, სამართლებრივი რეview მოიცავს მთელ სპეციფიკაციას. სპეციფიკაციის გაუმჯობესების მიზნით, ხელახლაview ძირითადად ფოკუსირდება სპეციფიკაციის შეცვლილ ნაწილებზე. მიზანი სამართლებრივი რეview უპირველეს ყოვლისა არის იურიდიული რისკების იდენტიფიცირება, რომლებიც უნდა განიხილოს და უნდა მოაგვაროს ჯგუფმა. სამართლებრივი უკუკავშირი იქნება კატეგორიზებული სიმძიმის მიხედვით. თუ არჩევითი იურიდიული ხელახალიview შესრულდა 0.9/CR Stagე, ვერსია, რომელიც იგზავნება კანონიერი ხელახლაview უნდა აჩვენოს, როგორც თვალყური ადევნებს ყველა იმ ცვლილებას, რაც განხორციელდა ამ ვერსიიდან (გენერირებული WG ან BSTS). ლეგალური ხელახალი დასრულების შემდეგview, WG და BSTS შეთანხმდებიან გამოხმაურებაზე, რომელიც უნდა შეიტანოს სპეციფიკაციის პროექტში. თუ არსებობს რაიმე გადაუჭრელი სამართლებრივი შენიშვნები სამართლებრივი რეview სპეციფიკაციის პროექტზე, სამუშაო ჯგუფის თავმჯდომარეს შეუძლია მოითხოვოს დრო საბჭოს დღის წესრიგში დადგენილების შეთანხმების მიზნით.

პარალელურად სამართლებრივი რეviewსამუშაო ჯგუფმა უნდა წარუდგინოს სპეციფიკაციის პროექტი BARB– ს ხელახლაviewრა BARB– ს პირველადი წარდგენისთანავე, BSTS შეატყობინებს ყველა წევრს, რომ სპეციფიკაციის პროექტი გადაეცა BARB– ს ხელახლაview და რომ ის ასევე ხელმისაწვდომია წევრი Reviewრა თუ WG წარუდგენს განახლებებს BARB ხელახლა ხელახალი პროექტის სპეციფიკაციის პროექტზეview, BSTS პერიოდულად გაგზავნის დამატებით შეტყობინებებს ყველა წევრს.

დასრულების შემდეგ BARB ხელახლაview, WG და BARB შეთანხმდებიან გამოხმაურებაზე, რომელიც უნდა იყოს ჩართული სპეციფიკაციის პროექტში.

თუ ლეგალური ხელახლაview იწვევს რაიმე არსებით ცვლილებას, დამატებით ხელახლაview BARB– ის მიერ შეიძლება იყოს საჭირო. ანალოგიურად, თუ ბარბარე ხელახლაview შედეგად ნებისმიერი არსებითი ცვლილება, BSTS განსაზღვრავს თუ არა დამატებითი სამართლებრივი რეview ამ ცვლილებებიდან საჭიროა. ლეგალური ხელახალი დასრულების შემდეგview და ბარბ ხელახლაview, ბარბმა უნდა დაამტკიცოს ან უარყოს კენჭისყრის პროექტი.

თუ რაიმე საცდელი დოკუმენტის განახლებას საჭიროებს, BSTS დაეხმარება ჯგუფს სატესტო დოკუმენტების განახლებაში. BTI– მ უნდა დაამტკიცოს ან უარყოს ტესტის დოკუმენტები. BTI– ს მიერ დამტკიცების შემთხვევაში, BTI ხელს შეუწყობს TCRL– ის დასრულებას და ამ დოკუმენტის მიწოდებას BQRB– სთან ასოცირებულ ICS, IXIT და Test Suite– თან ერთად. BSTS შეაფასებს საბჭოს სხდომის თარიღს, როდესაც საბჭო აპირებს კენჭისყრა კენჭისყრის პროექტის (მიღების თარიღი) მიღებაზე და მისთვის BTI გამოიყენოს TCRL– ში. დაზუსტების დადასტურება BARB, ყველა საცდელი დოკუმენტის BTI დამტკიცება (Test Suite, TCRL, ICS და IXIT ჩათვლით) და TQRL BQRB დამტკიცება უნდა მოხდეს მიღების თარიღზე ან მანამდე.

BSTS აცნობებს ყველა წევრს კენჭისყრის პროექტის დასრულებისა და ხელმისაწვდომობის და მიღების თარიღის შესახებ. მიღების თარიღი განისაზღვრება არა უადრეს 60 დღისა მას შემდეგ, რაც წევრებმა მიიღეს ინფორმაცია საბჭოს მიერ დამტკიცებული 0.9/CR სპეციფიკაციის შესახებ, თუ წევრი არview ვადა მცირდება საბჭოს მიერ შინაგანაწესის შესაბამისად, ხოლო შვილად აყვანის თარიღის გაფრთხილებიდან სულ მცირე 14 დღის შემდეგ წევრებს მიეწოდება წესდების შესაბამისად. იმ შემთხვევებში, როდესაც მრავალჯერადი CR ინტეგრირებულია კენჭისყრის პროექტში, წევრი Re იწყებაview არის თარიღი, როდესაც წევრებმა მიიღეს შეტყობინება საბჭოს მიერ დამტკიცებული CR– ის შესახებ.

მას შემდეგ, რაც წევრებს მიიღებენ მიღების თარიღს, დაშვებულია საბჭოს მიერ დამტკიცებული შესწორებები კენჭისყრის პროექტში ტიპოგრაფიულ შეცდომებში. სპეციფიკაციების მიღების ქრონოლოგია ასახულია ნახაზზე 6.2.

6.2 მინიჭებული რიცხვები

Bluetooth SIG ინარჩუნებს მინიჭებული ნომრების საჯაროდ ხელმისაწვდომ კომპლექტს Bluetooth SIG მინიჭებულ ნომრებზე webსაიტი [7]. ეს მინიჭებული რიცხვები დაჯგუფებულია სხვადასხვა რიცხვით სივრცეში (რიცხვების დაკავშირებული ნაკრები დუბლიკატების გარეშე). მინიჭებული რიცხვები შეიძლება გადაფარავდეს სხვა მინიჭებულ რიცხვებს სხვადასხვა რიცხვით სივრცეში, მაგრამ რიცხვთა სივრცეში რიცხვის ხელახალი გამოყენება ნებადართული არ არის. სხვადასხვა რიცხვითი სივრცე განისაზღვრება სპეციფიკაციაში, რომელიც განსაზღვრავს მინიჭებული რიცხვების გამოყენებას.

მას შემდეგ, რაც BARB დაამტკიცებს IOP ტესტის ანგარიშს, WG წარუდგენს მოთხოვნას BARB– ს ახალი ნომრების მინიჭებისათვის საბოლოო სპეციფიკაციით მოთხოვნილ რიცხვთა სივრცეში. ბარბი ხელახლაview მოთხოვნა და მუშაობა BSTS– თან, განსაზღვრული ნომრების დასადგენად. 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. სპეციფიკაციის ტექნიკური ფაზა

სპეციფიკაციის ტექნიკური ფაზა იწყება მიღების / დამტკიცების ფაზის დასრულების შემდეგ. თუ დაფიქსირდა პრობლემები (მაგ., გაურკვევლობის ფორმები ან ტექნიკური შეცდომები) დაზუსტებასთან ან მასთან დაკავშირებული სატესტო დოკუმენტებთან, მათი დოკუმენტირება უნდა მოხდეს errata წინადადებების შექმნით Bluetooth SIG Errata ინსტრუმენტის გამოყენებით. დაზუსტებული წინადადებების დამუშავება, კატეგორიზაცია და დამტკიცება მოხდება EPD– ის შესაბამისად [3]. Test Suite ერატუმის დამუშავება და კატეგორიზაცია ხდება TSTO– ს მიხედვით [5]. თუ რაიმე კონფლიქტი არსებობს SMPD– სა და EPD– ს ან TSTO– ს შორის, უპირატესობას ანიჭებს SMPD– ს.

დაზუსტების ცდომილება უნდა იქნას გამოყენებული მხოლოდ ტექნიკური ან სარედაქციო შეცდომების გამოსასწორებლად საბოლოოდ მიღებულ Bluetooth სპეციფიკაციებში. ფუნქციების დამატება, ცვლილებები და მოხსნა შეიძლება განხორციელდეს მხოლოდ ამ დოკუმენტში ადრე განსაზღვრული სპეციფიკაციის გაუმჯობესების პროცესის საშუალებით.

7.1 დაჩქარებული ერარატული პროცესი

როდესაც შეცდომა დამტკიცდება EPD [3] - ში განსაზღვრული პროცესის შემდეგ, WG, BARB ან BSTS შეიძლება გირჩიოთ, რომ იგი სასწრაფოდ ჩაითვალოს და დაჩქარდეს. როდესაც ეს მოხდება, BSTS ერთად WG ან BARB წარუდგენს რეკომენდაციას საბჭოს. საბჭო გადაწყვეტს მიიღოს თუ არა უარი რეკომენდაციაზე. თუკი რეკომენდაცია მიიღება, BSTS დაუყოვნებლივ შეიტანს დამტკიცებულ შეცდომას შეცდომის შაბლონში [8] და იმუშავებს პასუხისმგებელ სამუშაო ჯგუფთან, რათა დაასრულოს Errata– ს დაჩქარებული კორექტირება, რომელიც უნდა წარედგინოს WG– ს ხელახლაview და მოწონება.

დასრულდაview დაჩქარებული ცვალებადობის პროცესი ილუსტრირებულია ნახაზზე 7.1.

შემდეგი დოკუმენტები შევსებული უნდა იყოს და საბჭოსთვის ხელმისაწვდომი უნდა იქნეს მიღებამდე:

• BARB- ის მიერ დამტკიცებული დაჩქარებული შეცდომის შესწორების პროექტი.
• WG– სგან აღწერა ნებისმიერი ჩამორჩენილი თავსებადობის მოთხოვნების შესახებ (როგორც აღწერილია 3.3.2 ნაწილში) და რომელიც არ არის შესრულებული და ნებისმიერი შეღავათების დასაბუთება.
• სამართლებრივი გადასახადებიდან დარჩენილი გადაუჭრელი სამართლებრივი საკითხების ჩამონათვალიview (ასეთის არსებობის შემთხვევაში).
• BTI– ს მიერ დამტკიცებული Test Suite, ICS და IXIT (თუ მოთხოვნილება აქვს ერატუმს).
• BTI- და BQRB დამტკიცებული TCRL (თუ ამას ითხოვს ერატიუმი).
• BSTS– ის მიერ შევსებული ანგარიში BTI– სთან დაკავშირებით ინსტრუმენტის მზადყოფნის სტატუსთან დაკავშირებით (მაგ., PTS და სხვა საცდელი ხელსაწყოები, Bluetooth Launch Studio), მათ შორის, თუ TCRL– ში რაიმე საცდელი შემთხვევა არ არის მხარდაჭერილი ტესტის საშუალებებით და ახსნა-განმარტება (თუ ამას ითხოვს ერტატი )
• BSTS- ისა და WG- ს მიერ შევსებული შვილად აყვანის ჩამონათვალი, რომელიც აჩვენებს, რომ ამ ნაწილში არსებული პროდუქტები დასრულებულია.
• საბჭოს მიერ მოთხოვნილი ყველა სხვა ინფორმაცია.

BSTS იმუშავებს პასუხისმგებელ სამუშაო ჯგუფთან, რათა დაასრულოს Errata– ს დაჩქარებული კორექტირების პროექტი და შექმნას ვერსია, რომელიც წარუდგენს პასუხისმგებელ WG– ს ხელახლაview და მოწონება.

WG– მ უნდა წარუდგინოს Errata– ს დაჩქარებული შესწორება BSTS– ს იურიდიული განსახილველადviewრა ლეგალური ხელახალი დასრულების შემდეგview, WG და BSTS შეთანხმდებიან გამოხმაურებაზე, რომელიც უნდა დაინერგოს Errata– ს დაჩქარებულ კორექტირებაში. თუ არსებობს რაიმე გადაუჭრელი სამართლებრივი შენიშვნები სამართლებრივი რეview Errata– ს დაჩქარებული კორექტირებისას, WG– ის თავმჯდომარეს შეუძლია მოითხოვოს დრო საბჭოს დღის წესრიგში, რათა მოიძიოს საბჭოს გადაწყვეტილება გადაწყვეტილების მიღების შესახებ.

პარალელურად სამართლებრივი რეviewWG– მ უნდა წარუდგინოს Errata– ს დაჩქარებული კორექტირება BARB– ს ხელახლაviewრა მას შემდეგ, რაც დაჩქარებული Errata შესწორება წარედგინება BARB- ს, BSTS გახდის მისაწვდომს ყველა წევრისათვის ხელახლაview და აცნობოს ყველა წევრს მისი ხელმისაწვდომობის შესახებ. დასრულების შემდეგ BARB ხელახლაview, WG და BARB შეთანხმდებიან გამოხმაურებაზე, რომელიც უნდა დაინერგოს Errata– ს დაჩქარებულ კორექტირებაში.

თუ ლეგალური ხელახლაview იწვევს რაიმე არსებით ცვლილებას, დამატებით ხელახლაview BARB– ის მიერ შეიძლება იყოს საჭირო. ანალოგიურად, თუ ბარბარე ხელახლაview შედეგად ნებისმიერი არსებითი ცვლილება, BSTS განსაზღვრავს თუ არა დამატებითი სამართლებრივი რეview ამ ცვლილებებიდან საჭიროა. ლეგალური ხელახალი დასრულების შემდეგview და ბარბ ხელახლაview, BARB– მა უნდა დაამტკიცოს ან უარყოს Errata– ს დაჩქარებული შესწორება.

თუ რაიმე საცდელი დოკუმენტის განახლებას საჭიროებს, BSTS დაეხმარება ჯგუფს სატესტო დოკუმენტების განახლებაში. BTI ტესტის დოკუმენტების დამტკიცების შემდეგ, BTI ხელს შეუწყობს TCRL– ის დასრულებას და გადასცემს დოკუმენტს BQRB– ს, ასოცირებულ ICS, IXIT და Test Suite– სთან ერთად. BSTS შეაფასებს მიღების თარიღს და მიაწოდებს მას BTI TCRL– ში გამოსაყენებლად. დაჩქარებული შეცდომის კორექტირების BARB დამტკიცება, ყველა საცდელი დოკუმენტის BTI დამტკიცება (მათ შორის, Test Suite, TCRL, ICS და IXIT) და TQRL– ის BQRB დამტკიცება უნდა მოხდეს მიღების თარიღზე ან მანამდე.

BSTS შეატყობინებს ყველა წევრს დაჩქარებული შეცდომის კორექტირების დასრულებისა და ხელმისაწვდომობის შესახებ და მიღებულ იქნა შემოთავაზებული თარიღი. შვილად აყვანის თარიღი დადგენილი იქნება და ეცნობება ყველა წევრს წესდების შესაბამისად [2], ხოლო მიღების თარიღი უნდა იყოს წევრებისთვის შეტყობინების მიღებიდან არანაკლებ 14 დღე. მას შემდეგ, რაც წევრებს მიიღებენ შემოთავაზებული შემოთავაზებული თარიღის შესახებ, საბჭოს შეუძლია დაამტკიცოს ტიპოგრაფიული შეცდომების დაზუსტება დაჩქარებული შეცდომის კორექციაში შესწორებული შემოთავაზების თარიღის შესახებ დამატებითი შეტყობინების გარეშე და საჭირო 14 დღის ლოდინის გარეშე.

Bluetooth SIG საჯაროდ გახდის მიღებულ დაჩქარებულ Errata კორექციას და ამის გაკეთებას გეგმავს მიღებიდან ერთი კვირის განმავლობაში. მისი არსებობის შესახებ შეტყობინებას BSTS გადასცემს ყველა წევრს.

დაჩქარებული ერატუმის პროცესი დასრულებულია, როდესაც საბჭომ მიიღო დაჩქარებული შეცდომის კორექტირება და დასრულდა შემდეგ საქმიანობა:

• BSTS– მ მიიღო მიღებული Errata– ს დაჩქარებული შესწორება და მასთან დაკავშირებული სატესტო დოკუმენტები (საჭიროების შემთხვევაში) საჯაროდ ხელმისაწვდომი იყოს Bluetooth SIG– ზე webსაიტი.
• BSTS– მა საშუალება მისცა კვალიფიკაციის სისტემას (თუ ამას მოითხოვს ერატიუმი).
• BSTS აცნობებს ყველა წევრს მიღებული დაჩქარებული Errata კორექციის შესახებ.

ამ საქმიანობის დასრულების შემდეგ, დაიგეგმება Errata- ს კორექტირება დაზარალებულ სპეციფიკაციებში ინტეგრაციის მიზნით, როგორც დაგეგმილი სპეციფიკაციის გაუმჯობესების ნაწილი, ან მომავალი ტექნიკური უზრუნველყოფის სახით, როგორც ეს აღწერილია 7.2 ნაწილში.

7.2 სარემონტო სამუშაოების გამოყოფის პროცესი (.Z სპეციფიკაციები)

დაახლოებით ყოველწლიურად, BSTS განსაზღვრავს არსებობს დამტკიცებული ერტა (მოიხსენიება როგორც Errata Corrections), რომელიც კლასიფიცირებულია როგორც ტექნიკური / მაღალი ან ტექნიკური / კრიტიკული და რომელიც ჯერ კიდევ არ არის ჩასმული ნებისმიერი აქტიური სპეციფიკაციის ტექსტში (მაგ., მიღებული სპეციფიკაცია, რომელიც არ გაუქმებულა ან ამოღებულია). ერატის კლასიფიკაციის განმარტებებისათვის იხილეთ დანართი A. სპეციფიკაციის მფლობელს (ან WG– ს დაზუსტება სპეციფიკაციის შესანარჩუნებლად, ან BARB– ს, თუ WG არ არის დაქირავებული სპეციფიკაციის შესანარჩუნებლად) ასევე შეიძლება მოითხოვდეს აქტიური სპეციფიკაციის უფრო ადრე შენარჩუნებას, რომელშიც გათვალისწინებული იქნება ნებისმიერი დამტკიცებული ერატა. ან BSTS განსაზღვრის ან სპეციფიკაციის მფლობელის თხოვნის საფუძველზე, ტექნიკური უზრუნველყოფის გათავისუფლების პროცესი დაიწყება.

დასრულდაview ტექნიკური უზრუნველყოფის გათავისუფლების პროცესი ილუსტრირებულია შეცდომაში! საცნობარო წყარო ვერ მოიძებნა.

ტექნიკური გამოთავისუფლების პროცესის დაწყებისთანავე, BSTS სპეციფიკაციის მფლობელთან, BARB და BTI- სთან ერთად შეიმუშავებს და წარუდგენს საბჭოს გეგმას Errata Corrections- ის გამოქვეყნებულ სპეციფიკაციურ ვერსიაში ჩართვის შესახებ. შემოთავაზებულ გეგმაში მითითებული უნდა იყოს, შედის თუ არა Errata Corrections– ის სპეციფიკაციის სარემონტო გამოცემაში (მაგ., Z ვერსია) ან სპეციფიკაციის გაუმჯობესებაში, რომელიც უკვე მიმდინარეობს (ანუ XY ვერსია). შემოთავაზებულ გეგმაში უნდა იქნას გათვალისწინებული, დაემატა თუ არა რაიმე ახალი სავალდებულო მახასიათებელი მიღებული სპეციფიკაციების ვერსიებს, სავარაუდო დრო, როდესაც შემდეგი სპეციფიკაციის გაუმჯობესება იგეგმება მიღებას და სხვა ფაქტორებს შორის.

საბჭოს მიერ გეგმის დამტკიცების შემდეგ, BSTS სპეციფიკაციის მფლობელთან ერთად შეუდგება ყველა ტექნიკური / საშუალო, ტექნიკური / მაღალი და ტექნიკური / კრიტიკული შეცდომების შესწორებებს სპეციფიკაციის პროექტში, რომელსაც უწოდებენ "სარემონტო სამუშაოების გამოშვების პროექტს". სარედაქციო ან ტექნიკური / დაბალი Errata კორექტირებისთვის, თუ Errata Correction ვრცელდება სპეციფიკაციის ერთზე მეტ ვერსიაზე, BSTS, გარდა იმ შემთხვევისა, როდესაც საბჭომ სხვა რამ დააფიქსირა, ამ ერტას აერთიანებს მხოლოდ უახლესი უმაღლესი სპეციფიკაციის ვერსიაში ამ ვერსიის შემდეგი განახლებისას. . დაუშვებელია ცვლილებების შეტანა სარემონტო სამუშაოების გამოცემაში, გარდა Errata Corrections– ისა. სარემონტო სამუშაოების თითოეულმა პროექტმა უნდა დაადგინოს ყველა ჩართული Errata კორექტირება ცვლილებების თვალყურისდევნების გამოყენებით, რათა ნაჩვენები იყოს გამოქვეყნებული სპეციფიკაციის ადრე მიღებული ვერსიის შემოთავაზებული ცვლილებები.

სარემონტო გამოშვების პროექტში Errata- ს შესწორების შემოთავაზებული შემოთავაზების დრო დამოკიდებული იქნება Test Suite- ის გავლენაზე: Errata- ს ყველა შესწორება, რომელსაც არ აქვს Test Suite- ის გავლენა, შეიძლება დაუყოვნებლივ იყოს ჩართული, მაგრამ Errata- ს შესწორებები, რომლებიც გავლენას ახდენს Test Suite- ზე, იქნება დამუშავებულია ისე, რომ დრო ემთხვევა TCRL– ის განახლებას.

BTI და BSTS დაადგენენ ვადას, რომელიც მოიცავს Errata Corrections– ს Test Suite– ის გავლენას ტექნიკური უზრუნველყოფის გამოშვების პროექტში. როგორც წესი, ეს ვადაა 3 – დან 6 თვემდე TCRL– ის შემდეგი ძირითადი გამოშვების დაგეგმილი დამტკიცების თარიღამდე. Errata- ს შესწორებები Test Suite– ის ზემოქმედებით, რომელიც არ შეიცავს ვადის შეტანას, დამუშავდება შემდეგი TCRL– ის შემდეგი გამოშვების ფარგლებში. ამიტომ, თუ არ მოითხოვება უფრო ადრე გამოცემა, მაქსიმალური დრო ტექნიკური / მაღალი ან ტექნიკური / კრიტიკული შეცდომების შესწორებებისთვის, სპეციფიკაციის განახლებაში ჩასართავად, არის დაახლოებით 15-დან 18 თვემდე.

სპეციფიკაციის მფლობელმა უნდა წარმოადგინოს სარემონტო სამუშაოების გამოშვების პროექტი, რომელიც მან დაამტკიცა, როგორც საბოლოო იურიდიული განსახილველადviewრა ლეგალური ხელახალიview ძირითადად ფოკუსირდება სპეციფიკაციის შეცვლილ ნაწილებზე. ლეგალური ხელახალი დასრულების შემდეგview, სპეციფიკაციის მფლობელი და BSTS შეთანხმდებიან გამოხმაურებაზე, რომელიც უნდა შედიოდეს სარემონტო სამუშაოების შემუშავების პროექტში. თუ არსებობს რაიმე გადაუჭრელი სამართლებრივი შენიშვნები სამართლებრივი რეview ტექნიკური მომსახურების გათავისუფლების პროექტზე, სპეციფიკაციის მფლობელს შეუძლია მოითხოვოს დრო საბჭოს დღის წესრიგში, რათა მოიძიოს საბჭოს გადაწყვეტილება გადაწყვეტილების მიღების შესახებ.

პარალელურად სამართლებრივი რეviewსპეციფიკაციის მფლობელმა უნდა წარუდგინოს სარემონტო სამუშაოების პროექტი BARB– ს ხელახლაviewრა მას შემდეგ, რაც სარემონტო სამუშაოების გამოქვეყნების პროექტი წარედგინება BARB- ს, BSTS გახდის მისაწვდომს ყველა წევრისათვის ხელახლაview და აცნობოს ყველა წევრს მისი ხელმისაწვდომობის შესახებ. დასრულების შემდეგ BARB ხელახლაview, სპეციფიკაციის მფლობელი და BARB შეთანხმდებიან, რომ გამოხმაურება შეიტანოს სპეციფიკაციის პროექტში.

თუ ლეგალური ხელახლაview იწვევს რაიმე არსებით ცვლილებას, დამატებით ხელახლაview BARB– ის მიერ შეიძლება იყოს საჭირო. ანალოგიურად, თუ ბარბარე ხელახლაview შედეგად ნებისმიერი არსებითი ცვლილება, BSTS განსაზღვრავს თუ არა დამატებითი სამართლებრივი რეview ამ ცვლილებებიდან საჭიროა. ლეგალური ხელახალი დასრულების შემდეგview და ბარბ ხელახლაview, ბარბმა უნდა დაამტკიცოს ან უარყოს სარემონტო სამუშაოების გამოშვების პროექტი. თუ დამტკიცებულია BARB– ის მიერ, ეს ხდება ხმის მიცემის პროექტი.

Errata Corrections- ისთვის, რომლებიც გავლენას ახდენს ტესტის დოკუმენტებზე და სადაც შესაბამისი ტესტის errata დამუშავდება TCRL- ის მომავალი გამოცემისთვის, BSTS იმუშავებს სპეციფიკაციის მფლობელთან და BTI- სთვის ტესტირების დოკუმენტების განახლებისთვის. BTI ტესტის დოკუმენტების დამტკიცებისთანავე, BSTS შეაფასებს მიღების თარიღს და BTI– ს გადასცემს მიღებულ შემოთავაზებულ თარიღს TCRL– ში გამოყენებისთვის. BTI მიაწვდის TCRL– ს BQRB– ს, ასოცირებულ ICS– ს, IXIT– სა და Test Suite– სთან ერთად. BARB დაზუსტება დაზუსტება, BTI ყველა საცდელი დოკუმენტის დამტკიცება (მათ შორის Test Suite, TCRL, ICS და IXIT) და BQRB დამტკიცება TCRL უნდა მოხდეს მიღების თარიღზე ან მანამდე.

BSTS შეატყობინებს ყველა წევრს კენჭისყრის პროექტის და მიღების შემოთავაზებული თარიღის საბოლოო შედგენისა და ხელმისაწვდომობის შესახებ. შვილად აყვანის თარიღი დადგენილი იქნება და ეცნობება ყველა წევრს წესდების შესაბამისად, ხოლო მიღების თარიღი უნდა იყოს წევრებისთვის შეტყობინების მიღებიდან არანაკლებ 14 დღისა. მას შემდეგ, რაც წევრებს მიიღებენ შემოთავაზებული მიღების თარიღის შესახებ შეტყობინებას, საბჭოს შეუძლია დაამტკიცოს ტიპოგრაფიული შეცდომების შესწორებები კენჭისყრის პროექტში, შემოთავაზებული მიღების თარიღის შესახებ დამატებითი შეტყობინების გარეშე და საჭირო 14 დღის ლოდინის გარეშე.

შემდეგი დოკუმენტები შევსებული უნდა იყოს და საბჭოსთვის ხელმისაწვდომი უნდა იქნეს მიღებამდე:

• ხმის მიცემის პროექტი
• კენჭისყრის მონახაზის თვალყური ადევნებული ვერსია, რომელშიც ნაჩვენებია ყველა ცვლილება სპეციფიკაციის მიღებულ ვერსიაში, რომელსაც აქვს იგივე XY მნიშვნელობა (მაგ., თუ ​​კენჭისყრის პროექტი შემოთავაზებულია როგორც 1.4.2 ვერსია, ცვლილებები თვალყურს ადევნებს 1.4.1-ს. სპეციფიკაციის ვერსია)
• სპეციფიკაციის მფლობელის რეკომენდაცია მიღებული სპეციფიკაციის ნებისმიერი წინა ვერსიის (ებ) ის ცვეთის ან გაუქმების შესახებ, ასევე დასაბუთებასთან დაკავშირებით
• სამართლებრივი გადასახადებიდან დარჩენილი გადაუჭრელი სამართლებრივი საკითხების ჩამონათვალიview (ასეთის არსებობის შემთხვევაში)
• BTI– ს მიერ დამტკიცებული Test Suite, ICS და IXIT (თუ ამას მოითხოვს ტექნიკური უზრუნველყოფა)
• BTI- და BQRB დამტკიცებული TCRL (თუ ამას მოითხოვს სარემონტო სამუშაოები)
• BSTS– ის მიერ შევსებული ანგარიში BTI– სთან დაკავშირებით ინსტრუმენტის მზადყოფნის სტატუსთან დაკავშირებით (მაგ., PTS და სხვა საცდელი ხელსაწყოები, Bluetooth Launch Studio) TCRL– ში ნებისმიერი საცდელი შემთხვევის ჩათვლით, რომლებიც არ არის მხარდაჭერილი ტესტირების საშუალებით და განმარტება (თუ ამას მოითხოვს ტექნიკური მომსახურება გათავისუფლება)
• BSTS- ისა და სპეციფიკაციის მფლობელის მიერ შევსებული შვილად აყვანის ჩამონათვალი, რომელიც აჩვენებს, რომ ამ ნაწილში არსებული პროდუქტები დასრულებულია
• საბჭოს მიერ მოთხოვნილი ყველა სხვა ინფორმაცია

ტექნიკური უზრუნველყოფის გათავისუფლების პროცესი დასრულებულია, როდესაც საბჭომ მიიღო კენჭისყრის პროექტი და დასრულდა შემდეგ აქტივობები:

• BSTS– მა მიღებული სპეციფიკაცია და მასთან დაკავშირებული სატესტო დოკუმენტები (საჭიროების შემთხვევაში სარემონტო სამუშაოებით) საჯაროდ ხელმისაწვდომი გახადა Bluetooth SIG– ზე webსაიტი.
• BSTS– მა შეასრულა ადრე მიღებული სპეციფიკაციის ვერსიის ინფორმაციული ცვლილება-თვალყური ადევნეთ ყველა ცვლილებას, რომელიც ახლად მიღებულ ვერსიაშია ჩართული, ყველა წევრისთვის ხელმისაწვდომია Bluetooth SIG– ში webსაიტი.
• BSTS– მა ჩართო საკვალიფიკაციო სისტემა.
• BSTS აცნობებს ყველა წევრს მიღებული სპეციფიკაციების და დამადასტურებელი დოკუმენტების არსებობის შესახებ.

Bluetooth SIG გეგმავს დასრულების შემდეგ ამ საქმიანობის დასრულებას სპეციფიკაციის მიღებიდან ერთი კვირის განმავლობაში.

ამ საქმიანობის დასრულების შემდეგ, სპეციფიკაცია რჩება სპეციფიკაციის შენარჩუნების ფაზაში, სანამ სპეციფიკაცია არ ცდება ან ამოღებულია, როგორც ეს განმარტებულია მე -8 ნაწილში.

 

8. სიცოცხლის ბოლოს ფაზის სპეციფიკაცია

სპეციფიკაციები შეიძლება გაბათილდეს ან ამოღებულ იქნეს, როდესაც ისინი შეცვლიან უფრო ახალ ვერსიებს, დადგინდა, რომ ტექნიკურად არასაკმარისია ან სხვა მიზეზების გამო. გაუქმებული და ამოღებული სპეციფიკაციები დაარქივებულია და აღარ განახლდება. გაუქმებული და ამოღებული სპეციფიკაციები განსხვავებულად განიხილება Bluetooth საკვალიფიკაციო პროგრამაში.

ნებისმიერ წევრს, ჯგუფს ან კომიტეტს შეუძლია წარუდგინოს რეკომენდაციები BSTS– სთვის დაზუსტებული ვადის გასატარებლად, ან გაუქმდეს სპეციფიკაცია (ელ.ფოსტით

specification.manager@bluetooth.com) ნებისმიერ დროს. BSTS– ს ასევე შეუძლია რეკომენდაცია გაუწიოს სპეციფიკაციის და მასთან დაკავშირებული ვადების გაუქმებას ან გაუქმებას. BSTS რეკომენდაციას გადაუგზავნის BARB- ს და ჯგუფს ან კომიტეტს, რომელიც პასუხისმგებელია ხელახლა სპეციფიკაციის შენარჩუნებაზეview და გამოხმაურება.

BARB და პასუხისმგებელი ჯგუფი ან კომიტეტი შეაფასებენ რეკომენდაციებს სპეციფიკაციის გაუქმების ან გაუქმების მიზნით და განიხილავენ შემდეგ (არა ამომწურავ) კრიტერიუმებს:

• არსებობს სპეციფიკაციის წინა ვერსიაში ფუნქციონირება, რომელიც მოძველებულია ან არ უნდა იქნას გამოყენებული?
• დაემატა თუ არა ახალ სავალდებულო ფუნქციებს მოგვიანებით ვერსიებს?
• არსებობს ხარვეზები ადრეულ ვერსიებში, რომლებიც აფერხებს ოპერაციას ან ურთიერთქმედებას, რომლებიც გამოსწორდა შემდეგ ვერსიებში და საჭიროა მომხმარებლის არსებული სცენარების ასამაღლებლად?
• არსებობს თუ არა დამატებითი ფუნქციები შემდგომ ვერსიებში, მომხმარებლის ახალი სცენარების წინსვლისთვის?
• არის თუ არა გაუმჯობესებული გამოყენებადობა და თავსებადობა შემდეგ ვერსიებში?
• არის უსაფრთხოების გაუმჯობესება მოგვიანებით ვერსიებში?

ბარბმა და პასუხისმგებელმა ჯგუფმა ან კომიტეტმა შეიძლება შემოგთავაზონ ალტერნატიული რეკომენდაცია.

BARB- ის ან ჯგუფის ან კომიტეტის მიერ უკუკავშირის მიღების შემდეგ, რომელიც პასუხისმგებელია სპეციფიკაციის შენარჩუნებაზე, BSTS წარუდგენს რეკომენდაციას (რეკომენდაციებს) და უკუკავშირს საბჭოს განსახილველად. საბჭომ შეიძლება მოიწვიოს ჯგუფი ან კომიტეტი, რომელიც პასუხისმგებელია დაზარალებული სპეციფიკაციების შენარჩუნებაზე, შეხვდეს და განიხილოს რეკომენდაციები. საბჭო განიხილავს რეკომენდაციებს და გამოხმაურებებს და შეიძლება დაეთანხმოს ან შეცვალოს წინადადება. საბჭო მოითხოვს, რომ BSTS აცნობოს ყველა წევრს წინადადებების შესახებ, რომ გააუქმოს ან გააუქმოს სპეციფიკა (ებ) ი და მასთან დაკავშირებული ვადები (ები) 30-დღიანი ხელახალი პერიოდისთვის.view პერიოდი, რათა ყველა წევრმა უზრუნველყოს დამატებითი გამოხმაურება საბოლოო გადაწყვეტილების მიღებამდე.

საბჭო განიხილავს წევრებისგან მიღებულ უკუკავშირს. მას შემდეგ, რაც საბჭო დაადასტურებს სპეციფიკაციის ცვეთის შემცირებას ან გაუქმებას, BSTS შეატყობინებს ყველა წევრს გადაწყვეტილებისა და მასთან დაკავშირებული ვადების შესახებ.

8.1 ცვეთა

მას შემდეგ, რაც სპეციფიკაცია გაუქმდება, მოხდება შემდეგი:

• სპეციფიკაცია აღარ განახლდება.
• პასუხისმგებელი WG კვლავview ყველა გამორჩეული შეცდომა დაწერილია მოძველებული სპეციფიკაციის საწინააღმდეგოდ, რათა დადგინდეს, გამოიყენება თუ არა ისინი სხვა სპეციფიკაციებზე. Errata შეიძლება უარყოფილი იყოს errata სისტემაში და ხელახლა დაიწეროს მოქმედი სპეციფიკა (ებ) ის საწინააღმდეგოდ.
• WG ან BSTS შექმნის შეცდომებს სხვა სპეციფიკაციებში მოძველებული სპეციფიკაციების ნებისმიერი საჭირო მითითების განახლების მიზნით.
• BTI განაახლებს შესაბამის საცდელ დოკუმენტებს სპეციფიკაციის ცვეთის მითითების მიზნით.
• BSTS განაახლებს Bluetooth SIG- ს webსაიტი მითითებით გამოყენების ალტერნატიული სპეციფიკა (ებ) ის შესახებ.
• ახალი ერატის წარდგენა აღარ შეიძლება მოძველებული სპეციფიკაციის საწინააღმდეგოდ.
• მომავალში სპეციფიკაციაში მითითება არ იქნება მითითებული.
• BSTS დაარქივებს სპეციფიკაციის ვერსიას, რომელიც მონიშნულია, როგორც ამორტიზებული, რომ წევრებმა ისტორიული მიზნებისათვის მიიღონ წვდომა.

8.2 გატანა

დაზუსტების მოხსნისთანავე, გარდა ნაბიჯებისა, რომლებიც გამოიყენება ამორტიზაციისთვის, მოხდება შემდეგი:

• BTI განაახლებს შესაბამის საცდელ დოკუმენტებს სპეციფიკაციის გაუქმების მითითებით.
• BSTS განაახლებს Bluetooth SIG- ს webსაიტი მითითებით გამოყენების ალტერნატიული სპეციფიკა (ებ) ის შესახებ.
• BSTS დაარქივებს სპეციფიკაციის ვერსიას, რომელიც აღნიშნულია, როგორც გაუქმებული წევრებისთვის ისტორიული მიზნებისათვის.

საბჭომ შეიძლება აირჩიოს სპეციფიკაციის დაუყოვნებლივ გაუქმება, სპეციფიკაციის წინასწარი გაუქმების გარეშე.

 

9. თეთრი ქაღალდის პროცესი

თეთრი ფურცლები იქმნება მხოლოდ ინფორმაციული მიზნებისთვის. შემდეგი თეთრი ქაღალდის პროცესი ვრცელდება ყველა Bluetooth WG, EG, SG და კომიტეტებზე. ეს სექცია არ ვრცელდება ინფორმაციულ დოკუმენტებზე, რომლებიც გამოიყენება მხოლოდ Bluetooth SIG– ში.

ეს პროცესი ილუსტრირებულია ქვემოთ მოცემულ დიაგრამაზე 9.1.

სანამ რომელიმე ჯგუფი ან კომიტეტი დაიწყებს მუშაობას თეთრ ქაღალდზე, რომლის გამოქვეყნებასაც აპირებს Bluetooth SIG, ჯგუფი ან კომიტეტი მოამზადებს როგორც შემოთავაზებული ქარტიის განახლებას, რომელშიც კარგად იქნება განსაზღვრული შემოთავაზებული შინაარსის თეთრი ქაღალდი და თეთრი ქაღალდის წინადადების პრეზენტაცია.

თეთრი ქაღალდის წინადადების პრეზენტაცია უნდა შეიცავდეს მინიმუმ:

• თეთრი ქაღალდის საჭიროება
• თეთრი ნაშრომის შემოთავაზებული შინაარსის შეჯამება
• განმარტება, თუ რატომ არ არის რეკომენდებული შინაარსის დამატება სპეციფიკაციის ნაწილად
• განკუთვნილი აუდიტორია
• ტექნიკური უზრუნველყოფის ნებისმიერი გეგმა (ანუ შეიძლება საჭირო იყოს ამ თეთრი ქაღალდის მომდევნო გამოქვეყნებამდე სავარაუდო დრო)
• რეკომენდაციები, თუ როგორ უნდა მოგვარდეს თეთრი ქაღალდის წინა ვერსიები, ასეთის არსებობის შემთხვევაში (მაგ., დაარქივება)

ქარტიის განახლება და თეთრი ქაღალდის წინადადების პრეზენტაცია უნდა იყოს წარმოდგენილი BARB reviewრა ხელახლაview და BARB- ის მიერ ქარტიის განახლების დამტკიცებით, BSTS ქარტიის განახლებას წარუდგენს საბჭოს დასამტკიცებლად, თეთრი ქაღალდის წინადადების პრეზენტაციასთან ერთად.

თუ საბჭო დაამტკიცებს წესდების განახლებას, ჯგუფმა ან კომიტეტმა შეიძლება განაგრძოს თეთრი ფურცლის შემუშავება.

როდესაც ჯგუფმა ან კომიტეტმა დაასრულა თეთრი ქაღალდის შემუშავება, BSTS შეასრულებს სარედაქციო გამოცემასview Bluetooth- ის შემუშავების სახელმძღვანელოსთან შესაბამისობისთვის.

BSTS კომენტარების გადაწყვეტის შემდეგ, ჯგუფმა უნდა წარუდგინოს თეთრი ქაღალდი BSTS– ს ლეგალური განსახილველადviewრა ლეგალური ხელახალი დასრულების შემდეგview, ჯგუფი და BSTS შეთანხმდებიან, რომ გამოხმაურება შევა თეთრ ქაღალდზე. თუ არსებობს რაიმე გადაუჭრელი სამართლებრივი შენიშვნები სამართლებრივი რეview თეთრ ქაღალდზე ჯგუფის თავმჯდომარეს შეუძლია მოითხოვოს დრო საბჭოს დღის წესრიგში, რათა მოიძიოს საბჭოს გადაწყვეტილება გადაწყვეტილების მიღების შესახებ.

პარალელურად სამართლებრივი რეviewჯგუფმა უნდა წარუდგინოს თეთრი ქაღალდი BARB– ს ხელახლაviewრა როგორც მათი ხელახალი ნაწილიview, BARB- მ შეიძლება რეკომენდაცია გაუწიოს, უნდა ამოიღონ თუ არა თეთრი ქაღალდის ნაწილი თეთრი ქაღალდიდან და ჩაერთოს სპეციფიკაციაში მე –3 ნაწილში შემდგომი პროცესის შემდგომ.viewრა დასრულების შემდეგ BARB ხელახლაview, ჯგუფი და BARB შეთანხმდებიან, რომ გამოხმაურება შევა თეთრ ქაღალდზე.

თუ ლეგალური ხელახლაview იწვევს რაიმე არსებით ცვლილებას, დამატებით ხელახლაview BARB– ის მიერ შეიძლება იყოს საჭირო. ანალოგიურად, თუ ბარბარე ხელახლაview შედეგად ნებისმიერი არსებითი ცვლილება, BSTS განსაზღვრავს თუ არა დამატებითი სამართლებრივი რეview ამ ცვლილებებიდან საჭიროა. ლეგალური ხელახალი დასრულების შემდეგview და ბარბ ხელახლაview, ბარბმა უნდა დაამტკიცოს ან უარყოს თეთრი ქაღალდი.

მას შემდეგ, რაც BARB დაამტკიცებს თეთრ ფურცელს, BARB– ის მიერ დამტკიცებული თეთრი ქაღალდი საავტორო ჯგუფის ან კომიტეტის მიერ წარედგინება საბჭოს დასამტკიცებლად.

თეთრი ქაღალდის პროცესი დასრულებულია, როდესაც საბჭომ დაამტკიცა თეთრი ქაღალდი და დასრულდა შემდეგი საქმიანობის დამტკიცების შემდეგ:

• BSTS– მა დაამტკიცა თეთრი ქაღალდი საჯაროდ ხელმისაწვდომი Bluetooth SIG– ზე webსაიტი.
• BSTS აცნობებს დამტკიცებული თეთრი ქაღალდის ყველა წევრს.
• თუ თეთრი ქაღალდი წარმოადგენს არსებული თეთრი ფურცლის გაუმჯობესებას, BSTS დაარქივებს თეთრი ფურცლის ვერსიას, რომლითაც წევრები შეძლებენ ისტორიული მიზნების მისაღწევად.

Bluetooth SIG გეგმავს დამტკიცების შემდგომი აქტივობების დასრულებას თეთრი ქაღალდის დამტკიცებიდან ერთი კვირის განმავლობაში.

 

10. ცნობები

მითითებული Bluetooth დოკუმენტები ხელმისაწვდომია Bluetooth– დან webსაიტი http://www.bluetooth.com.

1. Bluetooth- ის შედგენის სახელმძღვანელო მითითებები (ხელმისაწვდომია სამუშაო ჯგუფის შაბლონების და დოკუმენტების გვერდზე, მისამართზე: https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
2. Bluetooth SIG, Inc.– ის წესდება (ხელმისაწვდომია მმართველი დოკუმენტების გვერდზე, მისამართზე: https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
3. Bluetooth სპეციფიკაციის Errata პროცესის დოკუმენტი (ხელმისაწვდომია სამუშაო ჯგუფის შაბლონების და დოკუმენტების გვერდზე, გვერდზე https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
4. სამუშაო ჯგუფის პროცესის დოკუმენტი (ხელმისაწვდომია სამუშაო ჯგუფის შაბლონებისა და დოკუმენტების გვერდზე, გვერდზე https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
5. ტესტის სტრატეგია და ტერმინოლოგია დასრულდაview დოკუმენტი (ხელმისაწვდომია საკვალიფიკაციო გამოცდის მოთხოვნების გვერდზე, მისამართზე https://www.bluetooth.com/specifications/qualification-test-requirements)
6. BTI სპეციფიკაცია Review პროცესის ჩამონათვალი (ხელმისაწვდომია სამუშაო ჯგუფის შაბლონებისა და დოკუმენტების გვერდზე, მისამართზე: https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
7. Bluetooth SIG მინიჭებული ნომრები (https://www.bluetooth.com/specifications/assigned-numbers)
8. სამუშაო ჯგუფის შაბლონები და დოკუმენტები (ხელმისაწვდომია სამუშაო ჯგუფის შაბლონების და დოკუმენტების გვერდზე, გვერდზე https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
9. GATT სპეციფიკაციის დამატება (GSS) (ხელმისაწვდომია GATT სპეციფიკაციების გვერდზე, მისამართზე: https://www.bluetooth.com/specifications/gatt)
10. შეიტანეთ იდეა ახალი სპეციფიკაციისთვის https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

 

11. აბრევიატურა და აბრევიატურა

ცხრილი A: აბრევიატურა და აბრევიატურა

 

დანართი A - ერატის სიმძიმის კლასიფიკაცია

ამ დანართში შეჯამებულია სიმძიმის კლასიფიკაციის სახელმძღვანელო მითითებები სპეციფიკაციის ერატის შესახებ. ეს ცხრილი დაემატება EPD– ის სამომავლო გადასინჯვას და შემდეგ ეს სექცია წაიშლება.

 

წაიკითხეთ მეტი ამ სახელმძღვანელოს შესახებ და ჩამოტვირთეთ PDF:

სპეციფიკაციის მართვის პროცესის დოკუმენტი (SMPD) - ოპტიმიზებული PDF
სპეციფიკაციის მართვის პროცესის დოკუმენტი (SMPD) - ორიგინალი PDF

გაქვთ შეკითხვები თქვენს სახელმძღვანელოსთან დაკავშირებით? გამოაქვეყნეთ კომენტარებში!

ცნობები

• მომხმარებლის სახელმძღვანელო