Tài liệu Quy trình Quản lý Đặc điểm kỹ thuật (SMPD)

Tài liệu này, bất kể tiêu đề hoặc nội dung của nó, không phải là Thông số kỹ thuật Bluetooth tuân theo giấy phép được cấp bởi Bluetooth SIG Inc. (“Bluetooth SIG”) và các thành viên của nó theo Thỏa thuận cấp phép bằng sáng chế / bản quyền Bluetooth và Thỏa thuận cấp phép nhãn hiệu Bluetooth.

TÀI LIỆU NÀY ĐƯỢC CUNG CẤP “NGUYÊN TRẠNG” VÀ BLUETOOTH SIG, CÁC THÀNH VIÊN CỦA NÓ VÀ NHỮNG NGƯỜI LIÊN QUAN ĐẾN CỦA HỌ KHÔNG TUYÊN BỐ HOẶC BẢO ĐẢM VÀ TỪ CHỐI TẤT CẢ CÁC BẢO ĐẢM, RÕ RÀNG HOẶC NGỤ Ý, BAO GỒM BẤT KỲ BẢO ĐẢM NÀO VỀ KHẢ NĂNG, MỤC ĐÍCH, MỤC TIÊU RẰNG NỘI DUNG CỦA TÀI LIỆU NÀY KHÔNG CÓ LỖI.

NGOÀI RA KHÔNG BỊ CẤM BẰNG PHÁP LUẬT, BLUETOOTH SIG, CÁC THÀNH VIÊN CỦA NÓ VÀ CÁC THÀNH VIÊN CỦA HỌ TỪ BỎ MỌI TRÁCH NHIỆM PHÁP LÝ PHÁT SINH NGOÀI HOẶC LIÊN QUAN ĐẾN VIỆC SỬ DỤNG TÀI LIỆU NÀY VÀ BẤT KỲ THÔNG TIN NÀO CÓ TRONG TÀI LIỆU NÀY, BAO GỒM CÁC TIẾN ĐỘ, DOANH THU HOẶC DOANH THU SỰ CỐ GẮNG HOẶC ĐỐI VỚI CÁC THIỆT HẠI ĐẶC BIỆT, ĐÚNG, HẬU QUẢ, BẤT CỨ HOẶC VÔ CÙNG BAO NHIÊU NGUYÊN NHÂN VÀ LIÊN QUAN ĐẾN LÝ THUYẾT VỀ TRÁCH NHIỆM PHÁP LÝ VÀ NGAY CẢ NẾU BLUETOOTH SIG, CÁC THÀNH VIÊN CỦA NÓ, HOẶC NHỮNG NGƯỜI LIÊN LẠC CỦA HỌ ĐÃ CÓ KHẢ NĂNG TĂNG CƯỜNG.

Tài liệu này là độc quyền của Bluetooth SIG. Tài liệu này có thể chứa hoặc đề cập đến chủ đề là tài sản trí tuệ của Bluetooth SIG và các thành viên của nó. Việc cung cấp tài liệu này không cấp bất kỳ giấy phép nào cho bất kỳ tài sản trí tuệ nào của Bluetooth SIG hoặc các thành viên của nó.

Tài liệu này có thể thay đổi mà không cần thông báo trước.

1. Giới thiệu

Tài liệu Quy trình Quản lý Đặc điểm kỹ thuật (SMPD) mô tả các quy trình mà đặc điểm kỹ thuật tác giả và táiviewers phải tuân theo để phát triển các thông số kỹ thuật mới và cải tiến các thông số kỹ thuật hiện có (nghĩa là thêm hoặc bớt chức năng hoặc thay đổi chức năng cụ thể trong một thông số kỹ thuật đã được chấp nhận), để duy trì các thông số kỹ thuật đã được chấp nhận và quản lý thời hạn sử dụng của các thông số kỹ thuật đã được thông qua. Ngoài ra, tài liệu này mô tả quá trình tạo, táiviewing, và phê duyệt sách trắng.

Có sự khác biệt trong quá trình phát triển đặc điểm kỹ thuật giữa việc phát triển các thông số kỹ thuật mới và cải tiến các thông số kỹ thuật hiện có do sự khác biệt vốn có trong phạm vi của các nhiệm vụ đó; những khác biệt đó được đánh dấu trong tài liệu này.

Quá trình phát triển đặc điểm kỹ thuật bao gồm:

Giai đoạn Yêu cầu (được mô tả trong Phần 3) để xác định các yêu cầu chức năng

Một Giai đoạn Phát triển (được mô tả trong Phần 4) để phát triển và táiview thông số kỹ thuật
Giai đoạn xác thực (được mô tả trong Phần 5) để xác nhận các thông số kỹ thuật bằng phương pháp thử nghiệm Nguyên mẫu có thể tương tác (IOP)

Giai đoạn Thông qua / Phê duyệt (được mô tả trong Phần 6) để trình bày các thông số kỹ thuật cho Hội đồng quản trị Bluetooth SIG (BoD) để thông qua / phê duyệt

Tài liệu Quy trình Errata Đặc điểm kỹ thuật (EPD) [3] mô tả quy trình đề xuất và táiviewnhập errata đặc điểm kỹ thuật, và phê duyệt chúng dưới dạng Sửa lỗi Errata (như được định nghĩa trong Điều luật [2]) đối với các thông số kỹ thuật được thông qua. Trừ khi có ghi chú khác, tất cả các tham chiếu đến errata trong SMPD này có nghĩa là errata đặc tả.

1.1 Quyền ưu tiên

Quy chế của Bluetooth SIG, Inc. (Điều lệ) và các thỏa thuận thành viên [2] được ưu tiên hơn bất kỳ nội dung xung đột nào trong các tài liệu đó và SMPD. Bất kể điều gì trong tài liệu này, Hội đồng quản trị vẫn giữ quyền quyết định và thẩm quyền cuối cùng để hành động và đưa ra quyết định ngay cả khi những hành động và quyết định đó không tuân theo hoặc mâu thuẫn với bất kỳ điều gì trong tài liệu này và không có điều gì trong tài liệu này hạn chế hoặc hạn chế thẩm quyền độc lập của Hội đồng quản trị và tùy ý.

Nếu có bất kỳ xung đột nào giữa văn bản trong SMPD và các số liệu, văn bản sẽ được ưu tiên.

1.2 Các nhóm và ủy ban được tham chiếu

Các loại nhóm sau được tham chiếu trong tài liệu này: Nhóm nghiên cứu (SG), Nhóm chuyên gia (EG) và Nhóm làm việc (WG). WG cũng có thể có một nhóm con báo cáo cho WG. Tương tự, các loại ủy ban sau được tham chiếu trong tài liệu này: Bluetooth Architectural Review Bo mạch (BARB), Kiểm tra Bluetooth và Khả năng tương tác (BTI), và Chứng chỉ Bluetooth Review Hội đồng quản trị (BQRB). Tài liệu này cũng đề cập đến Nhân viên kỹ thuật Bluetooth SIG (BSTS) và BoD.

1.3 Ủy ban táiviews và phê duyệt

Một ủy ban lạiview làview được tiến hành bởi các thành viên của một ủy ban (thường là 3 thành viên) để cung cấp phản hồi trong một thời gian cụ thể (thường là 2-3 tuần), tuy nhiênview thời gian có thể thay đổi tùy thuộc vào độ dài và độ phức tạp của tài liệu và các ưu tiên khác trong ủy ban. Nhóm yêu cầu táiview và ủy ban tiến hành táiview mỗi người đồng ý về khoảng thời gian củaview. Các thành viên nhóm và ủy ban sử dụng các công cụ Bluetooth SIG để thông báo và ghi lại điểm bắt đầu và kết thúc của quá trìnhview. Nhóm thường sẽ xử lý phản hồi của ủy ban khi nhận được phản hồi. Khi ủy ban táiview hết thời gian, nhóm hoàn thành việc giải quyết phản hồi của ủy ban và cũng nên xem xét bất kỳ trường hợp nào đến muộnview phản hồi lưu ý rằng tài liệu có thể được ủy ban phê duyệt sau đó.

Sự chấp thuận của ủy ban đạt được bằng một cuộc bỏ phiếu của các thành viên ủy ban tuân theo Tài liệu Quy trình của Nhóm làm việc [4].

1.4 Thông báo cho các thành viên và khả năng tiếp cận tài liệu

Tất cả các thông báo được cung cấp cho các thành viên theo tài liệu này có thể được cung cấp qua email, chẳng hạn như bản cập nhật kỹ thuật định kỳ. Các thông báo sẽ được cung cấp cho tất cả các thành viên sẽ được gửi đến tất cả các thành viên đang hoạt động (tức là khi tư cách thành viên chưa bị đình chỉ, chấm dứt hoặc bị thu hồi). Khi thông báo được gửi qua email, chúng sẽ được gửi đến địa chỉ email được biết đến gần đây nhất (như được phản ánh trong hồ sơ hiện tại của Bluetooth SIG) của từng cá nhân đã đăng ký theo tài khoản thành viên của công ty thành viên và người không chọn không nhận thông báo qua email. Không có nội dung nào trong tài liệu này làm thay đổi các nghĩa vụ hoặc yêu cầu của Bluetooth SIG liên quan đến việc cung cấp thông báo theo Quy chế hoặc bất kỳ thỏa thuận nào khác giữa Bluetooth SIG và bất kỳ thành viên nào.

Bất cứ nơi nào tài liệu này đề cập đến một webtrang web có thể truy cập cho tất cả các thành viên, điều này đề cập đến khả năng truy cập cho những cá nhân có tài khoản Bluetooth SIG đang hoạt động. Các thành viên chưa có tài khoản đang hoạt động có thể tạo tài khoản qua Bluetooth SIG webđịa điểm.

1.5 Mẫu

Đối với mỗi loại tài liệu (ví dụ: thông số kỹ thuật, sách trắng, tài liệu kiểm tra) được đề cập trong SMPD này, Bluetooth SIG cung cấp một mẫu. Mẫu phải được sử dụng làm cơ sở cho mỗi tài liệu được tạo ra phù hợp với SMPD này. Nếu không sử dụng đúng mẫu có thể dẫn đến tài liệu không được duyệt. Các mẫu có sẵn trên Bluetooth SIG webtrang web [8].

1.6 Các loại thông số kỹ thuật

Có một số loại thông số kỹ thuật Bluetooth SIG. Theo thứ bậc, tất cả các thông số kỹ thuật phụ thuộc vào Thông số kỹ thuật cốt lõi của Bluetooth. Các thông số kỹ thuật như chuyên nghiệp truyền thốngfileNS; giao thức truyền thống; và chuyên nghiệp dựa trên GATTfiles, các dịch vụ dựa trên GATT và các giao thức dựa trên GATT đều phụ thuộc vào các tính năng trong Đặc điểm kỹ thuật cốt lõi. Các thông số kỹ thuật khác, chẳng hạn như thông số kỹ thuật của Mô hình lưới, phụ thuộc vào Mesh Profile đặc điểm kỹ thuật mà lần lượt phụ thuộc vào Đặc điểm kỹ thuật cốt lõi.

Đặc tả Bổ sung Đặc điểm kỹ thuật cốt lõi (CSS) xác định các kiểu dữ liệu, định dạng dữ liệu và các chuyên gia phổ biếnfile và mã lỗi dịch vụ được sử dụng bởi Đặc điểm kỹ thuật chính và các thông số kỹ thuật khác và bản thân nó không xác định bất kỳ hành vi nào.

Thông số kỹ thuật của GATT Specification Supplement (GSS) xác định các định dạng đặc trưng và mô tả được sử dụng bởi Profiles và Dịch vụ và bản thân nó không xác định bất kỳ hành vi nào.
Đặc tả Mesh Device Properties (MDP) xác định các thuộc tính lưới được Mesh Pro sử dụngfile và các thông số kỹ thuật của Mô hình lưới và bản thân nó không xác định bất kỳ hành vi nào.

2. Kết thúcview

Phần này cung cấp một hơnview của các quy trình và không nhằm mục đích bao gồm tất cả các chi tiết.

Hình 2.1 cho thấy sáu giai đoạn chính tạo nên Quy trình Quản lý Đặc điểm kỹ thuật.

Bốn giai đoạn đầu tiên xảy ra trong quá trình phát triển đặc tả và bao gồm Giai đoạn Yêu cầu (Phần 3), Giai đoạn Phát triển (Phần 4), Giai đoạn Xác thực (Phần 5) và Giai đoạn Tiếp nhận / Phê duyệt (Phần 6). Tiếp theo là hai giai đoạn sau khi áp dụng: Giai đoạn Duy trì Thông số kỹ thuật (Phần 7) và Giai đoạn Kết thúc Vòng đời của Thông số kỹ thuật (Phần 8).

Hình 2.2 minh họa chi tiết của bốn giai đoạn trong quá trình phát triển đặc tả. Các hộp màu xám cho biết các phân phối chính cho mỗi giai đoạn. Các ô màu cam tóm tắt các mốc quá trình.

Trong Giai đoạn Yêu cầu (được mô tả trong Phần 3), một đề xuất bắt đầu công việc mới (Đề xuất Công việc Mới (NWP)) bắt đầu quá trình phát triển đặc tả bằng cách xác định các kịch bản người dùng sẽ được kích hoạt nếu công việc mới tiếp tục. Nếu NWP được chấp thuận, một nhóm được chỉ định sẽ tạo Tài liệu Yêu cầu Chức năng (FRD). Khi FRD được chấp thuận và được chỉ định cho một nhóm, Giai đoạn Phát triển sẽ bắt đầu.

Trong Giai đoạn Phát triển (được mô tả trong Phần 4), việc phát triển đặc điểm kỹ thuật tiến triển thông qua một chuỗi cáctages (0.5 / DIPD đến 0.9 / CR) đạt đến đỉnh điểm là bản thảo hoàn chỉnh của thông số kỹ thuật. Thông số kỹ thuật 0.9 / CR được cung cấp cho tất cả các thành viên, sau đó được đệ trình lên Hội đồng quản trị, người xem xét thông số kỹ thuật để phê duyệt. Sau khi được chấp thuận, Giai đoạn Xác thực bắt đầu.

Trong Giai đoạn xác thực của quá trình phát triển thông số kỹ thuật (được mô tả trong Phần 5), thông số kỹ thuật 0.9 / CR được BoD phê duyệt được cung cấp cho tất cả các thành viên đểview và xác thực, và Thành viên Review được bắt đầu. Việc xác thực được thực hiện thông qua kiểm tra khả năng tương tác (IOP) giữa các nguyên mẫu được xây dựng bởi các thành viên. Sau khi kiểm tra IOP hoàn tất (nếu được yêu cầu đối với đặc điểm kỹ thuật) và BARB phê duyệt báo cáo kiểm tra IOP, thì Giai đoạn Áp dụng / Phê duyệt bắt đầu.

Trong Giai đoạn Tiếp nhận / Phê duyệt (được mô tả trong Phần 6), đặc điểm kỹ thuật và các tài liệu kiểm tra liên quan được hoàn thiện; Các phê duyệt BARB, BQRB và BTI được nhận; và gói thông số kỹ thuật cuối cùng được đệ trình cho Hội đồng quản trị, người xem xét thông số kỹ thuật để thông qua (tức là phê duyệt cuối cùng).

Một thông số kỹ thuật có thể cần quay lại giai đoạn trước đó hoặc stage nếu những thay đổi đáng kể được thực hiện. Trong một số trường hợp, cũng có thể từ bỏ một phần của giai đoạn như được mô tả trong Phần 4.4.

Giai đoạn Bảo trì Thông số kỹ thuật (được mô tả trong Phần 7) bắt đầu sau khi một thông số kỹ thuật được Hội đồng quản trị thông qua. Trong giai đoạn này, các lỗi tiềm ẩn được tìm thấy trong một thông số kỹ thuật đã được thông qua được báo cáo và đánh giá, và (nếu cần) Các sửa lỗi Errata được thực hiện đối với thông số kỹ thuật. Giai đoạn Bảo trì Thông số kỹ thuật tiếp tục cho đến khi thông số kỹ thuật không được chấp nhận hoặc bị thu hồi (xem Giai đoạn kết thúc vòng đời của Thông số kỹ thuật trong đoạn sau).

Giai đoạn cuối của đặc điểm kỹ thuật (được mô tả trong Phần 8) mô tả quy trình không dùng nữa và hủy bỏ các thông số kỹ thuật được chấp nhận.

3. Giai đoạn Yêu cầu

Giai đoạn Yêu cầu bắt đầu với một NWP (trong đó nêu mong muốn bắt đầu công việc trên một hoặc nhiều tình huống của người dùng) hoặc sau khi xác định rằng công việc mới mong muốn đã được quy định trong điều lệ WG của họ. Nếu một WG muốn bắt đầu công việc mới mà họ tin rằng đã nằm trong phạm vi điều lệ WG của mình, thì WG phải tuân theo quy trình được xác định trong Phần 3.1 để tiến hành trực tiếp phát triển một FRD. Đối với tất cả các hạng mục công việc khác, WG phải tuân theo quy trình được xác định trong Mục 3.2. FRD xác định phạm vi của các yêu cầu chức năng được sử dụng để xây dựng các thông số kỹ thuật trong Giai đoạn Phát triển. Giai đoạn Yêu cầu được minh họa trong Hình 3.1.

3.1 Công việc mới theo điều lệ WG

Khi một WG muốn bắt đầu công việc mới và tin tưởng một cách hợp lý rằng chức năng mà họ muốn bổ sung đã nằm trong phạm vi điều lệ của WG, WG có thể bắt đầu hoạt động trên FRD, miễn là họ phải thông báo ngay cho BARB. WG sẽ bao gồm trong thông báo của mình cho BARB một mô tả về công việc mới được đề xuất và một bản sao của điều lệ WG với ngôn ngữ được đánh dấu cho phép họ bắt đầu công việc mới.

Nếu BARB từ chối phân tích của WG, WG phải ngừng công việc trên FRD và tiếp tục quy trình NWP được nêu trong Phần 3.2. Nếu BARB chấp thuận phân tích của WG, WG sẽ ngay lập tức thông báo cho BSTS (qua email tới specification.manager@bl Bluetooth.com) và BSTS sẽ thêm mục đó vào chương trình nghị sự tiếp theo của HĐQT.

WG sẽ bao gồm trong thông báo của mình cho BSTS cùng thông tin mà nó đã cung cấp cho BARB. Nếu BoD từ chối phân tích của WG, WG phải dừng công việc của FRD và tiếp tục với quy trình NWP được nêu trong Phần 3.2. Nếu Hội đồng Quản trị chấp thuận phân tích của WG, WG có thể tiếp tục làm việc về FRD như đã nêu trong Phần 3.3.

3.2 Đề xuất công việc mới (NWP)

Bất kỳ thành viên nào, WG, SG hoặc EG đều có thể tạo và gửi NWP (thông qua Bluetooth SIG webtrang web [10]). Một NWP tối thiểu phải bao gồm thông tin về những điều sau đây bằng cách sử dụng mẫu chính thức được cung cấp trong [8]:

Tình huống người dùng
Thành viên cam kết phát triển FRD và trong (các) lĩnh vực nào (ví dụ: Người đóng góp, Tác giả, Táiviewer, Tạo mẫu)
Đề xuất lãnh đạo công việc FRD
Đề xuất phân công nhóm cho công việc FRD
Địa chỉ email của (các) tác giả chính

Ghi chú: Hướng dẫn về quy trình NWP có sẵn trên Bluetooth SIG webtrang web [10].

BSTS sẽ thực hiện các nhiệm vụ sau trong quá trình phát triển NWP:

Cung cấp cho (các) tác giả xác nhận đã nhận (thường trong vòng bảy ngày theo lịch kể từ ngày nhận) và phác thảo các bước tiếp theo.
Nếu cần, hãy làm việc với (các) tác giả để NWP rõ ràng và đầy đủ. Điều này có thể yêu cầu một số lần lặp lại NWP.
Nếu NWP chứa các tuyên bố về lỗi trong các thông số kỹ thuật Bluetooth được thông qua, hãy làm việc với (các) tác giả để file các mục nhập vào hệ thống errata.
Nếu nhận thấy rằng NWP có khả năng sao chép tác phẩm đang thực hiện hoặc đã hoàn thành, hãy thông báo cho (các) tác giả của tác phẩm khác để họ đánh giá.
Đăng NWP lên NWP webtrang web có thể truy cập cho tất cả các thành viên.

Thông báo cho tất cả các thành viên rằng NWP có sẵn để táiview và liệu có cần thêm cam kết của thành viên để phát triển FRD hay không.

Các thành viên có thể liên hệ với (các) tác giả để đặt câu hỏi hoặc cung cấp phản hồi về NWP.

Ít nhất ba công ty thành viên phải cam kết tham gia vào việc hoàn thành FRD kết quả để NWP trở thành ứng cử viên cho sự chấp thuận của Hội đồng quản trị và ít nhất một công ty thành viên phải là thành viên Cộng tác hoặc Người thăng tiến. Sau khi Hội đồng quản trị chấp thuận NWP, Hội đồng quản trị sẽ chỉ định NWP cho một nhóm con WG gồm tất cả các thành viên hiện có hoặc SG để làm việc trên FRD (được mô tả trong Phần 3.3). Nếu một nhóm con WG hoặc SG thích hợp không tồn tại, một nhóm có thể được tạo.

Đối với các NWP có đủ cam kết thành viên, BSTS sẽ thực hiện các nhiệm vụ bổ sung sau:

Ít nhất 13 ngày trước khi NWP được đề xuất phê duyệt bởi Hội đồng quản trị, hãy thông báo cho BARB và nhóm mà NWP được đề nghị chỉ định, về việc NWP đang chờ phê duyệt. Điều này được thực hiện để tạo cơ hội cho phản hồi trong các lĩnh vực như nhóm được đề xuất, liệu NWP đã được bao phủ bởi công việc hiện có chưa, v.v.
Gửi NWP đã hoàn chỉnh cho Hội đồng quản trị.

Nếu NWP được đệ trình bởi các thành viên không liên kết với một nhóm, hãy sắp xếp để một trong các thành viên trình bày NWP cho Hội đồng quản trị.

Nếu NWP do một nhóm đệ trình, hãy sắp xếp để người chủ trì nhóm trình bày NWP cho Hội đồng quản trị.
Mời chủ tịch BARB và các chủ tọa của nhóm mà NWP được đề nghị phân công, tham gia cuộc họp của Hội đồng quản trị.
Nếu NWP được Hội đồng quản trị phê duyệt và chỉ định, hãy thông báo cho nhóm mà nó được chỉ định; các tác giả); các thành viên được xác định trong NWP cam kết phát triển FRD tương ứng; và nếu NWP được đề xuất bởi một nhóm, thì nhóm kết quả và các bước tiếp theo.

Sau khi NWP được Hội đồng quản trị phê duyệt, hãy cập nhật trạng thái trên NWP webđịa điểm.

Bất kỳ NWP nào cũng có thể bị từ chối bởi Hội đồng Quản trị theo quyết định của mình, đối vớiample, do hạn chế về nguồn lực, nếu công việc đã được hoàn thành đầy đủ, công việc sẽ nằm ngoài phạm vi của các tài liệu quản lý của Bluetooth SIG (ví dụ: Giao diện lập trình ứng dụng (API)) [2], hoặc nếu công việc được đề xuất nên filed như một erratum. Nếu NWP bị từ chối, BSTS sẽ thông báo cho (các) tác giả, các thành viên được xác định trong NWP là cam kết phát triển FRD tương ứng, và nếu NWP được đề xuất bởi một nhóm, thì nhóm đó. Thông báo sẽ bao gồm bất kỳ lý do nào cho việc từ chối. (Các) tác giả, các thành viên cam kết hoặc nhóm có thể yêu cầu thời gian trong chương trình nghị sự của HĐQT để khiếu nại việc từ chối.

Nếu một thành viên hoặc nhóm muốn đề xuất loại bỏ một tính năng khỏi một thông số kỹ thuật đã được thông qua, nhóm hoặc thành viên đó phải chuẩn bị một NWP. NWP phải bao gồm phân tích về tác động mà việc loại bỏ sẽ có đối với khả năng tương thích ngược và khả năng tương tác, bao gồm phân tích tác động đối với các trường hợp thử nghiệm.

NWP không bắt buộc đối với các cải tiến đối với thông số kỹ thuật CSS, GSS hoặc MDP: thông thường, các cập nhật đối với thông số kỹ thuật CSS, GSS hoặc MDP là kết quả của việc cập nhật các thông số kỹ thuật khác có NWP của riêng chúng.

3.3 Tài liệu Yêu cầu Chức năng (FRD)

FRD xác định các yêu cầu chức năng để kích hoạt các kịch bản người dùng. Một FRD tối thiểu phải bao gồm thông tin về những điều sau bằng cách sử dụng mẫu chính thức được cung cấp trong [8]:

Tình huống người dùng
Các yêu cầu chức năng dựa trên các tình huống của người dùng
Thành viên cam kết phát triển (các) đặc điểm kỹ thuật kết quả
Hỗ trợ nguyên mẫu tùy chọn bởi các thành viên cho các vai trò dự kiến
WG khuyến nghị để phát triển (các) thông số kỹ thuật kết quả

Phát triển FRD

FRD được tạo bởi nhóm con WG toàn thành viên được chỉ định hoặc các thành viên SG với sự hỗ trợ biên tập từ BSTS. Bất kỳ thành viên nào quan tâm đến việc tham gia phát triển FRD đều có thể tham gia nhóm.

FRD phải chỉ ra cam kết từ ít nhất hai (mặc dù ba công ty được khuyến khích) các công ty thành viên cấp Liên kết hoặc Quảng cáo tham gia vào việc phát triển đặc điểm kỹ thuật kết quả. WG hoặc SGs đệ trình FRD phải cố gắng đạt được sự hỗ trợ rộng rãi từ các công ty thành viên trong nhóm đại diện cho phân khúc ngành mục tiêu dự kiến được xác định trong FRD.

Chức năng mới được đề xuất trong FRD phải được hỗ trợ trên nhiều phương tiện và thiết bị hiện có nhất có thể. Điều này bao gồm, đối với người yêu cũample, hỗ trợ chuyên nghiệp dựa trên GATTfilevà các dịch vụ trên cả vận chuyển Tốc độ cơ bản / Tốc độ dữ liệu mở rộng (BR / EDR) và vận chuyển Bluetooth năng lượng thấp (LE). Nếu chức năng mới thiếu sự hỗ trợ đầy đủ của thành viên đối với phương tiện vận chuyển, ví dụampDo thiếu cam kết của thành viên trong việc xác định việc sử dụng phương tiện vận chuyển hoặc có khả năng không đủ số lượng nền tảng thử nghiệm IOP cho một hoặc nhiều vai trò, hỗ trợ về phương tiện vận chuyển đó có thể bị loại trừ khỏi FRD.

Trừ khi có lý do khác, chức năng mới, chuyên nghiệpfiles, và các dịch vụ phải tuân thủ các yêu cầu tương thích ngược được mô tả trong Phần 3.3.2.

WG hoặc SG phải gửi FRD cho BARB để táiview và phê duyệt. BARB phải chấp thuận hoặc từ chối FRD dựa trên đánh giá kỹ thuật của nó. Nếu được BARB chấp thuận, FRD sẽ được cung cấp cho tất cả các thành viên và thông báo về tính khả dụng của nó sẽ được phát hành bởi BSTS.

FRD không bắt buộc đối với các cải tiến đối với thông số kỹ thuật CSS, GSS hoặc MDP: thông thường, các cập nhật đối với thông số kỹ thuật CSS, GSS hoặc MDP là kết quả của việc cập nhật các thông số kỹ thuật khác có FRD riêng của chúng.

Yêu cầu tương thích ngược

Khả năng tương thích ngược cho BR / EDR

Đối với hoạt động BR / EDR, yêu cầu tương thích ngược được xác định là tương thích với phần BR / EDR của Đặc điểm kỹ thuật cốt lõi Bluetooth v1.1 trở lên.

Khả năng tương thích ngược cho Bluetooth Low Energy

Đối với hoạt động LE, yêu cầu tương thích ngược được định nghĩa là tương thích với phần LE của Đặc điểm kỹ thuật cốt lõi Bluetooth v4.0 trở lên.

Khả năng tương thích ngược cho các thông số kỹ thuật khác với Thông số kỹ thuật cốt lõi

Đối với các thông số kỹ thuật khác với Thông số kỹ thuật cốt lõi của Bluetooth, phải duy trì khả năng tương thích ngược của một phiên bản nhất định với tất cả các phiên bản trước đó có cùng số phiên bản chính. Cho người yêu cũample, phiên bản 1.3 phải tương thích với các phiên bản 1.2, 1.1 và 1.0, nhưng phiên bản 2.0 có thể không tương thích với các phiên bản 1.0, 1.1, 1.2 và 1.3. Lưu ý rằng sự gia tăng số phiên bản chính của Thông số kỹ thuật cốt lõi không có nghĩa là thiếu khả năng tương thích ngược với các phiên bản trước.

Miễn các yêu cầu tương thích ngược

WG hoặc SG có thể đề xuất loại bỏ chức năng cụ thể khỏi yêu cầu tương thích ngược nếu cung cấp được lý do. Cho người yêu cũample, nếu chức năng được hiển thị là có tỷ lệ chấp nhận thị trường thấp hoặc do các vấn đề về khả năng tương tác, tốt hơn là loại bỏ hoặc thay thế chức năng hơn là sửa đổi chức năng. WG hoặc SG phải bao gồm bất kỳ trường hợp miễn trừ khả năng tương thích ngược nào trong FRD, được BARB phê duyệt sau khi FRD phê duyệt. Bất kỳ trường hợp miễn trừ nào được BARB chấp thuận sẽ được trình lên Hội đồng Quản trị để phê duyệt ở mức 0.9 / CR Stage.

3.4 Điều lệ của Nhóm công tác

Khi BARB phê duyệt một FRD được đề xuất chỉ định cho một WG hiện có, WG đó phải chuẩn bị bản cập nhật dự thảo cho điều lệ của mình để thêm chức năng mới vào phạm vi (trừ khi trước đó Hội đồng quản trị đã chấp thuận phân tích của WG rằng bản cập nhật điều lệ WG không yêu cầu). Tuy nhiên, khi BARB chấp thuận một FRD được đề xuất chỉ định cho một WG mới, BARB và các thành viên quan tâm đến việc phát triển chức năng được nêu trong FRD phải chuẩn bị dự thảo điều lệ cho một WG mới với chức năng mới được bao gồm trong phạm vi điều lệ .

Sau khi điều lệ WG mới hoặc cập nhật được chuẩn bị, nó phải được đệ trình cho BARB để táiview và phê duyệt. Sau khi BARB thông qua điều lệ, dự thảo của điều lệ WG mới hoặc cập nhật sẽ được trình lên HĐQT để phê duyệt.

Sau khi Hội đồng quản trị phê duyệt điều lệ, WG mà Hội đồng quản trị đã giao công việc phát triển đặc điểm kỹ thuật phải hợp tác chặt chẽ với nhóm đã chuẩn bị cho FRD trong trường hợp cần có bất kỳ cập nhật hoặc giải thích cần thiết nào đối với FRD đó. Nếu cần cập nhật FRD trong Giai đoạn Phát triển, các quy trình nêu trong Phần 3.3 và phần này phải được tuân theo; tuy nhiên, việc phát triển đặc điểm kỹ thuật có thể xảy ra song song với các cập nhật điều lệ FRD và WG.

3.5 Yêu cầu Yêu cầu thoát giai đoạn

Giai đoạn Yêu cầu đã hoàn tất và Giai đoạn Phát triển bắt đầu khi điều lệ WG với phạm vi cần thiết cho FRD được Hội đồng Quản trị xác nhận hoặc phê duyệt và các yêu cầu sau đã được đáp ứng:

NWP hoặc đã được Hội đồng quản trị chấp thuận, hoặc Hội đồng quản trị đã đồng ý rằng một NWP là không cần thiết.
Điều lệ FRD và WG tương ứng đã được BARB chấp thuận.

4. Giai đoạn phát triển

Trong Giai đoạn Phát triển, (các) WG được chỉ định tạo ra đặc điểm kỹ thuật mới và / hoặc nâng cao thông số kỹ thuật hiện có. FRD xác định các yêu cầu của đặc điểm kỹ thuật Bluetooth mới hoặc nâng cao. Không có chức năng nào được phép trong đặc tả không liên quan hợp lý đến các yêu cầu trong FRD. Mục tiêu là tạo ra thông số kỹ thuật 0.9 / CR sẵn sàng cho Giai đoạn xác thực (được mô tả trong Phần 5) khi kết thúc Giai đoạn phát triển.
Trong Giai đoạn Phát triển, một đặc điểm kỹ thuật (hoặc nâng cao đặc điểm kỹ thuật) tiến bộ qua ba bướctagnghĩa là

Đối với một thông số kỹ thuật mới, ba stagCác là:

0.5 giâytage
0.7 giâytage
0.9 giâytage

Để nâng cao đặc điểm kỹ thuật, ba stagCác là:

Dự thảo Tài liệu Đề xuất Cải tiến (DIPD) Stage
Tài liệu Đề xuất Cải tiến Cuối cùng (FIPD) Stage
Yêu cầu thay đổi (CR) Stage

Mỗi stage được mô tả thêm trong các phần phụ tiếp theo. Hình 4.1 dưới đây minh họa các tài liệu khác nhau mà WG sẽ chuẩn bị tại mỗi stage.

Hình 4.1: Hếtview của đặc điểm kỹ thuật stagnhững điều xảy ra trong Giai đoạn Phát triển

Vai trò của BARB trong suốt quá trình phát triển đặc tả là cung cấp cho WGs lời khuyên và hỗ trợ kỹ thuật. WGs có thể, bất cứ lúc nào, yêu cầu BARB tư vấn kỹ thuật liên quan đến việc phát triển đặc điểm kỹ thuật và các khái niệm kiến trúc được sử dụng trong một đặc điểm kỹ thuật. Các WG đặc biệt được khuyến khích để thu hút phản hồi sớm từ BARB cho các đối tượng địa lý cần xem xét kiến trúc phức tạp hơn.

4.1 0.5 / DIPD Stage

Trong 0.5 / DIPD Stage, WG sẽ phát triển các nội dung sau bằng cách sử dụng các mẫu chính thức được cung cấp trong [8]:

Đối với một đặc điểm kỹ thuật mới, bản nháp của đặc điểm kỹ thuật 0.5, tối thiểu phải bao gồm thông tin về những điều sau:

Kiến trúc để đáp ứng các yêu cầu như đã nêu trong FRD
Đối với các giao thức, các điểm truy cập dịch vụ được xác định
Đối với dịch vụ, dữ liệu bị lộ và hành vi
Dành cho chuyên nghiệpfiles, các giao thức được xác định và chức năng được chỉ định

2. Để nâng cao đặc điểm kỹ thuật, bản dự thảo DIPD, tối thiểu phải bao gồm thông tin về những điều sau:

Lý lịch: Phạm vi công việc, các mục tiêu hướng dẫn công việc và cách đề xuất cụ thể này phù hợp với phạm vi

Quaview đề xuất: Bản tóm tắt về chức năng mở rộng (tính linh hoạt bổ sung, hiệu suất được cải thiện, v.v.) do DIPD cung cấp bao gồm mô tả rõ ràng về cách chức năng mới phù hợp với phiên bản đặc điểm kỹ thuật hiện tại. Nếu WG đã đánh giá nhiều đề xuất, thì những đề xuất này nên được đưa vào để cho phép BARB có cơ hội xác định xem có đủ sự thẩm định trong việc lựa chọn đề xuất ưu tiên hay không.
Bao gồm các yêu cầu: Bản tóm tắt về phạm vi các yêu cầu chức năng do đề xuất đưa ra, có tham chiếu đến các yêu cầu hệ thống thích hợp và các tình huống sử dụng được đưa ra trong FRD liên quan
Định nghĩa vấn đề: Tuyên bố về các vấn đề được giải quyết bởi (các) đề xuất

Tiêu chí lựa chọn: Một tuyên bố liên quan đến các tiêu chí lựa chọn / hiệu suất từ các chỉ số đánh giá liên quan đã hướng dẫn quá trình lựa chọn
Biện minh cho sự lựa chọn: Kiểm tra các chỉ số đánh giá để chứng minh sự lựa chọn giữa các đề xuất và tiết lộ sự đánh đổi
Sự miêu tả: Mô tả về chức năng và các giao thức mở rộng. Phần này có thể thích ứng với các nhu cầu khác nhau bằng cách thêm các phần phụ có liên quan.

3. Chiến lược kiểm tra: Mô tả về chức năng được đề xuất để kiểm tra (hoặc không được kiểm tra) như một phần của Chương trình Chứng nhận Bluetooth và cách chức năng mà nó được đề xuất để kiểm tra (ví dụ: kỳ vọng đối với (các) Kiểm tra dưới hoặc (các) Kiểm tra trên, và nếu các thử nghiệm sẽ được coi là thử nghiệm sự phù hợp hoặc khả năng tương tác hoặc kết hợp cả hai). Điều này có thể nằm trong một tài liệu riêng biệt hoặc một phần riêng biệt trong thông số kỹ thuật 0.5 / DIPD. Các quy ước được sử dụng trong Chiến lược kiểm tra được mô tả trong Chiến lược kiểm tra và thuật ngữview tài liệu (TSTO) [5].

Đối tượng chính của tài liệu tại stage là các thành viên WG và BARBview các đề xuất kiến trúc và phạm vi yêu cầu, và BTI là ngườiviews Chiến lược Kiểm tra. Trong hầu hết các trường hợp, các tài liệu tại stage không nhằm mục đích chứa văn bản được lên kế hoạch đưa vào thông số kỹ thuật cuối cùng.

BSTS phảiview tất cả các tài liệu để nhất quán với Nguyên tắc soạn thảo Bluetooth [1] và xác định các vấn đề để WG giải quyết. BARB phải lạiview đặc điểm kỹ thuật 0.5 / DIPD. Để nâng cao đặc điểm kỹ thuật, BARB cũng phảiview DIPD để tuân thủ các yêu cầu tương thích ngược được mô tả trong Phần 3.3.2. BTI phải táiview Chiến lược Kiểm tra.

BARB phải chấp thuận hoặc từ chối thông số kỹ thuật 0.5 / DIPD dựa trên đánh giá kỹ thuật của nó. Nếu được BARB chấp thuận, thông số kỹ thuật 0.5 / DIPD sẽ có sẵn trên Bluetooth SIG webtrang web cho tất cả các thành viên Liên kết và Nhà quảng cáo và thông báo về tính khả dụng của nó sẽ được phát hành bởi BSTS. Ở 0.5 / DIPD Stage, không cần phê duyệt Chiến lược thử nghiệm.
0.5 / DIPD Stage không bắt buộc đối với các cải tiến đối với thông số kỹ thuật CSS, GSS hoặc MDP

0.5 / DIPD Stage yêu cầu thoát

0.5 / DIPD Stage đã hoàn thành và 0.7 / FIPD Stage bắt đầu khi các yêu cầu thoát sau được đáp ứng:

BSTS đã hoàn thànhviewtrong chiến lược thử nghiệm và đặc tả 0.5 / DIPD.

BARB đã phê duyệt thông số kỹ thuật 0.5 / DIPD.
BTI đã hoàn thànhview của Chiến lược kiểm tra.
BSTS đã cung cấp thông số kỹ thuật 0.5 / DIPD được phê duyệt cho tất cả các thành viên Cộng tác viên và Nhà quảng cáo.

4.2 0.7 / FIPD Stage

Trong 0.7 / FIPD Stage, WG sẽ phát triển các nội dung sau bằng cách sử dụng các mẫu chính thức được cung cấp trong [8]:

Đối với một đặc điểm kỹ thuật mới, bản nháp của đặc điểm kỹ thuật 0.7, tối thiểu phải bao gồm thông tin về những điều sau:

Mô tả tất cả các thay đổi đã được thực hiện kể từ 0.5 được BARB phê duyệt, bao gồm các đề xuất mới hoặc sửa đổi, tiêu chí lựa chọn và lý do lựa chọn. Các thay đổi phải được mô tả ở cùng mức độ chi tiết như yêu cầu trong 0.5 Stage.
Tất cả các yêu cầu chức năng từ FRD đã được giải quyết.

2. Để nâng cao đặc điểm kỹ thuật, dự thảo FIPD, tối thiểu phải bao gồm thông tin về những điều sau:

Mô tả về tất cả các thay đổi đã được thực hiện kể từ khi DIPD được BARB phê duyệt, bao gồm các đề xuất mới hoặc sửa đổi, tiêu chí lựa chọn và lý do lựa chọn. Các thay đổi phải được mô tả ở cùng mức độ chi tiết như được yêu cầu trong DIPD Stage.

Khi cần thiết, các lĩnh vực được phát triển thêm đã được mô tả trong Phần 4.1 liên quan đến DIPD.
Mô tả hoàn chỉnh về cải tiến.
Một mô tả kiến trúc được cập nhật.
Tất cả các yêu cầu chức năng từ FRD đã được giải quyết.

3. 0.7 / Tài liệu kiểm tra FIPD, tối thiểu phải bao gồm thông tin về những điều sau:

Bộ thử nghiệm, bao gồm danh sách các Mục đích Thử nghiệm như được mô tả trong TSTO [5].

Tuyên bố Tuân thủ Triển khai (ICS), như được mô tả trong TSTO [5].

Đối với các cải tiến về đặc điểm kỹ thuật, Bộ thử nghiệm và ICS có thể được cung cấp dưới dạng các tài liệu riêng biệt hoặc dưới dạng các phần bổ sung trong FIPD.

Đối tượng chính của các tài liệu được tạo ra tại stage là các thành viên WG và BARBview mô tả đầy đủ về tính năng hoặc cải tiến bao gồm một số văn bản được lên kế hoạch đưa vào thông số kỹ thuật cuối cùng. BTI là khán giả của review của các tài liệu thử nghiệm.

BSTS sẽ lạiview các phần mới hoặc thay đổi của tài liệu kiểm tra và thông số kỹ thuật 0.7 / FIPD về tính nhất quán với Hướng dẫn soạn thảo Bluetooth, bao gồm cả các quy ước ngôn ngữ được thiết lập bởi Bluetooth SIG. BARB sẽ lạiview đặc điểm kỹ thuật 0.7 / FIPD.

BSTS sẽ hỗ trợ WG chuẩn bị các tài liệu kiểm tra 0.7 / FIPD phù hợp với TSTO [5].

BTI phải táiview tài liệu thử nghiệm 0.7 / FIPD. WG phải cung cấp đặc điểm kỹ thuật 0.7 / FIPD cho BTI làm tài liệu tham khảo khiviewtrong tài liệu kiểm tra 0.7 / FIPD, mà BTI sẽview phù hợp với Đặc điểm kỹ thuật BTI Review Danh sách kiểm tra quy trình [6].

Sau khi BARB hoàn thànhview của đặc điểm kỹ thuật 0.7 / FIPD và BTI đã hoàn thànhview trong số các tài liệu kiểm tra 0.7 / FIPD, BSTS sẽ thực hiệnviewed 0.7 / đặc điểm kỹ thuật FIPD có sẵn cho tất cả các thành viên Cộng tác và Nhà quảng cáo.

0.7 / FIPD Stage không bắt buộc đối với các cải tiến đối với thông số kỹ thuật CSS, GSS hoặc MDP.

0.7 / FIPD Stage yêu cầu thoát

0.7 / FIPD Stage đã hoàn thành và 0.9 / CR Stage bắt đầu khi các yêu cầu thoát sau được đáp ứng:

BSTS đã hoàn thànhviewtrong tài liệu kiểm tra và thông số kỹ thuật 0.7 / FIPD.
BARB đã hoàn thành lạiviewtheo đặc điểm kỹ thuật 0.7 / FIPD.
BTI đã hoàn thànhviewtrong Bộ thử nghiệm 0.7 / FIPD (Mục đích thử nghiệm) và 0.7 / FIPD ICS.
BSTS đã thực hiện lạiviewed 0.7 / đặc điểm kỹ thuật FIPD có sẵn cho tất cả các thành viên Cộng tác và Nhà quảng cáo.

4.3 0.9 / CR Stage

Có hai loại CR: CR tích hợp, là tài liệu theo dõi thay đổi của toàn bộ thông số kỹ thuật đã được thông qua hiển thị tất cả các thay đổi kể từ phiên bản trước và CR viết tắt, là tài liệu cung cấp hướng dẫn chỉ sửa đổi các phần bị ảnh hưởng của phiên bản đặc điểm kỹ thuật dựa trên CR.

Trong 0.9 / CR Stage, WG sẽ phát triển các nội dung sau bằng cách sử dụng các mẫu chính thức được cung cấp trong [8]:

Đối với một thông số kỹ thuật mới, một bản thảo hoàn chỉnh về nội dung của thông số kỹ thuật 0.9, tối thiểu phải bao gồm thông tin về những điều sau:

Mô tả về tất cả các thay đổi đã được thực hiện kể từ khi BARB-reviewđặc điểm kỹ thuật ed 0.7 (hoặc vì thông số kỹ thuật 0.5 nếu sản xuất thông số kỹ thuật 0.7 đã được miễn), bao gồm mới hoặc
đề xuất sửa đổi, tiêu chí lựa chọn và lý do lựa chọn. Các thay đổi phải được mô tả ở cùng mức độ chi tiết như yêu cầu trong 0.5 Stage và 0.7 Stage.

2. Để nâng cao đặc điểm kỹ thuật:

CR tích hợp, tối thiểu phải bao gồm thông tin về những điều sau:

Mô tả về tất cả các thay đổi đã được thực hiện kể từ khi BARB-reviewed FIPD (hoặc kể từ DIPD nếu FIPD đã được từ bỏ) bao gồm các đề xuất mới hoặc sửa đổi, tiêu chí lựa chọn và lý do lựa chọn. Các thay đổi phải được mô tả ở cùng mức độ chi tiết như được yêu cầu trong DIPD Stage và FIPD Stage.
Tất cả các thay đổi được đề xuất cho đặc điểm kỹ thuật được chấp nhận trước đó bằng cách sử dụng theo dõi thay đổi.
Tất cả các lỗi kỹ thuật đã được phê duyệt (với mỗi lỗi được tham chiếu với một số lỗi), được hiển thị bằng cách sử dụng theo dõi thay đổi, vẫn chưa được tích hợp vào phiên bản đặc điểm kỹ thuật đã được thông qua trước đó và văn bản tác động được liên kết với việc nâng cao đặc điểm kỹ thuật; hoặc điều đó ảnh hưởng đến thử nghiệm IOP.

3. Hoặc CR viết tắt, tối thiểu phải bao gồm thông tin về những điều sau:

Mô tả về tất cả các thay đổi đã được thực hiện kể từ khi BARB-reviewed FIPD (hoặc kể từ DIPD nếu FIPD đã được từ bỏ) bao gồm các đề xuất mới hoặc sửa đổi, tiêu chí lựa chọn và lý do lựa chọn. Các thay đổi phải được mô tả ở cùng mức độ chi tiết như được yêu cầu trong DIPD Stage và FIPD Stage.
Tất cả các thay đổi được đề xuất cho từng phần và đoạn bị ảnh hưởng của đặc điểm kỹ thuật mà CR đề xuất thay đổi.
Tất cả các lỗi kỹ thuật đã được phê duyệt (với mỗi lỗi được tham chiếu với một số lỗi), được hiển thị bằng cách sử dụng đánh dấu, vẫn chưa được tích hợp vào phiên bản đặc điểm kỹ thuật đã được thông qua trước đó và văn bản tác động được liên kết với việc nâng cao đặc điểm kỹ thuật; hoặc điều đó ảnh hưởng đến thử nghiệm IOP.

4. CSS CR (nếu đặc điểm kỹ thuật yêu cầu các mục nhập mới), có thể được nhúng vào CR viết tắt của thông số kỹ thuật.
5. GSS CR (nếu đặc điểm kỹ thuật yêu cầu các mục nhập mới), có thể được nhúng vào CR viết tắt của thông số kỹ thuật.
6. MDP CR (nếu đặc điểm kỹ thuật yêu cầu các mục nhập mới), có thể được nhúng vào CR viết tắt của thông số kỹ thuật.
7. Tài liệu thử nghiệm 0.9 / CR, tối thiểu phải bao gồm thông tin về những điều sau đây bằng cách sử dụng mẫu chính thức được cung cấp trong [8]:

Bộ thử nghiệm 0.9 / CR, bao gồm các trường hợp thử nghiệm hoàn chỉnh về nội dung và Bảng ánh xạ trường hợp thử nghiệm (TCMT) liên quan, như được mô tả trong TSTO [5].
ICS 0.9 / CR, như được mô tả trong TSTO [5].
Nếu cấu hình các thử nghiệm yêu cầu các tham số cụ thể cho Triển khai Đang Kiểm tra (IUT), thì Thông tin eXtra Thực thi 0.9 / CR để Kiểm tra (IXIT).

Danh sách tham chiếu trường hợp thử nghiệm 0.9 / CR (TCRL) (tùy chọn cho các bản cập nhật Thông số kỹ thuật chính).

8. Phân tích phạm vi kiểm tra cho biết các yêu cầu đặc điểm kỹ thuật nào được kiểm tra hoặc không được kiểm tra trong Bộ thử nghiệm 0.9 / CR (đối với các cải tiến về đặc điểm kỹ thuật, phân tích phạm vi kiểm tra chỉ cần bao gồm chức năng mới được bổ sung và bị ảnh hưởng, chứ không phải các khu vực không bị ảnh hưởng của đặc điểm kỹ thuật gốc).
9. Một kế hoạch thử nghiệm IOP.

Đối với các cải tiến về đặc điểm kỹ thuật, Bộ thử nghiệm, ICS và IXIT có thể được cung cấp dưới dạng tài liệu riêng biệt hoặc dưới dạng các phần bổ sung trong CR viết tắt.

Trong hầu hết các trường hợp, CR được tích hợp hoặc viết tắt phải dựa trên phiên bản thông số kỹ thuật đã được thông qua trước đó, nhưng nó cũng có thể dựa trên bản nháp trung gian mới nhất. Số phiên bản đặc điểm kỹ thuật của bản nháp trung gian mới nhất phải là số phiên bản được liên kết với một phiên bản của tài liệu bị đóng băng và sẽ không thay đổi theo thời gian. Nếu không, thông tin nhận dạng bổ sung (chẳng hạn như ngày tháng tài liệu và URL đến một vị trí cố định) phải được cung cấp để xác định phiên bản "đường cơ sở" cụ thể. Nếu bản nháp trung gian được sử dụng, bất kỳ thay đổi nào không liên quan trực tiếp đến CR trong một phần nhất định mà CR đang sửa đổi phải được đưa vào, nhưng không bắt buộc phải được hiển thị bằng cách sử dụng đánh dấu. Nếu các phần liên quan của dự thảo trung gian được cập nhật sau đó, CR phải được cập nhật để phản ánh các cập nhật đối với dự thảo trung gian.

Lý tưởng nhất, tài liệu CR viết tắt được tích hợp vào bản thảo của đặc điểm kỹ thuật hoàn chỉnh và tài liệu thử nghiệm hoàn chỉnh tương ứng trước Giai đoạn xác thực, nhưng chúng cũng có thể được tích hợp khi bắt đầu Giai đoạn xác thực. Nếu nhiều tính năng đang được phát triển cho một đặc điểm kỹ thuật (ví dụ: Đặc điểm kỹ thuật chính), có thể nên tích hợp các tính năng vào một bản nháp duy nhất sau khi quá trình kiểm tra IOP hoàn tất.

BSTS sẽ lạiview thông số kỹ thuật 0.9 / CR và các tài liệu kiểm tra về tính nhất quán với Nguyên tắc soạn thảo Bluetooth. Sau đó BARB sẽ lạiview đặc điểm kỹ thuật 0.9 / CR sau đó là kế hoạch kiểm tra IOP (như được mô tả trong Phần 4.3.1). Sau khi thông số kỹ thuật 0.9 / CR được WG gửi tới BARB để táiview, BSTS sẽ giúp tất cả các thành viên có thể truy cậpview và thông báo cho tất cả các thành viên về tính khả dụng của nó. Kể từ thời điểm này trở đi trong quá trình phát triển đặc điểm kỹ thuật, BSTS sẽ cung cấp các bản thảo của đặc điểm kỹ thuật gửi cho BARB cho tất cả các thành viên cùng với các thông báo định kỳ được gửi cho tất cả các thành viên.

Để nâng cao đặc điểm kỹ thuật, WG sẽ đề xuất với BoD xem có nên ngừng sử dụng hoặc rút lại các phiên bản trước của thông số kỹ thuật hay không, bao gồm cả lý do kỹ thuật cho (các) đề xuất.

BARB sẽ lạiview phân tích của WG về sự tuân thủ của thông số kỹ thuật 0.9 / CR với các yêu cầu được đưa ra trong FRD, mọi vấn đề bảo mật tiềm ẩn, mọi vấn đề quy định, sự phù hợp với kiến trúc Bluetooth và, để nâng cao thông số kỹ thuật, tuân thủ các yêu cầu tương thích ngược được mô tả trong Mục 3.3.2 .XNUMX. Nếu BARB xác định bất kỳ vấn đề bảo mật tiềm ẩn nào, BARB sẽ thông báo cho BSTS đểview và phối hợp với Nhóm chuyên gia bảo mật; và nếu BARB xác định được bất kỳ tác động pháp lý nào, BARB sẽ thông báo cho BSTS để táiview và phối hợp với Ủy ban điều tiết và cố vấn pháp lý của Bluetooth SIG. BARB phải chấp thuận hoặc từ chối thông số kỹ thuật 0.9 / CR dựa trên đánh giá kỹ thuật của mình và xem xét các yếu tố được mô tả trong đoạn này.

BTI sẽ lạiview tài liệu thử nghiệm 0.9 / CR có tính đến phân tích phạm vi thử nghiệm. BTI phải chấp thuận hoặc từ chối các tài liệu thử nghiệm 0.9 / CR.

Sau khi BARB phê duyệt thông số kỹ thuật 0.9 / CR, WG gửi kế hoạch kiểm tra IOP cho BARB để táiview.

Thông số kỹ thuật 0.9 / CR được BARB phê duyệt được trình lên Hội đồng quản trị để phê duyệt việc bắt đầu thử nghiệm IOP và công bố thông số kỹ thuật 0.9 / CR cho tất cả các thành viên.

Để làm nổi bật các vấn đề pháp lý tiềm ẩn, WGs có thể yêu cầu một đặc điểm kỹ thuậtview bởi cố vấn pháp lý của Bluetooth SIG (luật phápview) trước khi luật pháp bắt buộc táiview diễn ra trong Giai đoạn Tiếp nhận / Phê duyệt. Tuy nhiên, để cải tiến đặc điểm kỹ thuật, luật pháp táiview nên được thực hiện trên CR tích hợp (trái ngược với CR viết tắt) và điều này nên được lên lịch trước càng nhiều càng tốt để có sẵn các nguồn lực.

Kế hoạch kiểm tra IOP

WG sẽ phát triển một kế hoạch kiểm tra IOP bằng văn bản phải đáp ứng tất cả các yêu cầu được xác định dưới đây để sử dụng trong Giai đoạn Xác thực tại các sự kiện kiểm tra IOP. WGs phải gửi kế hoạch kiểm tra IOP cho BARB đểview trước khi (các) sự kiện kiểm tra IOP bắt đầu. Đối với các cải tiến thông số kỹ thuật đơn giản (đặc biệt là những cải tiến không yêu cầu sửa đổi hoặc thêm bất kỳ trường hợp thử nghiệm nào trong Bộ thử nghiệm), có thể không cần thử nghiệm IOP và WG có thể gửi yêu cầu BARB từ bỏ thử nghiệm IOP bằng cách sử dụng quy trình đã xác định trong Phần 4.4.

Kế hoạch kiểm tra IOP phải bao gồm:

Các trường hợp kiểm tra để xác minh tất cả các tính năng bắt buộc, tùy chọn và có điều kiện mới
Ít nhất một trường hợp thử nghiệm cho mỗi mã op
Ít nhất một trường hợp thử nghiệm cho mỗi tham số
Ít nhất một trường hợp thử nghiệm cho mỗi loại gói
Các trường hợp kiểm tra khả năng tương thích ngược cho các cải tiến đặc điểm kỹ thuật để đáp ứng các yêu cầu liệt kê trong Phần 3.3.2 cho tất cả các chức năng nâng cao (xem thêm Phần 4.3.1.1).

Các trường hợp thử nghiệm trong đó IUT tiếp xúc với các giá trị nằm ngoài phạm vi xác định hoặc các khía cạnh hành vi được coi là không hợp lệ hoặc không mong muốn (Các trường hợp thử nghiệm Hành vi không hợp lệ). Lưu ý rằng dự kiến rằng một trình kiểm tra như PTS hoặc công cụ kiểm tra khác sẽ là người khởi xướng bất kỳ hành vi không hợp lệ nào.
Mọi số được ấn định tạm thời (được chọn phối hợp với BSTS để tránh trùng lặp tại các sự kiện thử nghiệm IOP sắp tới) sẽ được sử dụng tại sự kiện thử nghiệm IOP, như được mô tả trong Phần 4.3.1.2.
Xác định số lượng triển khai độc lập cần thiết phải vượt qua từng trường hợp thử nghiệm, có tính đến các yêu cầu về phạm vi được mô tả trong Phần 4.3.1.3

Việc xác định bất kỳ trường hợp thử nghiệm nào trong Bộ thử nghiệm mà WG tin rằng cần được loại trừ và lý do cho việc loại trừ chúng. Những điều này thường bao gồm: • Các trường hợp thử nghiệm Kiểm chứng trong tương lai (ví dụ: các thử nghiệm phổ biến để có thể bổ sung trong tương lai, chẳng hạn như các đặc tính bổ sung, đặc tính mở rộng hoặc việc sử dụng các bit hoặc trường Dành riêng cho Sử dụng trong Tương lai (RFU))
• Các trường hợp thử nghiệm là một tập hợp con của các thử nghiệm bao gồm khác
• Các trường hợp thử nghiệm chung hầu như giống hệt với các thử nghiệm chạy cho một số thông số kỹ thuật khác (ví dụ: kích hoạt mã lỗi phổ biến)
• Các trường hợp thử nghiệm có cùng mục đích thử nghiệm với các trường hợp thử nghiệm chạy trên một phương tiện giao thông khác (ví dụ: trường hợp thử nghiệm BR / EDR tương tự như trường hợp thử nghiệm LE)
• Kiểm tra độ chắc chắn hoặc căng thẳng của việc thực hiện

Kế hoạch thử nghiệm IOP cũng có thể bao gồm các thử nghiệm dành riêng cho thử nghiệm IOP, chẳng hạn như các trường hợp thử nghiệm end-to-end xâu chuỗi các chuỗi phức tạp hơn có thể giống với một kịch bản người dùng điển hình.

Mặc dù BARB phê duyệt kế hoạch kiểm tra IOP là không bắt buộc (hiểu rằng kế hoạch kiểm tra IOP sẽ tiếp tục được sửa đổi và cải tiến với mỗi sự kiện kiểm tra IOP), BARB phê duyệt báo cáo kiểm tra IOP là bắt buộc (xem Phần 5.1.1) . Nếu một kế hoạch kiểm tra IOP không đáp ứng tất cả các yêu cầu được xác định trong Phần 4.3.1, WG phải trình bày tóm tắt về bất kỳ phương sai đã biết nào và cơ sở lý luận cho mỗi phương sai đối với BARB trước khi (các) sự kiện kiểm tra IOP bắt đầu.

Kế hoạch kiểm tra IOP và các trường hợp kiểm tra chủ yếu phải dựa trên nội dung trong các tài liệu kiểm tra của thông số kỹ thuật được liên kết.

Để làm cho các sự kiện thử nghiệm IOP hiệu quả, WG phải có kế hoạch thử nghiệm IOP và tất cả các trường hợp thử nghiệm liên quan được hoàn thành và có sẵn cho người triển khai lý tưởng ít nhất một tháng trước sự kiện thử nghiệm IOP đầu tiên.

Lập kế hoạch kiểm tra khả năng tương thích ngược
Đối với các cải tiến về đặc điểm kỹ thuật, thử nghiệm IOP về khả năng tương thích ngược phải xem xét xác minh đối với tất cả các phiên bản thông số kỹ thuật đang hoạt động và không dùng nữa vì những thông số kỹ thuật và chức năng thường thấy trong các sản phẩm Bluetooth có thể có tuổi thọ rất cao (ví dụ: xe cộ). WG phải phân tích mức độ kiểm tra tương thích ngược thích hợp cần thiết (nếu có) bao gồm phiên bản nào cần kiểm tra và các kiểm tra cần thực hiện, đồng thời cung cấp phân tích này cho BARB. BARB phải lạiview phân tích và đề xuất các thay đổi (nếu có) để WG đưa vào kế hoạch kiểm tra IOP.

Các thành viên tham gia thử nghiệm tính tương thích ngược được khuyến khích mang theo các thiết bị kế thừa đã đủ điều kiện so với (các) phiên bản thông số kỹ thuật trước đó. WG phải báo cáo mọi lỗi tương thích ngược trong báo cáo kiểm tra IOP. Các công ty thành viên cũng được khuyến khích thực hiện kiểm tra tính tương thích ngược trong phòng thí nghiệm của riêng họ bên ngoài địa điểm diễn ra sự kiện kiểm tra IOP và báo cáo mọi vấn đề liên quan đến đặc điểm kỹ thuật cho WG.

Số được ấn định tạm thời được sử dụng trong thử nghiệm IOP
BSTS và BARB phải được tham khảo ý kiến để điều phối tạm thời các số được chỉ định sẽ được sử dụng tại sự kiện thử nghiệm IOP để không có sự chồng chéo hoặc xung đột với các thông số kỹ thuật khác. Các giá trị tạm thời này phải được đưa vào kế hoạch kiểm tra IOP và sẽ không được chỉ định để sử dụng bởi bất kỳ thông số kỹ thuật đã được thông qua nào.

Đối với thử nghiệm IOP trong đó một hoặc nhiều giá trị UUID 16 bit mới đang được đề xuất, các giá trị trong phạm vi từ 0x7F00 đến 0x7FFF được dành riêng cho thử nghiệm IOP.

Đối với thử nghiệm IOP trong đó một hoặc nhiều giá trị Bộ ghép kênh dịch vụ giao thức cố định (PSM) mới đang được đề xuất, các giá trị bắt đầu từ cuối phạm vi hợp lệ từ 0x0000 đến 0x007F, như được chỉ định trong Đặc điểm kỹ thuật chính, sẽ được sử dụng.

Yêu cầu bảo hiểm
WG phải cung cấp bằng chứng cho BARB rằng số lượng yêu cầu (như được mô tả trong các phần tiếp theo) của các triển khai độc lập đã vượt qua mỗi trường hợp thử nghiệm. Bất kỳ yêu cầu ngoại lệ nào của WG đối với số lượng triển khai độc lập bắt buộc phải được chỉ ra trong kế hoạch kiểm tra IOP được gửi cho BARB.

Việc triển khai được coi là độc lập với nhau miễn là tất cả các bộ phận liên quan đến việc xác nhận đã được phát triển độc lập, tức là bởi các nhóm khác nhau (không nhất thiết đến từ các công ty khác nhau). BSTS có thể hỗ trợ đánh giá xem liệu các nguyên mẫu có thể được coi là độc lập với nhau hay không để bảo vệ tính ẩn danh và bí mật của các chi tiết triển khai.

Lưu ý rằng các công cụ kiểm tra, bao gồm PTS, không được coi là triển khai độc lập.

Đặc điểm kỹ thuật cốt lõi Yêu cầu về phạm vi bảo hiểm IOP
Tính năng Đặc tả cốt lõi thường xác định một hoặc nhiều vai trò trong đó mỗi vai trò được thiết kế để tương tác với một hoặc nhiều vai trò khác hoặc có thể với chính nó.

Đối với mỗi cặp vai trò được thiết kế để tương tác với nhau, ít nhất ba cách triển khai độc lập của mỗi vai trò phải được chứng minh để tương tác với ba cách triển khai độc lập của vai trò bổ sung.

Đối với mỗi vai trò có thể tương tác với một thiết bị khác trong cùng một vai trò, ít nhất ba cách triển khai độc lập của vai trò đó phải chứng minh rằng chúng có thể tương tác với nhau trong vai trò đó.

Đặc điểm kỹ thuật dịch vụ Các yêu cầu về phạm vi bảo hiểm IOP
Ít nhất ba triển khai dịch vụ độc lập phải chứng minh rằng chúng tương tác với ít nhất một triển khai khách hàng, có thể là PTS.

Chuyên nghiệpfile và đặc điểm kỹ thuật giao thức các yêu cầu về phạm vi bảo hiểm IOP
Chuyên nghiệpfile và các đặc tả giao thức thường xác định một hoặc nhiều vai trò trong đó mỗi vai trò được thiết kế để tương tác với một hoặc nhiều vai trò khác hoặc có thể với chính nó.

Đối với mỗi cặp vai trò được thiết kế để tương tác với nhau, ít nhất hai triển khai độc lập của mỗi vai trò phải chứng minh rằng chúng tương tác với hai triển khai độc lập của vai trò bổ sung.

Đối với mỗi vai trò có thể tương tác với một thiết bị khác trong cùng một vai trò, ít nhất ba cách triển khai độc lập của vai trò đó phải chứng minh rằng chúng tương tác với nhau trong vai trò đó.

Đặc điểm kỹ thuật mô hình Yêu cầu về phạm vi IOP
Ít nhất ba triển khai mô hình máy chủ hoặc mô hình điều khiển độc lập phải chứng minh rằng chúng tương tác với ít nhất một triển khai máy khách (có thể là PTS) và ít nhất một triển khai mô hình máy khách phải chứng minh rằng nó tương tác với ít nhất một triển khai mô hình máy chủ và PTS.

Đánh số phiên bản đặc điểm kỹ thuật

Trong 0.9 / CR Stage, WG phải chuẩn bị một khuyến nghị để trình lên Hội đồng Quản trị về số phiên bản sẽ được áp dụng cho đặc điểm kỹ thuật khi được thông qua.

Các phiên bản của thông số kỹ thuật chia thành hai loại: phiên bản phát hành đầy đủ, bao gồm các tính năng mới hoặc cập nhật và phiên bản phát hành bảo trì (còn được gọi là “phiên bản dot-Z”), tích hợp lỗi kỹ thuật và biên tập, nhưng không bao gồm mới hoặc cập nhật đặc trưng. Các phiên bản phát hành đầy đủ có số hai phần ở dạng XY, chẳng hạn như 2.1 hoặc 5.0, trong khi các phiên bản phát hành bảo trì có số ba phần ở dạng XYZ, chẳng hạn như 2.1.2. Giá trị của Z không được bằng 0.

Đối với hai phiên bản bất kỳ, một phiên bản được gọi là “phiên bản cao hơn” và phiên bản còn lại là “phiên bản thấp hơn”. Điều này được xác định theo các quy tắc sau:

Nếu các thành phần X khác nhau, thành phần có giá trị X cao hơn là "phiên bản cao hơn".
Nếu các thành phần X giống nhau, nhưng các thành phần Y khác nhau, thì thành phần có giá trị Y cao hơn là “phiên bản cao hơn”.
Nếu các thành phần XY giống nhau, nhưng các thành phần Z khác nhau, thì thành phần có giá trị Z cao hơn là “phiên bản cao hơn”. Đối với mục đích này, số gồm hai phần XY được coi là số ba phần XY0.

Ví dụample, các số phiên bản sau sẽ theo thứ tự từ phiên bản thấp nhất đến phiên bản cao nhất: 1.4, 2.0, 2.0.3, 2.1, 2.1.1, 2.1.2, 2.2. Đối với CSS, mỗi bản cập nhật chỉ tăng thành phần X của số phiên bản.

Điều kiện tiên quyết để phê duyệt BoD
Vào cuối giai đoạn Phát triển thông số kỹ thuật, các yêu cầu sau phải được đáp ứng trước khi thông số kỹ thuật 0.9 / CR được đệ trình lên BoD để phê duyệt:

WG đã hoàn thành phân tích phạm vi kiểm tra.
BSTS đã hoàn thànhviewtrong tài liệu kiểm tra và thông số kỹ thuật 0.9 / CR.
BARB đã phê duyệt thông số kỹ thuật 0.9 / CR.
BARB đã phê duyệt CSS CR (nếu đặc điểm kỹ thuật yêu cầu các mục nhập mới) có thể được nhúng vào CR viết tắt của thông số kỹ thuật.
BARB đã phê duyệt GSS CR và MDP CR (nếu đặc điểm kỹ thuật yêu cầu các mục nhập mới).
BTI đã phê duyệt Bộ thử nghiệm 0.9 / CR, ICS và TCRL cùng với IXIT (với điều kiện là cần có IXIT để thực hiện các thử nghiệm trong Bộ thử nghiệm). TCRL là tùy chọn tại stage để cập nhật Đặc điểm kỹ thuật cốt lõi.
WG đã gửi kế hoạch kiểm tra IOP cho BARB để táiview (nếu thử nghiệm không được BARB từ bỏ).

Các tài liệu xuất trình cho Hội đồng quản trị phải bao gồm thông số kỹ thuật 0.9 / CR được BARB phê duyệt và bản trình bày cho Hội đồng quản trị phải bao gồm:

Bất kỳ yêu cầu nào đã biết để từ bỏ thử nghiệm IOP hoặc bất kỳ yêu cầu nào được xác định trong Phần 4.3.1
Danh sách các phương tiện vận chuyển mà đặc điểm kỹ thuật hỗ trợ (ví dụ: BR / EDR, LE, v.v.)
Để nâng cao đặc điểm kỹ thuật, bất kỳ trường hợp miễn trừ nào đối với các yêu cầu tương thích ngược (được mô tả trong Phần 3.3.2) đang được WG yêu cầu
Để cải thiện đặc điểm kỹ thuật, một khuyến nghị từ WG về số phiên bản để áp dụng cho thông số kỹ thuật được thông qua
Để cải tiến thông số kỹ thuật, khuyến nghị cuối đời của WG cho (các) phiên bản trước của thông số kỹ thuật đã được thông qua, bao gồm bất kỳ lý do kỹ thuật nào khiến việc ngừng sử dụng hoặc rút lại bất kỳ phiên bản thông số kỹ thuật nào trước đó được hoặc không được khuyến nghị và lý do cho lời giới thiệu
Bất kỳ mối quan tâm nghiêm trọng nào chưa được giải quyết từ các thành viên BARB hoặc BTI (ví dụ: lý do cho bất kỳ Không có phiếu bầu nào trong quá trình phê duyệt, mối quan tâm do táiview tài liệu kiểm tra hoặc lo ngại rằng đặc điểm kỹ thuật 0.9 / CR nằm ngoài phạm vi của FRD hoặc điều lệ)
Trạng thái chuẩn bị của Profile Bộ điều chỉnh (PTS) hoặc các công cụ cần thiết khác liên quan đến việc áp dụng do BSTS chuẩn bị

Hội đồng quản trị có thể lựa chọn phê duyệt thông số kỹ thuật 0.9 / CR cho thử nghiệm IOP theo yêu cầu của Điều luật [2], trước khi BTI phê duyệt tài liệu thử nghiệm 0.9 / CR và trước khi WG xác nhận rằng kế hoạch thử nghiệm IOP đáp ứng các yêu cầu được xác định trong Phần 4.3.1. 0.9. BoD cũng có thể điều kiện phê duyệt thông số kỹ thuật 0.9 / CR cho thử nghiệm IOP sau khi BTI phê duyệt tài liệu thử nghiệm XNUMX / CR.

0.9 / CR Stage yêu cầu thoát
0.9 / CR Stage đã hoàn tất và Giai đoạn Xác nhận bắt đầu khi Hội đồng Quản trị chấp thuận việc bắt đầu thử nghiệm IOP.

4.4 Miễn trừ Quy trình Phát triển Đặc điểm

WG có thể yêu cầu từ bỏ một hoặc nhiều bước quy trình sau:

0.5 / DIPD Stage
0.7 / FIPD Stage
Kiểm tra IOP trong Giai đoạn xác thực

Để yêu cầu từ bỏ, WG phải sử dụng mẫu từ bỏ quy trình do Bluetooth SIG [8] cung cấp và gửi yêu cầu từ bỏ cho từng ủy ban (tức là BARB hoặc BTI) được yêu cầuview hoặc phê duyệt thông số kỹ thuật dự thảo hoặc các tài liệu kiểm tra liên quan tại stage rằng WG đề xuất từ bỏ, và mỗi ủy ban trong số đó phải chấp thuận yêu cầu từ bỏ.

Yêu cầu từ bỏ phải bao gồm những điều sau:

Một nhận dạng của stage (các) mà WG muốn từ bỏ
Một sự biện minh tại sao stage (s) nên được miễn
Việc xác định từng ủy ban (tức là BTI và / hoặc BARB) được yêu cầu đểview và chấp thuận yêu cầu từ bỏ

Ủy ban xem xét sự từ bỏ có thể yêu cầu đại diện của WG trình bày để biện minh cho sự từ bỏ theo quy trình SMPD trước khi quyết định yêu cầu từ bỏ.

Nếu một người từ bỏ yêu cầu từ bỏ nhiều bước và một phần của sự từ bỏ bị từ chối và một phần được chấp thuận, thì phản hồi của ủy ban phải cho biết bước nào trong yêu cầu từ bỏ đã được chấp thuận và bước nào đã bị từ chối. Nếu một yêu cầu từ chối bị từ chối, thông báo từ chối phải bao gồm các lý do từ chối.

5. Giai đoạn xác nhận

Trong Giai đoạn Xác thực, WG sẽ thực hiện kiểm tra IOP trên đặc điểm kỹ thuật 0.9 / CR với mục tiêu cung cấp báo cáo kiểm tra IOP cho BARBview và phê duyệt. Bất cứ khi nào có thể, nên tiến hành thử nghiệm IOP đối với các cải tiến đặc điểm kỹ thuật dựa trên đặc điểm kỹ thuật dự thảo tích hợp. Ngoài ra, thành viên Review, theo yêu cầu của Điều lệ [2], bắt đầu trong giai đoạn này.

Nếu đặc điểm kỹ thuật (hoặc nâng cao) không yêu cầu kiểm tra IOP, thì kiểm tra IOP trong Giai đoạn xác thực có thể được miễn bằng cách sử dụng quy trình được mô tả trong Phần 4.4.

Trong suốt quá trình kiểm tra IOP (có thể là một hoặc nhiều sự kiện), WG phải theo dõi các vấn đề bằng cách sử dụng hệ thống theo dõi vấn đề của Bluetooth SIG và lặp lại để kết hợp các bản cập nhật cho đặc điểm kỹ thuật dự thảo, tài liệu kiểm tra và kế hoạch kiểm tra IOP. Sau khi thử nghiệm IOP kết thúc, WG phải hoàn thành cập nhật cho bản thảo đặc điểm kỹ thuật và tài liệu thử nghiệm để giải quyết tất cả các vấn đề, đồng thời chuẩn bị và gửi báo cáo thử nghiệm IOP cho BARB để táiview và phê duyệt. Điều này được minh họa trong Hình 5.1.

Trong Giai đoạn Xác thực, có một số hoạt động có thể bắt đầu. Các hoạt động này có thể diễn ra song song và bao gồm:

Thông số kỹ thuật 0.9 / CR được BoD phê duyệt được BSTS cung cấp cho tất cả các thành viên với thông báo về việc bắt đầu thành viên Review thời hạn theo yêu cầu của Điều lệ.
Mọi cập nhật bắt buộc đều được tích hợp vào CSS (có thể được nhúng trong CR viết tắt của thông số kỹ thuật).
Các định nghĩa về đặc tính hoặc mô tả được đưa vào đặc điểm kỹ thuật GSS cũng như PTS để kiểm tra IOP.
Các định nghĩa thuộc tính lưới được tích hợp vào đặc tả MDP cũng như PTS để kiểm tra IOP.
BSTS cho phép đăng ký nền tảng IOP và công cụ nhập kết quả để chuẩn bị cho thử nghiệm IOP.
Kiểm tra IOP, nếu được yêu cầu (xem Phần 5.1).
Review nhận xét và các vấn đề, bao gồm cả những nhận xét được gửi do kết quả của thử nghiệm IOP, được xử lý và các thay đổi được đưa vào bản thảo đặc tả.

5.1 Kiểm tra IOP

Mục tiêu chính của thử nghiệm IOP là xác thực thông số kỹ thuật bằng cách, ví dụample, kiểm tra tính chính xác và không rõ ràng trong văn bản,viewing đối với bất kỳ lỗi và thiếu sót thiết kế cơ bản nào, đồng thời cung cấp xác nhận đối với các yêu cầu đã thiết lập trước đó được phát triển trước đó trong quá trình phát triển đặc điểm kỹ thuật. Thử nghiệm IOP có thể dẫn đến những thay đổi đối với đặc điểm kỹ thuật dự thảo và nhiều sự kiện thử nghiệm IOP có thể là cần thiết để hoàn thành tất cả thử nghiệm bắt buộc.

Điều quan trọng là cung cấp cho các thành viên bên ngoài WG cơ hội tham gia thử nghiệm IOP vì họ cung cấp một view của thông số kỹ thuật và có thể phát hiện ra các khu vực không rõ ràng trong đặc điểm kỹ thuật mà có thể không rõ ràng đối với các thành viên của WG, những người đã phát triển dự thảo. Trước mỗi sự kiện thử nghiệm IOP, BSTS sẽ cung cấp chi tiết sự kiện, đặc tả bản nháp mới nhất, Bộ thử nghiệm và kế hoạch thử nghiệm IOP và sẽ thông báo cho tất cả các thành viên một tháng trước mỗi sự kiện. Đặc tả bản nháp cập nhật, Bộ thử nghiệm và kế hoạch thử nghiệm IOP được sử dụng tại sự kiện thử nghiệm IOP phải có sẵn ít nhất một tuần trước mỗi sự kiện.

Trong quá trình thử nghiệm IOP, các tổ hợp nền tảng theo cặp sẽ cố gắng thực hiện các thử nghiệm và những người tham gia thử nghiệm IOP sẽ ghi lại kết quả đạt / không đạt của mỗi bài kiểm tra và nhận xét. Bản tóm tắt ẩn danh về các kết quả này (ví dụ: “Nền tảng A”, “Nền tảng B”, v.v.) và bất kỳ nhận xét nào, sẽ được thu thập trong các sự kiện thử nghiệm IOP và cung cấp cho các thành viên của WG trong và sau IOP sự kiện thử nghiệm. Trong trường hợp cần thêm thông tin để hiểu rõ hơn về bất kỳ nhận xét hoặc lỗi nào xảy ra trong quá trình thử nghiệm IOP, BSTS có thể đóng vai trò trung gian để thu thập thêm thông tin từ thành viên gửi.

Nếu có thể, PTS nên được cập nhật để hỗ trợ kiểm tra IOP với các nền tảng ở tất cả các lớp phía trên Giao diện Bộ điều khiển Máy chủ (HCI) và có mặt tại các sự kiện kiểm tra IOP cho các lớp đó. Các công cụ kiểm tra khác cũng có thể có mặt tại các sự kiện kiểm tra IOP. Bản tóm tắt kết quả thử nghiệm bằng PTS hoặc các công cụ thử nghiệm khác (nếu có) phải được đưa vào báo cáo thử nghiệm IOP.

Thử nghiệm IOP sẽ được mở cho tất cả các thành viên muốn cung cấp triển khai nguyên mẫu, tuy nhiên, Bluetooth SIG có thể điều kiện tham gia khi chấp nhận các thỏa thuận với Bluetooth SIG (bao gồm cả thỏa thuận tham gia và bảo mật). WG chịu trách nhiệm xử lý và giải quyết các vấn đề được phát hiện trong quá trình thử nghiệm IOP và cập nhật các tài liệu bị ảnh hưởng; Các thay đổi được WG phê duyệt phải được kết hợp dưới dạng các bản cập nhật đối với đặc điểm kỹ thuật dự thảo và tài liệu thử nghiệm để sử dụng tại mỗi sự kiện thử nghiệm IOP.

Trước Giai đoạn Xác thực, WG có thể thực hiện kiểm tra IOP sơ bộ tại các sự kiện chỉ dành cho các thành viên của WG, tuy nhiên, kết quả của kiểm tra không chính thức có thể không được đưa vào kết quả kiểm tra IOP.

Có thể xảy ra trường hợp tuân theo tất cả các bước dẫn đến sự kiện thử nghiệm IOP đầu tiên, bao gồm cả ngày và địa điểm IOP đã thông báo với ý định bắt đầu thử nghiệm IOP, nhưng sự chấp thuận của BoD đã không được bảo đảm trước khi bắt đầu sự kiện thử nghiệm. Trong trường hợp này, Hội đồng quản trị có thể cho phép đưa các kết quả thử nghiệm được thu thập trước khi Hội đồng quản trị chấp thuận bắt đầu thử nghiệm IOP, miễn là các kết quả thu thập được dựa trên cùng một thông số kỹ thuật và Bộ thử nghiệm đã được Hội đồng quản trị phê duyệt.

Kiểm tra IOP không bắt buộc đối với các cải tiến đối với thông số kỹ thuật CSS, GSS hoặc MDP.

Báo cáo kiểm tra IOP
Sau khi quá trình kiểm tra IOP hoàn tất, WG phải gửi báo cáo kiểm tra IOP cho BARB với mục tiêu chứng minh rằng số lượng nền tảng độc lập được yêu cầu đã vượt qua các bài kiểm tra bắt buộc. BARB phải lạiview và phê duyệt hoặc từ chối báo cáo kiểm tra IOP và sẽ thông báo cho WG nếu cần kiểm tra IOP bổ sung trước khi gửi gói thông số kỹ thuật Dự thảo biểu quyết cho Hội đồng quản trị. BSTS và WG phải đảm bảo rằng không có thông tin nhận dạng thành viên nào xuất hiện trong báo cáo kiểm tra IOP trước khi gửi báo cáo cho BARB.

Báo cáo kiểm tra IOP phải bao gồm:

Danh sách tất cả các sự kiện kiểm tra IOP đã xảy ra trong Giai đoạn xác thực bao gồm ngày và địa điểm của chúng.
Số lượng các công ty thành viên và các nền tảng độc lập đã tham gia vào mỗi sự kiện IOP bao gồm cả việc PTS có được sử dụng hay không.
Danh sách các phiên bản đặc điểm kỹ thuật, Bộ thử nghiệm và gói thử nghiệm IOP được sử dụng tại mỗi sự kiện.
Bản tóm tắt điều hành nêu rõ liệu tất cả các trường hợp thử nghiệm có đáp ứng các tiêu chí vượt qua tối thiểu hay không.
Bản tóm tắt về bất kỳ phương sai nào so với các yêu cầu của kế hoạch thử nghiệm IOP được xác định trong Phần 4.3.1 và cơ sở lý luận cho mỗi phương sai.
Bản tóm tắt về phạm vi PTS cho các trường hợp thử nghiệm trong Bộ thử nghiệm.
Danh sách tất cả các trường hợp thử nghiệm (bao gồm cả các thử nghiệm tương thích ngược) từ kế hoạch thử nghiệm IOP, số lần vượt qua thử nghiệm, số lần thử nghiệm không thành công và liệu các tiêu chí tối thiểu có được đáp ứng cho mỗi trường hợp thử nghiệm hay không, bao gồm giải thích tại sao bất kỳ yêu cầu nào không được gặp.
Bản tóm tắt các vấn đề, nhận xét và câu hỏi tại mỗi sự kiện (bao gồm những filed chống lại đặc điểm kỹ thuật trong quá trình thử nghiệm IOP) và ảnh hưởng đến đặc điểm kỹ thuật và tài liệu thử nghiệm.

5.2 Yêu cầu thoát giai đoạn xác thực

Giai đoạn Xác thực đã hoàn tất và Giai đoạn Phê duyệt / Áp dụng bắt đầu khi BARB đã phê duyệt báo cáo thử nghiệm IOP (trừ khi thử nghiệm được BARB từ bỏ) và tất cả các yêu cầu sau đã được đáp ứng:

BSTS đã cung cấp thông số kỹ thuật 0.9 / CR được phê duyệt cho tất cả các thành viên cho Thành viên Review theo yêu cầu của Điều lệ và thông báo cho tất cả các thành viên về tính khả dụng của nó.
Tất cả các vấn đề được xác định trong quá trình thử nghiệm IOP và có tác động đến thử nghiệm, đã được kết hợp và thử nghiệm.
WG đã hoàn thành thử nghiệm IOP (trừ khi thử nghiệm được BARB từ bỏ).

6. Giai đoạn tiếp nhận / phê duyệt

Trong Giai đoạn Tiếp nhận / Phê duyệt, thông số kỹ thuật và các tài liệu kiểm tra liên quan được hoàn thiện, nhận được phê duyệt BARB, BQRB và BTI, thông báo về Ngày nhận con nuôi được đề xuất cùng với phiên bản cuối cùng của dự thảo thông số kỹ thuật được trình lên Hội đồng quản trị để thông qua ( Dự thảo biểu quyết), và gói thông số kỹ thuật cuối cùng được đệ trình lên Hội đồng quản trị. Sau thời hạn tối thiểu của Thành viên Review yêu cầu của Điều lệ [2]) đã được đáp ứng, Hội đồng quản trị sẽ xem xét các đặc điểm kỹ thuật để thông qua vào Ngày nhận con nuôi. Sau khi thông qua, thông số kỹ thuật được xuất bản và hệ thống chứng chỉ được kích hoạt. Giai đoạn Tiếp nhận / Phê duyệt được minh họa trong Hình 6.1.

6.1 Dự thảo biểu quyết

Bản thảo bỏ phiếu được tạo bằng cách kết hợp các bản cập nhật (được cung cấp trong Giai đoạn xác thực) vào các tài liệu đặc điểm kỹ thuật bắt buộc và chuẩn bị bản thảo cuối cùng của thông số kỹ thuật mới. Đối với các cải tiến về đặc điểm kỹ thuật, BSTS sẽ tạo thông số kỹ thuật tích hợp bằng cách tích hợp một hoặc nhiều CR (các) CR vào phiên bản cao hơn đã được thông qua trước đó của thông số kỹ thuật (xem Phần 4.3.2) nếu chưa hoàn thành trước Giai đoạn xác thực.

Nếu các thay đổi được thực hiện đối với thông số kỹ thuật trong giai đoạn này và WG, BARB hoặc BTI xác định rằng bất kỳ thay đổi nào yêu cầu kiểm tra IOP bổ sung, thông số kỹ thuật sẽ quay trở lại phần kiểm tra IOP của Giai đoạn xác thực để WG thực hiện các kiểm tra bổ sung. Trong Giai đoạn Tiếp nhận / Phê duyệt, các tài liệu sau sẽ được hoàn thành và cung cấp cho Hội đồng Quản trị trước Ngày Nhận con nuôi:

Dự thảo biểu quyết
Tất cả các thông số kỹ thuật hỗ trợ (ví dụ: CSS, GSS, MDP) theo yêu cầu cho loại thông số kỹ thuật (hoặc nâng cao) liên quan, nếu chưa được thông qua trước đó
Đối với các cải tiến về đặc điểm kỹ thuật, phiên bản được theo dõi thay đổi của phiên bản thông số kỹ thuật được thông qua hiển thị những thay đổi được đề xuất trong Dự thảo biểu quyết
Mô tả từ WG về bất kỳ yêu cầu tương thích ngược nào (như mô tả trong Phần 3.3.2) chưa được đáp ứng và lý do cho bất kỳ trường hợp miễn trừ nào
Mô tả từ WG về bất kỳ yêu cầu nào của kế hoạch kiểm tra IOP (như mô tả trong Phần 4.3.1) chưa được đáp ứng và lý do giải thích cho bất kỳ sai lệch nào cùng với báo cáo kiểm tra IOP (có thể được cung cấp bằng cách cung cấp liên kết đến bản sao trên Bluetooth SIG webĐịa điểm)
Khuyến nghị từ WG về việc ngừng sử dụng hoặc rút lại bất kỳ phiên bản nào trước đó của thông số kỹ thuật được thông qua cùng với lời giải thích, nêu bật những thay đổi kể từ 0.9 / CR Stage khuyến nghị cuối đời
Bản tóm tắt, do WG chuẩn bị, về những thay đổi đối với các tính năng hoặc chức năng kể từ đặc điểm kỹ thuật 0.9 / CR (nếu có)
Một bản tóm tắt, do BARB soạn thảo, về mối quan tâm của các thành viên BARB rằng thông số kỹ thuật do WG đưa ra nằm ngoài phạm vi điều lệ đã được Hội đồng quản trị phê duyệt (nếu có)
Danh sách các vấn đề pháp lý còn lại chưa được giải quyết từ luật phápview (nếu có)
Bộ thử nghiệm được BTI phê duyệt, cùng với bản tóm tắt được WG phê duyệt về phạm vi thử nghiệm của đặc tả Dự thảo biểu quyết. Trong trường hợp chức năng mới được bổ sung hoặc sửa đổi mà không có phạm vi kiểm tra, cần có văn bản giải thích cho sự thiếu sót
ICS và IXIT được BTI chấp thuận (nếu đặc điểm kỹ thuật yêu cầu)
TCRL được cả BTI và BQRB phê duyệt
Báo cáo do BSTS cùng với BTI chuẩn bị về trạng thái sẵn sàng của công cụ (ví dụ: PTS và các công cụ kiểm tra khác, Bluetooth Launch Studio) bao gồm nếu bất kỳ trường hợp kiểm tra nào trong TCRL không được công cụ kiểm tra hỗ trợ
Một bản tóm tắt, do WG chuẩn bị, về tất cả các con số được chỉ định cần thiết
Một danh sách kiểm tra việc áp dụng do BSTS và WG chuẩn bị cho thấy rằng tất cả các nội dung phân phối trong phần này đều đã được hoàn thành
Mọi thông tin khác do HĐQT yêu cầu

Trong Giai đoạn Thông qua / Phê duyệt, WG nên sử dụng hệ thống theo dõi vấn đề của Bluetooth SIG để nắm bắt các vấn đề và nhận xét chống lại đặc điểm kỹ thuật dự thảo và tài liệu thử nghiệm để chúng được tính đến trong quá trình hoàn thiện đặc điểm Dự thảo biểu quyết. Để nâng cao đặc điểm kỹ thuật, tất cả các lỗi được phê duyệt có liên quan (tức là các lỗi được phê duyệt chưa được tích hợp) phải được kết hợp và phải được xác định bằng cách sử dụng các thay đổi được theo dõi.

WG phải gửi bản thảo đặc tả cuối cùng cho BSTS để có thẩm quyền hợp phápview. Đối với các thông số kỹ thuật mới, luật phápview sẽ bao gồm toàn bộ thông số kỹ thuật. Đối với các cải tiến về đặc điểm kỹ thuật,view sẽ tập trung chủ yếu vào các phần đã thay đổi của đặc điểm kỹ thuật. Mục đích của pháp lý táiview chủ yếu là để xác định các rủi ro pháp lý mà WG cần xem xét và tìm cách giải quyết. Các phản hồi pháp lý sẽ được phân loại dựa trên mức độ nghiêm trọng. Nếu một pháp lý tùy chọn lạiview được thực hiện ở 0.9 / CR Stage, phiên bản được gửi để hợp phápview phải hiển thị, dưới dạng các thay đổi được theo dõi, tất cả các thay đổi đã được thực hiện kể từ phiên bản đó (được tạo bởi WG hoặc BSTS). Sau khi hoàn thành pháp lý táiview, WG và BSTS sẽ thống nhất ý kiến phản hồi để đưa vào bản thảo đặc tả. Nếu có bất kỳ ý kiến pháp lý nào chưa được giải quyết từ luật sưview về dự thảo đặc tả, Chủ tịch WG có thể yêu cầu thời gian trong chương trình nghị sự của HĐQT để thống nhất cách giải quyết.

Song song với pháp lý táiview, WG phải gửi bản thảo đặc tả cho BARB để táiview. Sau lần gửi đầu tiên cho BARB, BSTS sẽ thông báo cho tất cả các thành viên rằng bản thảo đặc tả đã được gửi cho BARB để táiview và nó cũng có sẵn cho Thành viên Review. Nếu WG gửi các bản cập nhật cho đặc điểm kỹ thuật dự thảo để BARB re-review, BSTS sẽ gửi thông báo bổ sung cho tất cả các thành viên theo định kỳ.

Sau khi hoàn thành BARB lạiview, WG và BARB sẽ thống nhất ý kiến phản hồi để đưa vào bản thảo đặc tả.

Nếu pháp lý táiview dẫn đến bất kỳ thay đổi quan trọng nào, bổ sungview bởi BARB có thể được yêu cầu. Tương tự, nếu BARB lạiview dẫn đến bất kỳ thay đổi quan trọng nào, BSTS sẽ xác định xemview những thay đổi đó là bắt buộc. Sau khi hoàn thành pháp lý táiview và BARB lạiview, BARB phải chấp thuận hoặc từ chối Dự thảo biểu quyết.

Nếu bất kỳ tài liệu kiểm tra nào yêu cầu cập nhật, BSTS sẽ hỗ trợ WG cập nhật tài liệu kiểm tra. BTI phải chấp thuận hoặc từ chối các tài liệu thử nghiệm. Nếu được BTI chấp thuận, BTI sẽ hỗ trợ hoàn thiện TCRL và gửi tài liệu này đến BQRB cùng với ICS, IXIT và Test Suite liên quan. BSTS sẽ ước tính ngày họp của Hội đồng quản trị khi Hội đồng quản trị dự định bỏ phiếu về việc thông qua Dự thảo biểu quyết (Ngày thông qua) và cung cấp BTI cho nó để sử dụng trong TCRL. Phê duyệt BARB đối với đặc điểm kỹ thuật, phê duyệt BTI của tất cả các tài liệu thử nghiệm (bao gồm Bộ thử nghiệm, TCRL, ICS và IXIT) và phê duyệt BQRB của TCRL phải xảy ra vào hoặc trước Ngày áp dụng.

BSTS sẽ thông báo cho tất cả các thành viên về việc hoàn thiện và tính sẵn có của Dự thảo biểu quyết và Ngày thông qua. Ngày nhận con nuôi sẽ được ấn định không sớm hơn 60 ngày sau khi các thành viên được thông báo về thông số kỹ thuật 0.9 / CR đã được BoD phê duyệt, trừ khi Thành viên Review Hội đồng quản trị rút ngắn thời gian phù hợp với Điều lệ và ít nhất 14 ngày sau khi thông báo về Ngày thông qua được cung cấp cho các thành viên phù hợp với Điều lệ. Đối với các trường hợp nhiều CR đã được tích hợp vào một Dự thảo biểu quyết, việc bắt đầu của Thành viên Review là ngày mà các thành viên được thông báo về CR được BoD phê duyệt gần đây nhất.

Sau khi thông báo về Ngày áp dụng được cung cấp cho các thành viên, cho phép sửa chữa các lỗi đánh máy trong Bản Dự thảo Biểu quyết đã được BoD phê duyệt. Đặc điểm kỹ thuật về thời gian áp dụng được minh họa trong Hình 6.2.

6.2 Số được ấn định

Bluetooth SIG duy trì một tập hợp các số được chỉ định có sẵn công khai trên Các số được chỉ định của Bluetooth SIG webtrang web [7]. Các số được chỉ định này được nhóm trong các không gian số khác nhau (một tập hợp các số có liên quan không trùng lặp). Các số được chỉ định có thể trùng lặp với các số được chỉ định khác trong các không gian số khác nhau, nhưng không số nào trong một không gian số được phép sử dụng lại. Các không gian số khác nhau được xác định trong đặc tả xác định việc sử dụng các số được chỉ định.

Sau khi BARB phê duyệt báo cáo kiểm tra IOP, WG sẽ gửi yêu cầu đến BARB để chỉ định các số mới trong (các) không gian số theo yêu cầu của thông số kỹ thuật cuối cùng. BARB sẽ lạiview yêu cầu và làm việc với BSTS để xác định các số được chỉ định. Sau khi được BARB chấp thuận, BSTS sẽ lên lịch xuất bản các số được chỉ định để công bố công khai trên Các số được ấn định của Bluetooth SIG webtrang web [7] trong vòng một tuần kể từ khi thông số kỹ thuật.

Sau khi công bố các số được chỉ định trên Bluetooth SIG Assigned Numbers webtrang web hoặc trong một thông số kỹ thuật được chấp nhận xảy ra, các con số được chỉ định là không thay đổi (không thay đổi về giá trị hoặc ý nghĩa). Nếu chúng không sử dụng được vì lý do nào đó, chúng sẽ trở thành các giá trị được bảo lưu và không được phép sử dụng lại.

6.3 Yêu cầu thoát khỏi Giai đoạn tiếp nhận / Phê duyệt

Giai đoạn Phê duyệt / Thông qua hoàn tất khi Hội đồng Quản trị đã thông qua các thông số kỹ thuật và các hoạt động sau thông qua đã được hoàn thành:

BSTS đã công bố công khai những con số cuối cùng được chỉ định trên Bluetooth SIG webđịa điểm.
BSTS đã công bố công khai thông số kỹ thuật được thông qua trên Bluetooth SIG webđịa điểm
BSTS đã cung cấp công khai tất cả các tài liệu hỗ trợ (ví dụ: CSS, GSS, MDP) cho các thông số kỹ thuật liên quan trên Bluetooth SIG webđịa điểm.
BSTS đã cung cấp các tài liệu kiểm tra liên quan cho tất cả các thành viên trên Bluetooth SIG webđịa điểm.
Đối với các cải tiến về đặc điểm kỹ thuật, BSTS đã thực hiện một phiên bản theo dõi thay đổi thông tin của phiên bản thông số kỹ thuật đã được thông qua trước đó với tất cả các thay đổi được thực hiện bởi phiên bản mới được thông qua và cung cấp cho tất cả các thành viên trên Bluetooth SIG webđịa điểm.
BSTS đã kích hoạt hệ thống chứng nhận.
BSTS đã thông báo cho tất cả các thành viên về tính khả dụng của thông số kỹ thuật được thông qua và tất cả các tài liệu hỗ trợ.

Bluetooth SIG có kế hoạch hoàn thành các hoạt động sau khi thông qua này trong vòng một tuần sau khi thông qua thông số kỹ thuật.

7. Giai đoạn bảo trì thông số kỹ thuật

Giai đoạn Duy trì Đặc điểm kỹ thuật bắt đầu sau khi Giai đoạn Tiếp nhận / Phê duyệt hoàn tất. Nếu các vấn đề được tìm thấy (ví dụ: sự không rõ ràng về từ ngữ hoặc lỗi kỹ thuật) với đặc điểm kỹ thuật hoặc các tài liệu kiểm tra liên quan, chúng phải được ghi lại bằng cách tạo các đề xuất errata bằng công cụ Bluetooth SIG Errata. Các đề xuất sai phạm về đặc điểm kỹ thuật sẽ được xử lý, phân loại và phê duyệt theo EPD [3]. Lỗi của Test Suite được xử lý và phân loại theo TSTO [5]. Nếu có bất kỳ xung đột nào giữa SMPD và EPD hoặc TSTO, SMPD sẽ được ưu tiên.

Thông số kỹ thuật chỉ được sử dụng để sửa lỗi kỹ thuật hoặc biên tập trong thông số kỹ thuật Bluetooth cuối cùng được thông qua. Việc bổ sung, thay đổi và loại bỏ chức năng chỉ có thể được thực hiện bằng quy trình nâng cao đặc điểm kỹ thuật được xác định trước đó trong tài liệu này.

7.1 Tiến trình erratum nhanh

Khi một lỗi được chấp thuận theo quy trình được xác định trong EPD [3], WG, BARB hoặc BSTS có thể khuyến nghị rằng việc đó được coi là khẩn cấp và cần được giải quyết nhanh chóng. Khi điều này xảy ra, BSTS cùng với WG hoặc BARB sẽ trình đề xuất với BoD. Hội đồng Quản trị sẽ quyết định chấp nhận hay từ chối khuyến nghị. Nếu đề xuất được chấp nhận, BSTS sẽ ngay lập tức kết hợp erratum đã được phê duyệt vào mẫu erratum [8] và làm việc với WG có trách nhiệm để hoàn thiện Bản sửa lỗi Errata Nhanh để gửi cho WG để táiview và phê duyệt.

Một quaview của quá trình erratum được giải quyết nhanh được minh họa trong Hình 7.1.

Các tài liệu sau phải được hoàn thành và cung cấp cho Hội đồng quản trị trước Ngày nhận con nuôi:

Bản dự thảo đã được BARB phê duyệt Hiệu chỉnh Errata nhanh.
Mô tả từ WG về bất kỳ yêu cầu tương thích ngược nào (như mô tả trong Phần 3.3.2) chưa được đáp ứng và lý do cho bất kỳ trường hợp miễn trừ nào.
Danh sách các vấn đề pháp lý còn lại chưa được giải quyết từ luật phápview (nếu có).
Bộ thử nghiệm được BTI phê duyệt, ICS và IXIT (nếu erratum yêu cầu).
TCRL được BTI và BQRB phê duyệt (nếu được yêu cầu bởi erratum).
Một báo cáo được hoàn thành bởi BSTS cùng với BTI về trạng thái sẵn sàng của công cụ (ví dụ: PTS và các công cụ kiểm tra khác, Bluetooth Launch Studio) bao gồm nếu bất kỳ trường hợp kiểm tra nào trong TCRL không được hỗ trợ bởi các công cụ kiểm tra và giải thích (nếu erratum yêu cầu ).
Một danh sách kiểm tra việc áp dụng được hoàn thành bởi BSTS và WG cho thấy rằng tất cả các công việc phân phối trong phần này đã được hoàn thành.
Tất cả các thông tin khác do HĐQT yêu cầu.

BSTS sẽ làm việc với WG chịu trách nhiệm để hoàn thiện bản thảo Sửa lỗi Errata Nhanh và tạo một phiên bản để đệ trình cho WG chịu trách nhiệm.view và phê duyệt.

WG phải gửi Bản sửa lỗi Errata Nhanh chóng cho BSTS để có thẩm quyền hợp phápview. Sau khi hoàn thành pháp lý táiview, WG và BSTS sẽ đồng ý về các phản hồi sẽ được đưa vào Bản sửa lỗi Errata Nhanh. Nếu có bất kỳ ý kiến pháp lý nào chưa được giải quyết từ bộ phận pháp lýview về việc Điều chỉnh Errata Nhanh chóng, Chủ tịch WG có thể yêu cầu thời gian trong chương trình nghị sự của HĐQT để xin ý kiến của HĐQT về giải pháp.

Song song với pháp lý táiview, WG phải gửi Bản sửa lỗi Errata Nhanh cho BARB để táiview. Sau khi Bản sửa lỗi khẩn cấp được gửi tới BARB, BSTS sẽ giúp tất cả các thành viên có thể truy cậpview và thông báo cho tất cả các thành viên về tính khả dụng của nó. Sau khi hoàn thành BARB lạiview, WG và BARB sẽ đồng ý về phản hồi để được đưa vào Bản sửa lỗi Nhanh.

Nếu bất kỳ tài liệu kiểm tra nào yêu cầu cập nhật, BSTS sẽ hỗ trợ WG cập nhật tài liệu kiểm tra. Sau khi BTI phê duyệt các tài liệu thử nghiệm, BTI sẽ hỗ trợ hoàn thiện TCRL và gửi tài liệu đến BQRB cùng với ICS, IXIT và Bộ thử nghiệm liên quan nếu có. BSTS sẽ ước tính Ngày nhận con nuôi và cung cấp cho BTI để sử dụng trong TCRL. Việc phê duyệt BARB đối với Sửa lỗi nhanh, BTI phê duyệt tất cả các tài liệu thử nghiệm (bao gồm Bộ thử nghiệm, TCRL, ICS và IXIT nếu có) và phê duyệt BQRB của TCRL phải xảy ra vào hoặc trước Ngày áp dụng.

BSTS sẽ thông báo cho tất cả các thành viên về việc hoàn thiện và sẵn sàng của Sửa lỗi Errata Nhanh và Ngày áp dụng được đề xuất. Ngày Nhận con nuôi sẽ được thiết lập và thông báo cho tất cả các thành viên phù hợp với Điều lệ [2] và Ngày Nhận con nuôi sẽ là ít nhất 14 ngày sau khi thông báo được cung cấp cho các thành viên. Sau khi thông báo về Ngày nhận con nuôi được đề xuất được cung cấp cho các thành viên, Hội đồng quản trị có thể phê duyệt sửa chữa các lỗi đánh máy trong Bản sửa lỗi Errata Nhanh mà không cần cung cấp thêm thông báo về Ngày nhận con nuôi được đề xuất và chờ 14 ngày theo yêu cầu.

Bluetooth SIG sẽ công bố công khai Bản sửa lỗi sai nhanh đã được thông qua và có kế hoạch thực hiện việc này trong vòng một tuần sau khi áp dụng. Thông báo về tính khả dụng của nó sẽ được BSTS phát hành cho tất cả các thành viên.

Quá trình xử lý khẩn cấp hoàn tất khi Hội đồng quản trị đã thông qua Sửa lỗi Errata Nhanh và các hoạt động sau thông qua đã hoàn tất:

BSTS đã công bố công khai Bản sửa lỗi sai nhanh đã được thông qua và các tài liệu kiểm tra liên quan (nếu erratum yêu cầu) trên Bluetooth SIG webđịa điểm.
BSTS đã kích hoạt hệ thống chứng nhận (nếu được yêu cầu bởi erratum).
BSTS đã thông báo cho tất cả các thành viên về tính khả dụng của Bản sửa lỗi Errata Nhanh đã được thông qua.

Khi hoàn thành các hoạt động này, Sửa lỗi Errata sẽ được lên lịch để tích hợp vào các thông số kỹ thuật bị ảnh hưởng như một phần của việc nâng cao thông số kỹ thuật đã lên kế hoạch hoặc trong một bản phát hành bảo trì sắp tới như được mô tả trong Phần 7.2.

7.2 Quy trình phát hành bảo trì (thông số kỹ thuật .Z)

Trên cơ sở gần như hàng năm, BSTS sẽ xác định xem có bất kỳ lỗi nào đã được phê duyệt (gọi là Sửa lỗi Errata) được phân loại là Kỹ thuật / Cao hoặc Kỹ thuật / Phê bình và vẫn chưa được đưa vào văn bản của bất kỳ thông số kỹ thuật đang hoạt động nào (ví dụ: một thông số kỹ thuật được chấp nhận chưa bị phản đối hoặc bị rút lại). Xem Phụ lục A về các định nghĩa phân loại errata. Chủ sở hữu thông số kỹ thuật (hoặc WG được thuê để duy trì thông số kỹ thuật hoặc BARB nếu không có WG nào được thuê để duy trì thông số kỹ thuật) cũng có thể yêu cầu một bản phát hành bảo trì sớm hơn của thông số kỹ thuật đang hoạt động để kết hợp bất kỳ lỗi nào đã được phê duyệt. Sau khi xác định BSTS hoặc yêu cầu của Chủ sở hữu thông số kỹ thuật, quá trình phát hành bảo trì sẽ bắt đầu.

Một quaview của quy trình phát hành bảo trì được minh họa trong Error! Nguồn tham khảo không tìm thấy.

Khi bắt đầu quá trình phát hành bảo trì, BSTS cùng với Chủ sở hữu thông số kỹ thuật, BARB và BTI sẽ phát triển và trình bày kế hoạch cho Hội đồng quản trị để kết hợp Errata Corrections vào phiên bản thông số kỹ thuật đã xuất bản. Kế hoạch được đề xuất phải chỉ ra liệu Errata Corrections sẽ được kết hợp vào một bản phát hành bảo trì của đặc điểm kỹ thuật (ví dụ: phiên bản .Z) hoặc cải tiến đặc điểm kỹ thuật đã được tiến hành (tức là phiên bản XY). Kế hoạch đề xuất cần tính đến việc có thêm bất kỳ tính năng bắt buộc mới nào giữa các phiên bản của thông số kỹ thuật được thông qua hay không, thời gian ước tính khi dự kiến áp dụng nâng cao thông số kỹ thuật tiếp theo và các yếu tố khác.

Sau khi được Hội đồng quản trị phê duyệt kế hoạch, BSTS cùng với Chủ sở hữu thông số kỹ thuật sẽ tiến hành kết hợp tất cả các Sửa lỗi kỹ thuật / trung bình, kỹ thuật / cao và kỹ thuật / nghiêm trọng vào một bản dự thảo thông số kỹ thuật được gọi là “Bản thảo phát hành bảo trì”. Đối với Chỉnh sửa Errata về Biên tập hoặc Kỹ thuật / Thấp, nếu Chỉnh sửa Errata áp dụng cho nhiều phiên bản của thông số kỹ thuật, BSTS sẽ, trừ khi BoD chỉ định khác, chỉ tích hợp các lỗi đó vào phiên bản thông số kỹ thuật cao hơn gần đây nhất ở lần cập nhật tiếp theo của phiên bản đó . Không có thay đổi nào có thể được bao gồm trong Dự thảo phát hành bảo trì ngoài việc kết hợp Sửa lỗi Errata. Mỗi Bản Dự thảo Phát hành Bảo trì phải xác định tất cả các Sửa lỗi Errata được kết hợp bằng cách sử dụng theo dõi thay đổi để hiển thị các thay đổi được đề xuất đối với phiên bản thông số kỹ thuật đã xuất bản đã được thông qua trước đó.

Thời gian kết hợp được đề xuất cho mỗi Bản sửa lỗi Errata trong Dự thảo phát hành bảo trì sẽ phụ thuộc vào tác động của Bộ thử nghiệm: tất cả các Bản sửa lỗi Errata không có tác động của Bộ thử nghiệm có thể được kết hợp ngay lập tức, nhưng các Bản sửa lỗi Errata ảnh hưởng đến Bộ thử nghiệm sẽ được được xử lý sao cho thời gian trùng với bản cập nhật cho TCRL.

BTI và BSTS sẽ thiết lập thời hạn để đưa các Sửa lỗi Errata với tác động của Bộ thử nghiệm vào Dự thảo phát hành bảo trì. Thời hạn này thường là từ 3 đến 6 tháng trước ngày phê duyệt dự kiến của bản phát hành TCRL chính tiếp theo. Sửa lỗi Errata với tác động của Bộ thử nghiệm mà bỏ lỡ thời hạn đưa vào sẽ được xử lý như một phần của bản phát hành TCRL hàng năm tiếp theo. Do đó, trừ khi được yêu cầu phát hành sớm hơn, thời gian tối đa để các Sửa lỗi kỹ thuật / cao hoặc kỹ thuật / nghiêm trọng được đưa vào bản cập nhật thông số kỹ thuật là khoảng 15 đến 18 tháng.

Chủ sở hữu thông số kỹ thuật phải gửi Dự thảo phát hành bảo trì mà họ đã phê duyệt là cuối cùng để có giá trị pháp lýview. Luật pháp lạiview sẽ tập trung chủ yếu vào các phần đã thay đổi của đặc điểm kỹ thuật. Sau khi hoàn thành pháp lý táiview, Chủ sở hữu thông số kỹ thuật và BSTS sẽ đồng ý về phản hồi để đưa vào Dự thảo phát hành bảo trì. Nếu có bất kỳ ý kiến pháp lý nào chưa được giải quyết từ luật sưview trong Dự thảo phát hành bảo trì, Chủ sở hữu đặc điểm kỹ thuật có thể yêu cầu thời gian trong chương trình nghị sự của HĐQT để tìm kiếm ý kiến của HĐQT về giải pháp.

Song song với pháp lý táiview, chủ sở hữu Thông số kỹ thuật phải gửi Bản thảo phát hành bảo trì cho BARB đểview. Sau khi Bản dự thảo phát hành bảo trì được gửi tới BARB, BSTS sẽ giúp tất cả các thành viên có thể truy cậpview và thông báo cho tất cả các thành viên về tính khả dụng của nó. Sau khi hoàn thành BARB lạiview, Chủ sở hữu thông số kỹ thuật và BARB sẽ thống nhất ý kiến phản hồi để đưa vào thông số kỹ thuật dự thảo.

Nếu pháp lý táiview dẫn đến bất kỳ thay đổi quan trọng nào, bổ sungview bởi BARB có thể được yêu cầu. Tương tự, nếu BARB lạiview dẫn đến bất kỳ thay đổi quan trọng nào, BSTS sẽ xác định xemview những thay đổi đó là bắt buộc. Sau khi hoàn thành pháp lý táiview và BARB lạiview, BARB phải phê duyệt hoặc từ chối Dự thảo phát hành bảo trì. Nếu được BARB chấp thuận, điều này sẽ trở thành Dự thảo biểu quyết.

Đối với các Sửa lỗi Errata ảnh hưởng đến tài liệu kiểm tra và nơi mà lỗi kiểm tra tương ứng sẽ được xử lý kịp thời cho bản phát hành TCRL sắp tới, BSTS sẽ làm việc với Chủ sở hữu đặc điểm kỹ thuật và BTI để cập nhật tài liệu kiểm tra. Sau khi BTI phê duyệt các tài liệu thử nghiệm, BSTS sẽ ước tính Ngày nhận con nuôi và cung cấp Ngày nhận con nuôi được đề xuất cho BTI để sử dụng trong TCRL. BTI sẽ phân phối TCRL tới BQRB cùng với ICS, IXIT và Bộ thử nghiệm được liên kết nếu có. Phê duyệt BARB đối với đặc điểm kỹ thuật, phê duyệt BTI của tất cả các tài liệu thử nghiệm (bao gồm Bộ thử nghiệm, TCRL, ICS và IXIT nếu có) và phê duyệt BQRB của TCRL phải xảy ra vào hoặc trước Ngày áp dụng.

BSTS sẽ thông báo cho tất cả các thành viên về việc hoàn thiện và sẵn có của Dự thảo biểu quyết và Ngày áp dụng được đề xuất. Ngày Nhận Con nuôi sẽ được thiết lập và thông báo cho tất cả các thành viên theo Quy chế và Ngày Nhận con nuôi sẽ là ít nhất 14 ngày sau khi thông báo về thông báo được cung cấp cho các thành viên. Sau khi thông báo về Ngày nhận con nuôi được đề xuất được cung cấp cho các thành viên, Hội đồng quản trị có thể chấp thuận sửa chữa các lỗi đánh máy trong Dự thảo biểu quyết mà không cần cung cấp thêm thông báo về Ngày nhận con nuôi được đề xuất và chờ 14 ngày theo yêu cầu.

Các tài liệu sau phải được hoàn thành và cung cấp cho Hội đồng quản trị trước Ngày nhận con nuôi:

Dự thảo biểu quyết
Một phiên bản được theo dõi thay đổi của Dự thảo biểu quyết hiển thị tất cả các thay đổi đối với phiên bản đã thông qua của thông số kỹ thuật có cùng giá trị XY (ví dụ: nếu Dự thảo biểu quyết được đề xuất là phiên bản 1.4.2, các thay đổi sẽ được theo dõi so với 1.4.1 phiên bản của đặc điểm kỹ thuật)
Khuyến nghị từ Chủ sở hữu thông số kỹ thuật về việc ngừng sử dụng hoặc rút lại bất kỳ (các) phiên bản nào trước đó của thông số kỹ thuật đã được thông qua cùng với lời giải thích
Danh sách các vấn đề pháp lý còn lại chưa được giải quyết từ luật phápview (nếu có)
Bộ thử nghiệm được BTI phê duyệt, ICS và IXIT (nếu bản phát hành bảo trì yêu cầu)
TCRL được BTI và BQRB phê duyệt (nếu bản phát hành bảo trì yêu cầu)
Một báo cáo được hoàn thành bởi BSTS cùng với BTI về trạng thái sẵn sàng của công cụ (ví dụ: PTS và các công cụ kiểm tra khác, Bluetooth Launch Studio) bao gồm bất kỳ trường hợp kiểm tra nào trong TCRL không được hỗ trợ bởi các công cụ kiểm tra và giải thích (nếu bảo trì yêu cầu giải phóng)
Danh sách kiểm tra việc áp dụng được hoàn thành bởi BSTS và Chủ sở hữu thông số kỹ thuật cho thấy rằng các sản phẩm phân phối trong phần này đã được hoàn thành
Mọi thông tin khác do HĐQT yêu cầu

Quá trình phát hành bảo trì hoàn tất khi Hội đồng Quản trị đã thông qua Dự thảo biểu quyết và các hoạt động sau thông qua đã hoàn tất:

BSTS đã cung cấp công khai thông số kỹ thuật được thông qua và các tài liệu kiểm tra liên quan (nếu bản phát hành bảo trì yêu cầu) trên Bluetooth SIG webđịa điểm.
BSTS đã tạo ra một phiên bản theo dõi thay đổi thông tin của phiên bản thông số kỹ thuật đã được thông qua trước đó với tất cả các thay đổi được kết hợp trong phiên bản mới được thông qua có sẵn cho tất cả các thành viên trên Bluetooth SIG webđịa điểm.
BSTS đã kích hoạt hệ thống chứng nhận.
BSTS đã thông báo cho tất cả các thành viên về sự sẵn có của đặc điểm kỹ thuật được thông qua và các tài liệu hỗ trợ.

Bluetooth SIG có kế hoạch hoàn thành các hoạt động sau khi thông qua này trong vòng một tuần sau khi thông qua thông số kỹ thuật.

Khi hoàn thành các hoạt động này, thông số kỹ thuật vẫn ở trong giai đoạn Bảo trì thông số kỹ thuật cho đến khi thông số kỹ thuật không được chấp nhận hoặc bị thu hồi, như được định nghĩa trong Phần 8.

8. Đặc điểm kỹ thuật Giai đoạn cuối của vòng đời

Các thông số kỹ thuật có thể không được chấp nhận hoặc bị rút lại khi chúng được thay thế bằng các phiên bản mới hơn, được xác định là không đủ kỹ thuật hoặc vì các lý do khác. Các thông số kỹ thuật không được chấp nhận và đã thu hồi được lưu trữ và không còn được cập nhật. Các thông số kỹ thuật không được chấp nhận và đã thu hồi được xử lý khác nhau trong Chương trình đủ điều kiện Bluetooth.

Bất kỳ thành viên, nhóm hoặc ủy ban nào cũng có thể gửi khuyến nghị không dùng nữa hoặc rút lại một thông số kỹ thuật cùng với dòng thời gian liên quan đến BSTS (qua email tới

đặc điểm kỹ thuật.manager@bl Bluetooth.com) bất kỳ lúc nào. BSTS cũng có thể đề xuất việc ngừng sử dụng hoặc rút lại một thông số kỹ thuật và tiến trình liên quan. BSTS sẽ chuyển khuyến nghị tới BARB và nhóm hoặc ủy ban chịu trách nhiệm duy trì thông số kỹ thuật cho táiview và phản hồi.

BARB và nhóm hoặc ủy ban chịu trách nhiệm sẽ đánh giá các khuyến nghị không dùng nữa hoặc rút lại một đặc điểm kỹ thuật và xem xét các tiêu chí (không đầy đủ) sau:

Có chức năng nào trong phiên bản trước của thông số kỹ thuật đã lỗi thời hoặc không nên được sử dụng không?
Chức năng bắt buộc mới đã được thêm vào các phiên bản sau chưa?
Có những khiếm khuyết nào trong các phiên bản trước làm ảnh hưởng đến hoạt động hoặc khả năng tương tác đã được sửa chữa trong các phiên bản sau và cần thiết để cải thiện các tình huống người dùng hiện có không?
Có chức năng bổ sung trong các phiên bản sau này cần thiết để nâng cao các kịch bản người dùng mới không?
Có cải thiện khả năng sử dụng và khả năng tương tác trong các phiên bản sau không?
Có cải tiến bảo mật trong các phiên bản sau không?

BARB và nhóm hoặc ủy ban chịu trách nhiệm có thể đề xuất một khuyến nghị thay thế.

Sau khi nhận được phản hồi từ BARB hoặc nhóm hoặc ủy ban chịu trách nhiệm duy trì thông số kỹ thuật, BSTS sẽ gửi (các) khuyến nghị và phản hồi cho Hội đồng quản trị để xem xét. Hội đồng quản trị có thể mời nhóm hoặc ủy ban chịu trách nhiệm duy trì các thông số kỹ thuật bị ảnh hưởng để họp và thảo luận về các khuyến nghị. Hội đồng Quản trị sẽ xem xét các khuyến nghị và phản hồi và có thể đồng ý hoặc sửa đổi đề xuất. Hội đồng Quản trị sẽ yêu cầu BSTS thông báo cho tất cả các thành viên về các đề xuất không dùng nữa hoặc rút lại (các) thông số kỹ thuật và (các) mốc thời gian liên quan trong 30 ngày táiview thời gian cho phép tất cả các thành viên cung cấp phản hồi bổ sung trước khi đưa ra quyết định cuối cùng.

HĐQT sẽ xem xét các phản hồi nhận được từ các thành viên. Sau khi Hội đồng Quản trị chấp thuận việc ngừng sử dụng hoặc rút lại một thông số kỹ thuật, BSTS sẽ thông báo cho tất cả các thành viên về quyết định và tiến trình liên quan.

8.1 Ngừng sử dụng

Khi một thông số kỹ thuật không được dùng nữa, những điều sau sẽ xảy ra:

Đặc điểm kỹ thuật sẽ không còn được cập nhật.
WG chịu trách nhiệm sẽ táiview tất cả các lỗi nổi bật được viết dựa trên đặc điểm kỹ thuật không dùng nữa để xác định xem chúng có áp dụng cho các thông số kỹ thuật khác hay không. Errata có thể bị từ chối trong hệ thống errata và được viết lại dựa trên (các) thông số kỹ thuật hiện hành.
WG hoặc BSTS sẽ tạo errata để cập nhật mọi tham chiếu cần thiết đến các thông số kỹ thuật không dùng nữa trong các thông số kỹ thuật khác.
BTI sẽ cập nhật các tài liệu kiểm tra hiện hành để cho biết thông số kỹ thuật ngừng hoạt động.
BSTS sẽ cập nhật Bluetooth SIG webtrang web có hướng dẫn về (các) đặc điểm kỹ thuật thay thế để sử dụng.
Không còn có thể gửi errata mới dựa trên đặc điểm kỹ thuật không dùng nữa.
Thông số kỹ thuật sẽ không được tham chiếu trong bất kỳ thông số kỹ thuật nào trong tương lai.
BSTS sẽ lưu trữ một phiên bản của thông số kỹ thuật được đánh dấu là không dùng nữa để các thành viên truy cập cho các mục đích lịch sử.

8.2 Rút lui

Sau khi thông số kỹ thuật bị rút lại, ngoài các bước áp dụng cho việc ngừng sử dụng, những điều sau sẽ xảy ra:

BTI sẽ cập nhật các tài liệu kiểm tra áp dụng để chỉ ra việc rút lại thông số kỹ thuật.
BSTS sẽ cập nhật Bluetooth SIG webtrang web có hướng dẫn về (các) đặc điểm kỹ thuật thay thế để sử dụng.
BSTS sẽ lưu trữ một phiên bản của thông số kỹ thuật được đánh dấu là đã thu hồi để các thành viên truy cập cho các mục đích lịch sử.

Hội đồng quản trị có thể chọn rút lại một thông số kỹ thuật ngay lập tức mà trước tiên không phản đối thông số kỹ thuật đó.

9. Quy trình giấy trắng

Sách trắng chỉ được tạo ra cho mục đích thông tin. Quy trình sách trắng sau đây áp dụng cho tất cả Bluetooth WG, EG, SG và ủy ban. Phần này không áp dụng cho các tài liệu thông tin chỉ để sử dụng trong Bluetooth SIG.

Quá trình này được minh họa trong Hình 9.1 dưới đây.

Trước khi bất kỳ nhóm hoặc ủy ban nào bắt đầu làm việc trên sách trắng mà họ dự định sẽ được Bluetooth SIG xuất bản, nhóm hoặc ủy ban sẽ chuẩn bị cả bản cập nhật điều lệ được đề xuất xác định rõ nội dung đề xuất của sách trắng và bản trình bày đề xuất trong sách trắng.

Bản trình bày đề xuất bằng giấy trắng tối thiểu phải bao gồm:

Sự cần thiết của sách trắng
Tóm tắt các nội dung đề xuất của sách trắng
Giải thích lý do tại sao nội dung không được khuyến nghị đưa vào như một phần của đặc tả
Đối tượng dự định
Bất kỳ kế hoạch bảo trì nào (ví dụ: thời gian ước tính trước khi phát hành sách trắng này có thể cần thiết)
Các khuyến nghị về cách xử lý các phiên bản trước của sách trắng, nếu có (ví dụ: lưu trữ)

Bản cập nhật điều lệ và bản trình bày đề xuất giấy trắng phải được đệ trình cho BARB lạiview. Khi táiview và phê duyệt bản cập nhật điều lệ của BARB, BSTS sẽ đệ trình bản cập nhật điều lệ lên Hội đồng quản trị để phê duyệt cùng với bản trình bày đề xuất giấy trắng hỗ trợ.

Nếu HĐQT chấp thuận bản cập nhật điều lệ, nhóm hoặc ủy ban có thể tiến hành xây dựng sách trắng.

Khi nhóm hoặc ủy ban đã hoàn thành việc phát triển sách trắng, BSTS sẽ thực hiện biên tập lạiview để nhất quán với Nguyên tắc soạn thảo Bluetooth.

Sau khi giải quyết các ý kiến của BSTS, nhóm phải nộp white paper cho BSTS để được hợp pháp hóaview. Sau khi hoàn thành pháp lý táiview, nhóm và BSTS sẽ thống nhất ý kiến phản hồi để đưa vào sách trắng. Nếu có bất kỳ ý kiến pháp lý nào chưa được giải quyết từ bộ phận pháp lýview trên white paper, chủ tọa nhóm có thể yêu cầu thời gian trong chương trình nghị sự của HĐQT để tìm kiếm ý kiến của HĐQT về giải pháp.

Song song với pháp lý táiview, nhóm phải nộp white paper cho BARB để táiview. Là một phần của táiview, BARB có thể đề xuất xem có nên xóa bất kỳ phần nào của sách trắng ra khỏi sách trắng và kết hợp vào một thông số kỹ thuật theo quy trình trong Phần 3. BARB cũng có thể quyết định gửi sách trắng cho các nhóm hoặc ủy ban khác để táiview. Sau khi hoàn thành BARB lạiview, nhóm và BARB sẽ thống nhất ý kiến phản hồi để đưa vào sách trắng.

Sau khi BARB thông qua sách trắng, sách trắng được BARB phê duyệt sẽ được nhóm tác giả hoặc ủy ban trình lên Hội đồng quản trị để phê duyệt.

Quy trình white paper hoàn tất khi HĐQT đã phê duyệt white paper và các hoạt động sau phê duyệt sau đây đã hoàn tất:

BSTS đã công bố công khai sách trắng đã được phê duyệt trên Bluetooth SIG webđịa điểm.
BSTS thông báo cho tất cả các thành viên về sách trắng đã được phê duyệt.
Nếu sách trắng là sự cải tiến của sách trắng hiện có, BSTS sẽ lưu trữ một phiên bản của sách trắng để các thành viên truy cập cho các mục đích lịch sử.

Bluetooth SIG có kế hoạch hoàn thành các hoạt động sau phê duyệt trong vòng một tuần sau khi sách trắng được phê duyệt.

10. Tài liệu tham khảo

Các tài liệu Bluetooth được tham chiếu có sẵn từ Bluetooth webđịa điểm http://www.bluetooth.com.

Nguyên tắc Soạn thảo Bluetooth (có sẵn trên trang Mẫu & Tài liệu của Nhóm làm việc, tại https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Các quy định của Bluetooth SIG, Inc. (có trên trang Tài liệu quản lý, tại https://www.bluetooth.com/membership-working-groups/membership-types-levels/membership-agreements)
Tài liệu Quy trình Errata Đặc điểm kỹ thuật Bluetooth (có sẵn trên trang Mẫu & Tài liệu của Nhóm làm việc, tại https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Tài liệu Quy trình Nhóm Công tác (có trên trang Mẫu & Tài liệu Nhóm Công tác, tại https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Chiến lược thử nghiệm và thuật ngữ kết thúcview tài liệu (có sẵn trên trang Yêu cầu Kiểm tra Năng lực, tại https://www.bluetooth.com/specifications/qualification-test-requirements)
Đặc điểm kỹ thuật BTI Review Danh sách kiểm tra quy trình (có sẵn trên trang Mẫu & Tài liệu của Nhóm làm việc, tại https://www.bluetooth.com/specifications/working-groups/working-group-templates-documents)
Các số được ấn định của Bluetooth SIG (https://www.bluetooth.com/specifications/assigned-numbers)
Mẫu và tài liệu của Nhóm làm việc (có sẵn trên trang Mẫu và tài liệu của Nhóm làm việc, tại https://www.bluetooth.com/membership-working-groups/working-groups/working-group-templates-documents)
Bổ sung Đặc điểm kỹ thuật GATT (GSS) (có sẵn trên trang Thông số kỹ thuật GATT, tại https://www.bluetooth.com/specifications/gatt)
Gửi ý tưởng cho một đặc điểm kỹ thuật mới https://www.bluetooth.com/specifications/submit-an-idea-for-a-specification

11. Từ viết tắt và chữ viết tắt

Bảng A: Từ viết tắt và từ viết tắt

Phụ lục A - Phân loại mức độ nghiêm trọng của Erratum

Phụ lục này tóm tắt các hướng dẫn phân loại mức độ nghiêm trọng cho một erratum đặc điểm kỹ thuật. Bảng này sẽ được thêm vào bản sửa đổi trong tương lai của EPD, và sau đó phần này sẽ bị xóa.

Đọc thêm về hướng dẫn này và tải xuống PDF:

Tài liệu Quy trình Quản lý Đặc điểm kỹ thuật (SMPD) - PDF được tối ưu hóa
Tài liệu Quy trình Quản lý Đặc điểm kỹ thuật (SMPD) - PDF gốc

Bạn có thắc mắc về Hướng dẫn sử dụng không? Hãy đăng ở phần bình luận!

Tài liệu tham khảo

Hướng dẫn sử dụng