Tiêu chuẩn TCVN 13910-1:2024 về yêu cầu đối với định nghĩa dữ liệu ITS

• Số hiệu: TCVN13910-1:2024
• Loại văn bản: Tiêu chuẩn Việt Nam
• Nơi ban hành: ***
• Người ký: ***
• Ngày ban hành: Năm 2024

TIÊU CHUẨN QUỐC GIA

TCVN 13910-1:2024
ISO 14817-1: 2015

HỆ THỐNG GIAO THÔNG THÔNG MINH - TỪ ĐIỂN DỮ LIỆU TRUNG TÂM ITS - PHẦN 1: YÊU CẦU ĐỐI VỚI ĐỊNH NGHĨA DỮ LIỆU ITS

Intelligent transport systems - ITS central data dictionaries - Part 1: Requirements for ITS data definitions

Mục lục

1. Phạm vi áp dụng

2. Sự phù hợp

3 Tài liệu viện dẫn

4 Thuật ngữ và định nghĩa

...

...

...

6 Khái niệm dữ liệu

6.1 Tóm tắt khái niệm dữ liệu

6.2 Khái niệm dữ liệu tài liệu

6.2.1 Tài liệu từ điển

6.2.2 Mô đun

6.3 Khái niệm dữ liệu mô hình dữ liệu

6.3.1 Lớp đối tượng

6.3.2 Phần tử dữ liệu

6.3.3 Miền giá trị

...

...

...

6.4.1 Hội thoại giao diện

6.4.2 Thông điệp

6.4.3 Khung dữ liệu

6.4.4 Miền tổng hợp

7 Siêu thuộc tính

7.1 Nhận dạng và đặt tên cho các siêu thuộc tính

7.1.1 Định danh khái niệm dữ liệu

7.1.2 Phiên bản khái niệm dữ liệu

7.1.3 Sửa đổi khái niệm dữ liệu

...

...

...

7.1.5 Định danh tài liệu

7.1.6 Tên theo ngữ cảnh

7.1.7 Tên mô tả

7.1.8 Tên mô tả lịch sử

7.1.9 Tên ASN.1

7.1.10 Tên ASN.1 lịch sử

7.1.11 Định danh đối tượng

7.1.12 Bộ định vị tài nguyên thống nhất

7.2 Siêu thuộc tính định nghĩa

...

...

...

7.2.2 Nguồn

7.2.3 Kiểu khái niệm dữ liệu

7.2.4 Nhận xét

7.2.5 Ngữ cảnh

7.2.6 Quy tắc thứ tự hội thoại

7.3 Siêu thuộc tính quan hệ

7.3.1 Lớp đối tượng cha

7.3.2 Lớp phía trên

7.3.3 Phần tử kế tiếp

...

...

...

7.3.5 Tóm tắt

7.3.6 Tính đa dạng

7.3.7 Siêu lớp

7.3.8 Tin nhắn được tham chiểu

7.3.9 Khung dữ liệu tham chiếu

7.3.10 Phần tử dữ liệu được tham chiếu

7.4 Siêu thuộc tính đại diện

7.4.1 Kiểu dữ liệu

7.4.2 Định dạng

...

...

...

7.4.4 Quy tắc giá trị hợp lệ

7.4.5 Ràng buộc

Phụ lục A (Quy định) Yêu cầu siêu thuộc tính

A.1 Khái quát

A.2 Tổng quan

A. 3 Yêu cầu siêu thuộc tính

Phụ lục B (Quy định) Quy ước đặt tên

B. 1 Tên ngữ cảnh

B.1.1 Tổng quan

...

...

...

B.1.3 Định dạng tên theo ngữ cảnh của mô-đun

B.1.4 Định dạng tên theo ngữ cảnh cho các bản tin và thông điệp giao diện

B.1.5 Định dạng tên theo ngữ cảnh cho các lớp đối tượng và các miền tổng hợp

B.1.6 Định dạng tên theo ngữ cảnh cho các phần tử dữ liệu và khung dữ liệu

B.1.7.2 Thuật ngữ lớp đại diện

B.2 Tên mô tả

B.2.1 Tên mô tả - Quy tắc chung

B.2.2 Tên mô tả cho một mô-đun

B.2.3 Tên mô tả cho các cuộc hội thoại và tin nhắn

...

...

...

B.2.5 Định dạng tên mô tả đủ điều kiện

B.3 Tên ASN1

B.3.1 Tổng quan

B.3.2 Sử dụng cú pháp ASN.1

B.3.3 Tên ASN.1 của tài liệu từ điển

B.3.4 Tên ASN.1 của mô-đun, lớp đối tượng và miền tổng hợp

B.3.5 Tên ASN.1 của phần tử dữ liệu và khung dữ liệu

B.3.6 ASN.1 tên miền giá trị

B.3.7 ASN.1 tên của thông điệp và hội thoại

...

...

...

C.1 Tổng quát

C.2 Các lớp đối tượng

C.3 Mô-đun

C.4 Khung dữ liệu

C.5 Tên miền tổng hợp

C.6 Phần tử dữ liệu

C.7 Miền giá trị

C. 8 Mô đun ASN.1

C.8.1 Mô đun, phiên bản 1.0

...

...

...

c.8.3 Mô đun phương tiện giao thông, phiên bản 1.0

Phụ lục D (tham khảo) Mô hình dữ liệu

D. 1 Yêu cầu chung

D.2 Ví dụ về mô hình hóa dữ liệu

D.3 Ví dụ về trao đổi thông tin

D. 4 Hướng dẫn về mô hình hóa dữ liệu

D.4.1 Dữ liệu ITS được sử dụng trong các thay đổi phải được biểu diễn trong một mô hình dữ liệu

D.4.2 Biểu đồ lớp UML nên được sử dụng để mô tả các mô hình dữ liệu

D.4.3 Chỉ sử dụng tập hợp con của UML được xác định trong phụ lục này khi phát triển các sơ đồ UML

...

...

...

D.4.5 Tất cả các phần tử dữ liệu thành phần và khung dữ liệu của lớp đối tượng phải được xác định trong sơ đồ lớp UML

D.4.6 Miền giá trị có thể được hiển thị

D.4.7 Các bảng phải được định nghĩa là một cặp lớp đối tượng liên kết

D. 4.8 Các hướng dẫn khác về phát triển dữ liệu (độc lập với mô hình)

Phụ lục E (tham khảo) Dữ liệu đang tồn tại

E. 1 Yêu cầu chung

E.2 Dữ liệu kế thừa mẫu

E. 2.1 Va chạm

E.2.2 Va chạm

...

...

...

E.2.4 Mức độ nghiêm trọng

E.2.5 Phương tiện

E.3 Phân tích dữ liệu kế thừa mẫu

E.4 Ví dụ về dữ liệu sửa đổi

E.4.1 Tài liệu Từ điển

E.4.2 Các lớp đối tượng

E.4.3 Mô-đun

E.4.4 Hội thoại giao diện

E.4.5 Bản tin

...

...

...

E.4.9 Miền giá trị

Thư mục tài liệu tham khảo

Lời nói đầu

TCVN 13910-1: 2024 hoàn toàn tương đương ISO 14817-1: 2015.

TCVN 13910-1: 2024 do Cục Đường bộ Việt Nam biên soạn, Bộ Giao thông Vận tải đề nghị, Tổng cục Tiêu chuẩn Đo lường Chất lượng thẩm định, Bộ Khoa học và Công nghệ công bố.

Bộ Tiêu chuẩn TCVN 13910, Hệ thống giao thông thông minh - Từ điển dữ liệu trung tâm ITS gồm 3 phần:

- TCVN 13910-1: 2024, Hệ thống giao thông thông minh - Từ điển dữ liệu trung tâm ITS - Phần 1: Yêu cầu đối với định nghĩa dữ liệu ITS

- TCVN 13910-2: 2024. Hệ thống giao thông thông minh - Từ điển dữ liệu trung tâm ITS - Phần 2: Quản lý đăng ký khái niệm dữ liệu ITS trung tâm

...

...

...

HỆ THỐNG GIAO THÔNG THÔNG MINH - TỪ ĐIỂN DỮ LIỆU TRUNG TÂM ITS - PHẦN 1: YÊU CẦU ĐỐI VỚI ĐỊNH NGHĨA DỮ LIỆU ITS

Intelligent transport systems - ITS central data dictionaries - Part 1: Requirements for ITS data definitions

1. Phạm vi áp dụng

Tiêu chuẩn này quy định cấu trúc lôgic (khung) và nội dung (vật chất) dữ liệu của từ điển dữ liệu (DD) hệ thống giao thông thông minh (ITS).

Cụ thể, tiêu chuẩn này quy định những nội dung sau:

- Khung được sử dụng để xác định và định nghĩa tất cả các khái niệm dữ liệu;

- Thuộc tính siêu dữ liệu được sử dụng để mô tả, chuẩn hóa và quản lý từng khái niệm dữ liệu được xác định trong khung này;

- Các yêu cầu được sử dụng để ghi lại các định nghĩa này;

...

...

...

- Một tập hợp các khái niệm dữ liệu được ưu tiên trong miền ITS;

- Phương pháp mô hình hóa dữ liệu để xác định các khái niệm dữ liệu ITS, khi được sử dụng.

DDs hỗ trợ các khái niệm dữ liệu xuất phát từ bất kỳ số lượng phương pháp và / hoặc kỹ thuật kiến trúc hệ thống quốc tế, khu vực hoặc quốc gia nào. Các định dạng dữ liệu phổ biến và các quy trình vận hành sẽ dễ dàng di chuyển và khả năng tương tác giữa các phương pháp tiếp cận như vậy.

Sổ đăng ký khái niệm dữ liệu là một từ điển dữ liệu điện tử hỗ trợ một số tính năng bổ sung. CIDCR đề cập đến việc triển khai cụ thể của cơ quan đăng ký khái niệm dữ liệu ITS được vận hành dưới sự bảo trợ của ISO / TC 204 (Ban kỹ thuật quốc tế về hệ thống giao thông thông minh). Thuật ngữ “cơ quan đăng ký khái niệm dữ liệu” có thể đề cập đến CIDCR và / hoặc bất kỳ cơ quan đăng ký khái niệm dữ liệu quốc gia hoặc khu vực nào khác được lựa chọn để phù hợp tiêu chuẩn này.

2. Sự phù hợp

Tiêu chuẩn này mô tả một mô hình khái niệm, nhưng không mô tả việc triển khai thực tế. Việc triển khai tiêu chuẩn này có thể sử dụng các khái niệm dữ liệu khác nhau, các siêu thuộc tính khác nhau hoặc các khái niệm dữ liệu khác nhau và các siêu thuộc tính khác nhau; tuy nhiên, việc triển khai tuân thủ tiêu chuẩn này sẽ cung cấp ánh xạ rõ ràng đến và từ mô hình triển khai thực tế và siêu mô hình khái niệm được xác định tiêu chuẩn này.

DDs khu vực và quốc gia có tùy chọn áp dụng các định nghĩa khái niệm dữ liệu từ CIDCR, nhưng không bắt buộc.

Bảng 1 chỉ ra các yêu cầu tuân thủ của sổ đăng ký khái niệm dữ liệu và từ điển dữ liệu

Bảng 1 - Từ điển dữ liệu vả sự tuân thủ đăng ký khái niệm dữ liệu

...

...

...

Từ điển dữ liệu

Đăng ký khái niệm dữ liệu ^b

Hỗ trợ tất cả các khái niệm dữ liệu^c

√

√

Hỗ trợ tất cả các siêu thuộc tính nhận dạng bắt buộc^d

√

√

Hỗ trợ tất cả các siêu thuộc tính về định nghĩa bắt buộc^e

...

...

...

√

Hỗ trợ tất cả các siêu thuộc tính quan hệ bắt buộc^f

√

√

Hỗ trợ tất cả các siêu thuộc tính đại diện bắt buộc^g

√

√

Hỗ trợ tất cả các siêu thuộc tính quản trị bắt buộc^h

...

...

...

Lưu trữ điện tử với các quy tắc quản trị tự động^i

√

a Phụ lục A xác định các siêu thuộc tính nào là bắt buộc đối với các khái niệm dữ liệu cụ thể.

b Đối với sổ đăng ký khái niệm dữ liệu, các siêu thuộc tính “bắt buộc” cũng sẽ bao gồm tất cả các siêu thuộc tính “được chỉ định”.

c Theo định nghĩa tại Khoản 6.

d Theo định nghĩa trong 7.1.

e Theo định nghĩa trong 7.2

f Như định nghĩa trong 7.3

...

...

...

h Như định nghĩa trong TCVN 13910-2:2024

i Theo định nghĩa trong TCVN 13910-2:2024

3  Tài liệu viện dẫn

Các tài liệu viện dẫn sau, toàn bộ hoặc một phần, rất cần thiết cho việc áp dụng tiêu chuẩn này. Đối với các tài liệu viện dẫn ghi năm công bố thì áp dụng phiên bản được nêu. Đối với các tài liệu viện dẫn không ghi năm công bố thì áp dụng phiên bản mới nhất, bao gồm cả các sửa đổi, bổ sung (nếu có).

- TCVN 13910-3: 2024, Hệ thống giao thông thông minh - Từ điển dữ liệu trung tâm ITS - Phần 3: Phép gán mã định danh đối tượng cho các khái niệm dữ liệu ITS (ISO 14817-3, Intelligent transport systems - ITS central data dictionaries - Part 3: Object Identifier assignments for ITS data concepts)

- TCVN 10583-1: 2014 (ISO/IEC 9834-1: 2012) Công nghệ thông tin - Thủ tục điều hành của cơ quan đăng ký định danh đối tượng - Phần 1: Thủ tục chung và các cung trên cùng của cây định danh đối tượng quốc tế

- NIMA TR8350.2, Phiên bản thứ bạ - Sửa đổi 1, Tháng 1 năm 2000, Bộ Quốc phòng - Hệ thống trắc địa thế giới 1984, Định nghĩa và mối quan hệ của nó với các hệ thống trắc địa địa phương, do Cơ quan Bản đồ và Hình ảnh Quốc gia (NIMA), Bộ Quốc phòng Hoa Kỳ phát hành

4  Thuật ngữ và định nghĩa

Tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa nêu trong TCVN 13910-3:2023 (ISO 14817-3) và các thuật ngữ, định nghĩa dưới đây:

...

...

...

Khái niệm tóm tắt (abstract)

Chỉ báo về việc lớp đối tượng là hoàn toàn tóm tắt hay có thể được khởi tạo bằng các đối tượng thành viên; các lớp đối tượng tóm tắt thường có các chuyên môn hỏa không trừu tượng.

4.2

Miền tổng hợp (aggregate domain)

Khái niệm dữ liệu xác định một nhóm các phần tử dữ liệu và / hoặc khung dữ liệu

4.3

Tên ASN1 (ASN.1 name)

Tên của một khái niệm dữ liệu được biểu thị dưới dạng “kiểu tham chiếu” hợp lệ theo định nghĩa của ISO/IEC 8824-1

4.4

...

...

...

Mối quan hệ ngữ nghĩa giữa hai lớp đối tượng

4.5

Ràng buộc (constraint)

Ký hiệu có thể được sử dụng cùng với một kiểu, để xác định kiểu con của kiểu đó

4.6

Ngữ cảnh (context)

Tất cả những gì được đề cập đến trong đó tên hoặc khái niệm được sử dụng

4.7

Tên ngữ cảnh (contextual name)

...

...

...

4.8

Dữ liệu (data)

Trình bày lại thông tin có thể giải thích được theo cách thức chính thức hóa phù hợp cho giao tiếp, diễn giải hoặc xử lý

CHÚ THÍCH 1: Dữ liệu có thể được xử lý bằng con người hoặc phương tiện tự động.

4.9

Khái niệm dữ liệu (data concept)

Mục có thể được lưu trữ trong từ điển dữ liệu đề cập đến một sự vật hoặc sự vật trừu tượng trong thể giới tự nhiên có thể được xác định với các ranh giới và ý nghĩa rõ ràng và các thuộc tính và hành vi của chúng đều tuân theo các quy tắc giống nhau. Lưu ý 1 về mục nhập: Các khái niệm dữ liệu có thể được phân loại thành các loại sau: lớp đối tượng, miền giá trị, phần tử dữ liệu, miền tổng hợp, khung dữ liệu, thông điệp, hội thoại giao diện, tài liệu từ điển hoặc mô-đun

4.10

Định danh khái niệm dữ liệu (data concept identifier)

...

...

...

4.11

Thể hiện khái niệm dữ liệu (data concept instance)

Sự xuất hiện của một khái niệm dữ liệu

4.12

Sổ đăng ký khái niệm dữ liệu (data concept registry)

Từ điển dữ liệu điện tử tuân theo các quy tắc được lập thành văn bản chính xác để đăng ký và quản lý các khái niệm dữ liệu được lưu trữ; nó thường cũng bao gồm các tính năng nâng cao đề thêm, truy xuất và làm việc với nội dung của nó

CHÚ THÍCH 1: Sổ đăng ký khái niệm dữ liệu chứa các siêu thuộc tính về các khái niệm dữ liệu dưới dạng tên và dạng biểu diễn của chúng cũng như ngữ nghĩa được liên kết với các khái niệm dữ liệu, sổ đăng ký khái niệm dữ liệu có thể chứa dữ liệu hỗ trợ trao đổi và sử dụng lại thông tin, cả từ quan điểm của người dùng con người và để máy móc giải thích các khái niệm dữ liệu.

4.13

Sửa đổi khái niệm dữ liệu (data concept revision)

...

...

...

4.14

Kiểu khái niệm dữ liệu (data concept type)

Phân loại các loại khái niệm dữ liệu

4.15

Phiên bản khái niệm dữ liệu (data concept version)

Sổ nguyên đại diện cho số lượng các thay đổi đã được thực hiện đối với các phiên bản đã được phê duyệt của khái niệm dữ liệu liên quan

4.16

Từ điển dữ liệu (data dictionary)

Liệt kê các khái niệm dữ liệu và các siêu thuộc tính của chúng ở một định dạng nhất quán

...

...

...

Phần tử dữ liệu (data element)

Khái niệm dữ liệu được đại diện bởi một miền giá trị cụ thể và mô tả một thuộc tính nguyên tử đơn lẻ về một lớp đối tượng

CHÚ THÍCH 1: Phần tử dữ liệu bao gồm một lớp đối tượng, một thuộc tính của lớp đối tượng được đại diện và một miền giá trị,

4.18

Khung dữ liệu (data frame)

Khái niệm dữ liệu được đại diện bởi một miền tổng hợp cụ thể và mô tả thông tin quan tâm thông qua một nhóm hữu ích gồm nhiều thuộc tính nguyên tử hơn về một hoặc nhiều lớp đối tượng

CHÚ THÍCH 1: Nhóm có thể là một tập hợp, trình tự hoặc lựa chọn

4.19

Mô hình dữ liệu (data model)

...

...

...

VÍ DỤ Một mô hình dữ liệu có thể chỉ định rằng “Xe” có thể được mô tả bằng nhiều thuộc tính, chẳng hạn như: “sản xuất”, “kiểu”, “năm” và “vin" (số nhận dạng xe). Tương tự như vậy, "Va chạm" có thể được mô tả bằng các thuộc tính như "thời gian xảy ra", "mức độ nghiêm trọng" và "Số lượng xe liên quan". Cuối cùng, mô hình có thể mô tả rằng một Vụ va chạm có mối quan hệ từ nhiều đến nhiều đối với một Phương tiện. Sau đây cung cấp một đồ họa mâu của mô hình dữ liệu này.

CHÚ THÍCH 1: Trong phạm vi của Tiêu chuẩn này, các mô hình dữ liệu được mô tả bằng cách sử dụng Sơ đồ lớp UML.

Hình 1 - Mô hình dữ liệu mẫu

4.20

Kiểu dữ liệu (data type)

tập hợp các giá trị riêng biệt, được đặc trưng bởi các thuộc tính của các giá trị đó và bằng các phép toán trên các giá trị đó

4.21

Định nghĩa (definition)

...

...

...

4.22

Tên mô tả (descriptive name)

từ mô tả hoặc nhóm từ gắn nhãn duy nhất cho một khái niệm dữ liệu trong một mô-đun

4.23

Hội thoại (dialogue)

Xem hội thoại giao diện

4.24

Quy tắc trình tự hội thoại (dialogue order rules)

Các quy tắc điều chỉnh trình tự các thông điệp được gửi giữa các hệ thống để đạt được một dịch vụ cụ thể

...

...

...

Tài liệu từ điển (dictionary document)

Khái niệm dữ liệu đại diện cho một từ điển dữ liệu cùng với thông tin bổ sung có thể được tiêu chuẩn hóa

4.26

Định danh tài liệu (document identifier)

Mã định danh nhận dạng duy nhất tài liệu

4.27

Định dạng (format)

Mô tả ngôn ngữ tự nhiên về bố cục hợp lý của khái niệm dữ liệu liên quan đến việc trao đổi dữ liệu

4.28

...

...

...

mối quan hệ phân loại giữa hơn một phần tử khái quát và hơn một phần tử cụ thể trong đó phần tử cụ thể hoàn toàn phù hợp với phần tử khái quát và chứa thông tin bổ sung

CHÚ THÍCH 1: Lớp tổng quát hơn được gọi là lớp cha.

CHÚ THÍCH 2: Lớp cụ thể hơn được gọi là lớp con.

CHÚ THÍCH 3: “Hoàn toàn nhất quán" có nghĩa là lớp con có tất cả các thuộc tính (4.47) và các mối quan hệ của lớp cha.

4.29

Tên ASN.1 lịch sử (historic ASN.1 name)

Tên ASN.1 được gán cho một khái niệm dữ liệu không tuân theo quy ước đặt tên hiện tại

4.30

Tên mô tả lịch sử (historic descriptive name)

...

...

...

4.31

Định danh (identifier)

Chuỗi các ký tự, có khả năng nhận dạng duy nhất mà nó được liên kết, trong một ngữ cảnh cụ thể

4.32

Hội thoại giao diện (interface dialogue)

Khái niệm dữ liệu xác định trình tự giao tiếp hai chiều giữa hai bên phù hợp với các giao thức xác định trước

4.33

Cây nhận dạng đối tượng quốc tế (international object identifier tree)

Cây có gốc tương ứng với ISO / IEC 9834-1 và có các nút tương ứng với Cơ quan đăng ký chịu trách nhiệm phân bổ cung từ nút cha

...

...

...

Thuật ngữ lower camel case (lower camel case term)

Một cụm từ bao gồm một hoặc nhiều từ đc ghép lại với nhau, các từ nằm trong cụm này khi đc ghép lại phải viết hoa chữ cái đầu của từ gốc đó chữ cái khác là chữ thường; các từ nối tiếp nhau không có khoảng trống; có thể sử dụng dấu gạch ngang và số, ký tự đầu tiên của cụm từ phải là ký tự chữ cái viết thường; dấu gạch ngang có thể không phải là ký tự cuối cùng hoặc xuất hiện nhiều lần theo trình tự

4.35

Thông điệp (message)

Khái niệm dữ liệu là một nhóm các phần tử dữ liệu, khung dữ liệu hoặc các phần tử dữ liệu và khung dữ liệu được sử dụng để truyền tải một tập hợp thông tin hoàn chỉnh

CHÚ THÍCH 1: Đối với mục đích của Tiêu chuẩn này, thông điệp là một mõ tả trừu tượng: nó không phải là một trường hợp cụ thể

4.36

Thể hiện thông điệp (message instance)

Sự xuất hiện của một thông điệp chứa các giá trị thực tế cho các phần tử dữ liệu và / hoặc khung dữ liệu

...

...

...

Siêu (meta-)

Tiền tố tiếng Hy Lạp biểu thị mô tả là một cấp độ trừu tượng cao hơn khái niệm được mô tả

4.38

Siêu thuộc tính (meta-attribute)

Tài liệu đặc trưng của một khái niệm dữ liệu được lưu trữ trong một DD

4.39

Siêu dữ liệu (metadata)

Tài liệu đặc trưng của một khái niệm dữ liệu được cung cấp trong một thông điệp

CHÚ THÍCH 1: Các đặc điểm của tài liệu được gọi là "thuộc tính siêu" khi được lưu trữ trong DD, nhưng được gọi là siêu dữ liệu khi được cung cấp trong cùng một thể hiện thông điệp với giá trị thực. Ví dụ, một phần tử dữ liệu có thể được xác định trong DD với một đơn vị đo lường cụ thể, chẳng hạn như mét; trường Đơn vị đo là một siêu thuộc tính được xác định. Ngoài ra, đơn vị đo lường có thể được xác định trong thời gian chạy trong một tin nhắn, đặc biệt là đối với các mục như đơn vị tiền tệ. Thể hiện thông điệp xác định đơn vị tiền tệ cho một giá trị được bao gồm sẽ được gọi là "siêu dữ liệu"

...

...

...

Mô đun (module)

Khái niệm dữ liệu có chứa định nghĩa cú pháp chính thức, và tùy chọn định nghĩa ngữ nghĩa, của một tập hợp xác định các khái niệm dữ liệu khác mà tất cả đều được phiên bản kiểm soát như một đơn vị duy nhất; một mô-đun có thể được biểu diễn bằng nhiều ngôn ngữ (ví dụ: ASN.1 hoặc Lược đồ XML) và được biên dịch bởi các hệ thống máy tính

4.41

Đa dạng (multiplicity)

Số lượng phiên bản của khái niệm dữ liệu chủ đề có thể được liên kết với lớp đối tượng mà nó mô tả

4.42

Tên (name)

Thuật ngữ chỉ mục được con người sử dụng làm phương tiện xác định các phần tử dữ liệu và các khái niệm dữ liệu khác

4.43

...

...

...

Lớp đối tượng đại diện cho một nhóm hợp lý các phần tử dữ liệu và khung dữ liệu mô tả một số khía cạnh của lớp đối tượng lớn hơn mà lớp đối tượng lồng nhau được chứa

CHÚ THÍCH 1: Các lớp đối tượng lồng nhau được sử dụng để mô tả các lớp đối tượng được chứa trong một lớp đối tượng khác và được sử dụng cho các đối tượng khái niệm hơn là các đối tượng hữu hình.

VÍ DỤ: Một lớp đối tượng ký hiệu thông điệp có thể có một lớp đối tượng lồng nhau cho các thông điệp được lưu trữ trong thư viện của nó, trong đó mỗi thông điệp được mô tả bởi một số thuộc tính, chẳng hạn như số thông điệp, nội dung thông điệp, chủ sở hữu thông điệp, v.v.

4.44

Phiên bản danh định (nominal version)

mã định danh đại diện cho một số phiên bản mà khái niệm dữ liệu thường được biết đến nhiều hơn

4.45

Lớp đối tượng (object class)

mô tả về một tập hợp các đối tượng có cùng thuộc tính, mối quan hệ và ngữ nghĩa

...

...

...

4.46

Định danh đối tượng (object identifier)

Danh sách có thứ tự các giá trị số nguyên chính từ gốc của cây nhận dạng đối tượng quốc tế đến một nút, nó xác định rõ ràng nút đó

4.47

Lớp đối tượng cha (parent object class)

Lớp đối tượng mà khái niệm dữ liệu mô tả

4.48

Lớp phía trên (precursor)

Khái niệm dữ liệu lịch sử, tương tự về mặt ngữ nghĩa trong cùng một DD, khái niệm dữ liệu này đã thay thế hoặc đang thay thế

...

...

...

Đặc tính (property)

Đặc điểm phổ biến với tất cả các thành phần của một lớp đối tượng

CHÚ THÍCH 1: Đây được định nghĩa là một khái niệm dữ liệu riêng biệt trong TCVN 7789 (ISO / IEC 11179-1), nhưng được đưa vào định nghĩa của phần tử dữ liệu trong Tiêu chuẩn này để đơn giản hóa thiết kế DD.

4.50

Phần tử dữ liệu được tham chiếu (referenced data element)

Phần tử dữ liệu được tham chiếu bởi khái niệm dữ liệu hiện tại

4.51

Khung dữ liệu được tham chiếu (referenced data frame)

Khung dữ liệu được tham chiếu bởi khái niệm dữ liệu hiện tại

...

...

...

Bản tin tham chiếu (referenced message)

Bản tin được sử dụng trong hội thoại giao diện hiện tại

4.53

Nhận xét (remarks)

nhận xét hoặc thông tin khác liên quan đến khái niệm dữ liệu

4.54

Ngữ nghĩa (semantics)

Nhánh của khoa học ngôn ngữ liên quan đến ý nghĩa của từ

4.55

...

...

...

Tài liệu hoặc tài liệu tham khảo khác được sử dụng để phát triển khái niệm dữ liệu thích hợp

4.56

Phần từ kế tiếp (successor)

Khái niệm dữ liệu mới hơn, tương tự về mặt ngữ nghĩa trong cùng một DD, đã thay thế hoặc đang thay thế khái niệm dữ liệu này

4.57

Lớp chồng (superclass)

lớp đối tượng là sự tổng quát hóa của lớp đối tượng hiện tại

4.58

Đồng nghĩa (synonym)

...

...

...

4.59

Cú pháp (syntax)

Tập hợp các quy tắc xác định cách dữ liệu được đặt cùng với các số nhận dạng thích hợp, dấu phân cách, (các) ký tự phân tách và các ký tự không phải dữ liệu khác để tạo thông điệp

4.60

Định vị tài nguyên thống nhất (uniform resource locator)

Chuỗi để xác định tài nguyên trên Internet (chẳng hạn như các trang Web) bằng cách chỉ định địa chỉ của tài nguyên và giao thức truy cập được sử dụng

4.61

Đơn vị đo lường (unit of measure)

đơn vị thực tế trong đó các giá trị liên quan được đo lường

...

...

...

Thuật ngữ upper camel case (upper camel case term)

Một cụm từ bao gồm một hoặc nhiều từ đc ghép lại với nhau, các từ nằm trong cụm này khi đc ghép lại phải viết hoa chữ cái đầu của từ gốc đó chữ cái khác là chữ thường; các từ nối tiếp nhau không có khoảng trống; có thể sử dụng dấu gạch ngang và số, ký tự đầu tiên củạ cụm từ phải là ký tự chữ cái viết hoa; dấu gạch ngang có thể không phải là ký tự cuối cùng hoặc xuất hiện nhiều lần theo trình tự

4.63

Miền giá trị (value domain)

Khái niệm dữ liệu xác định một tập hợp các giá trị cho phép

4.64

Quy tắc giá trị hợp lệ (valid value rule)

Định nghĩa văn bản ngôn ngữ tự nhiên của (các) quy tắc mà theo đó các trường hợp pháp lý được phép của phần tử dữ liệu hoặc miền giá trị được xác định

5  Ký hiệu và thuật ngữ viết tắt

...

...

...

ASN.1

Abstract Syntax Notation One

Ký hiệu cú pháp trừu tượng một

ANSI

American National Standards Institute

Viện tiêu chuẩn quốc gia Hoa Kỳ

CASE

Computer-Aided Software Engineering

Kỹ thuật phần mềm có sự hỗ trợ của máy tính

...

...

...

Central ITS Data Concept Registry

Hệ thống đăng ký khái niệm dữ liệu ITS trung tâm

DCI

Data concept identifier

Định danh khái niệm dữ liệu

DD

Data dictionary

Từ điển dữ liệu

NOTE

...

...

...

Theo định nghĩa, sổ đăng ký khái niệm dữ liệu là một loại chuyên biệt của từ điển dữ liệu; do đó, ký hiệu DD cũng áp dụng cho các đăng ký khái niệm dữ liệu

IEC

International Electrotechnical Commission

Ủy ban kỹ thuật điện quốc tế

ISO

International Organization for Standardization

Tổ chức Quốc tế về Tiêu chuẩn hoá

ITS

Intelligent transport system(s)

...

...

...

N/A

not applicable

Không áp dụng

OID

object identifier

Định danh đối tượng

OSI

Open System Interconnection

Mô hình tham chiếu kết nối hệ thống mở

...

...

...

Technical Committee

Ủy ban kỹ thuật

UBL

Universal Business Language

Ngôn ngữ kinh doanh toàn cầu

UML

Unified Modelling Language

Ngôn ngữ mô hình hóa thống nhất

URL

...

...

...

Định vị tài nguyên thống nhất

6  Khái niệm dữ liệu

6.1  Tóm tắt khái niệm dữ liệu

Mục này giải thích chín khái niệm dữ liệu (4.9) áp dụng trong tiêu chuẩn này, như được liệt kê trong điều 7.2.3. Khái niệm dữ liệu đề cập đến những thứ trừu tượng và những thứ trong thế giới tự nhiên có thể được xác định với ranh giới và ý nghĩa rõ ràng. Các thuộc tính và hành vi của các khái niệm dữ liệu này đều tuân theo cùng một bộ quy tắc. Trong ITS, có thể có các khái niệm dữ liệu để đại diện, ví dụ, một tuyển xe buýt và thông tin liên quan về nó.

Ở mức thấp nhất, miền giá trị (4.64) là một khái niệm dữ liệu xác định cú pháp được phép có thể được sử dụng để thể hiện một phần thông tin. Miền giá trị cung cấp thông tin ngữ nghĩa tối thiểu khác với những gì bộ giá trị được sử dụng. C.1 định nghĩa một số miền giá trị, ví dụ: “văn bản” là miền giá trị đại diện cho một chuỗi văn bản có thể phát âm được của con người được biểu diễn bằng Chuỗi ASN.1 UTF8.

Mục đích chính của miền giá trị là cung cấp các dạng biểu diễn tiêu chuẩn cho các phần tử dữ liệu. Phần tử dữ liệu (4.17) mô tả thuộc tính nguyên tử đơn (4.50) của một lớp đối tượng (4.46). Ví dụ, một chiếc xe (lớp đối tượng) có thể có một màu (thuộc tính) có thể được biểu thị bằng danh sách mã màu (miền giá trị). Lớp đối tượng “phương tiện” mô tả khái niệm cốt lõi đang được mô tả, thuộc tính “màu sắc” xác định những gì đang được mô tả về lớp đối tượng và miền giá trị “mã màu” cung cấp một dạng biểu diễn. Ba khái niệm kết hợp được gọi là một phần tử dữ liệu

Một số khái niệm phức tạp và được biểu diễn bằng nhiều phần tử dữ liệu liên quan. Ví dụ, một vị trí hai chiều thường được mô tả bằng vĩ độ và kinh độ. Hai điều này được nhóm lại với nhau thành một cấu trúc được gọi là miền tổng hợp (4.2) được gọi là GeoLocation.2D, như được định nghĩa trong c.4.9. Tương tự như miền giá trị, miền tổng hợp là một đại diện chung có thể được sử dụng trong nhiều ngữ cảnh; nó cung cấp một hình thức biểu diễn, nhưng cung cấp rất ít về mặt ngữ nghĩa (tức là vị trí của cái gì). Mỗi điều trong miền tổng hợp phải được xác định là phần tử dữ liệu hoặc khung dữ liệu của riêng nó. Ví dụ: trường vĩ độ trong cấu trúc GeoLocation.2D được xác định là thuộc tính "vĩ độ" của lớp đối tượng "Vị trí địa lý" với miền giá trị là MeasureType

Khung dữ liệu (4.18) là một phần tử dữ liệu phức tạp; nói cách khác, trong khi phần tử dữ liệu là phần tử theo định nghĩa và được biểu diễn bằng miền giá trị, thì khung dữ liệu phức tạp và được biểu diễn bằng miền tổng hợp. Ví dụ: một phương tiện (lớp đối tượng) có thể có một vị trí (thuộc tính) được đại diện bởi miền tổng hợp GeoLocation.2D. Ba khái niệm kết hợp tạo thành khung dữ liệu

Thông điệp (4.36) là một tập hợp các phần tử dữ liệu và / hoặc khung dữ liệu truyền tải một ý nghĩ hoàn chỉnh. Hội thoại giao diện (4.33) xác định (các) trình tự cho phép của các thông điệp có thể được trao đổi giữa các thực thể.

...

...

...

Tài liệu từ điển (4.25) là bất kỳ tài liệu nào được phê duyệt bởi một số cơ quan có thẩm quyền xác định chi tiết giao diện dữ liệu. Tài liệu từ điển thường là một tiêu chuẩn chính thức được chấp thuận bởi một tổ chức phát triển tiêu chuẩn như ISO, nhưng một tổ chức chính phủ hoặc công ty tư nhân cũng có thể phát triển các tài liệu từ điển để ghi lại các thiết kế tùy chỉnh của họ.

Hình 2 Mô tả tổng quan về cách thức chín khái niệm dữ liệu liên quan với nhau và có thể được lập thành văn bản

 Chỉ ra tham chiếu đến một khái niệm riêng biệt

Hình 2 - Lập hồ sơ các khái niệm dữ liệu

Tài liệu từ điển nên định nghĩa chính thức các lớp đối tượng được mô tả trong tài liệu. Sự phát triển của các lớp đối tượng buộc người phát triển tài liệu từ điển phải xem xét cấu trúc chính xác của dữ liệu mà họ đang xác định. Điều này rất quan trọng để khi các khái niệm dữ liệu được ghi lại trong CIDCR, chúng xác định đầy đủ ngữ cảnh của riêng mình một cách rõ ràng và rõ ràng.

Một tài liệu từ điển thường sẽ xác định một số mô-đun. Các mô-đun có thể được phân loại thành một trong ba loại.

Mỗi hội thoại giao diện nên được xác định trong mô-đun riêng của nó để cải thiện khả năng kiểm soát phiên bản. Nếu phiên bản tương lai của tài liệu từ điển chỉ cần sửa đổi một hộp thoại giao diện duy nhất, thì các thay đổi có thể được thực hiện mà không ảnh hưởng đến khả năng tương thích ngược của bất kỳ hộp thoại giao diện nào khác. Mỗi hội thoại giao diện sẽ tham chiếu đến nhiều thông điệp có thể xảy ra.

Tương tự như vậy, mỗi thông điệp nên được xác định trong mô-đun riêng của nó để thúc đẩy kiểm soát phiên bản thích hợp vì những lý do tương tự. Mỗi thông điệp sẽ tham chiếu đến một số kết hợp của các phần tử dữ liệu và khung dữ liệu

...

...

...

- mô-đun ISO-14817-1-Domains-1 như được định nghĩa trong C.6

- một mô-đun miền giá trị tùy chỉnh, nếu cần;

- một mô-đun phần tử dữ liệu cho mỗi lớp đối tượng có trong tài liệu từ điển

- một tập hợp tối thiểu các mô-đun cho mỗi lớp đối tượng xác định các miền và khung dữ liệu tổng hợp

- Cẩn thận trọng khi xác định mô-đun cho các miền và khung dữ liệu tổng hợp để không tạo ra các tham chiếu vòng giữa các mô-đun. Ngoài ra, các nhà phát triển cũng nên xem xét việc phân chia các mô-đun nếu nhận thấy lợi ích về khả năng tái sử dụng của các tài liệu từ điển khác.

Định nghĩa của một phần tử dữ liệu bao gồm một tham chiếu đến cả lớp đối tượng mẹ và miền giá trị. Định nghĩa của khung dữ liệu bao gồm tham chiếu đến cả lớp đối tượng mẹ và miền tổng hợp

- Khái niệm dữ liệu tài liệu bao gồm tài liệu từ điển và mô-đun.

- Các khái niệm dữ liệu của mô hình dữ liệu bao gồm lớp đối tượng, miền giá trị và phần tử dữ liệu.

- Các khái niệm dữ liệu giao diện bao gồm hội thoại giao diện, thông điệp, khung dữ liệu và miền tổng hợp. Môi nhóm khái niệm dữ liệu này được mô tả trong các mệnh đề sau.

...

...

...

Tiêu chuẩn này khuyến khích việc sử dụng Ngôn ngữ tạo mô hình thống nhất (UML) để ghi lại các mối quan hệ giữa các dữ liệu. Tuy nhiên, UML cũng có thể được sử dụng để ghi lại một siêu mô hình, tức là một mô hình dữ liệu chỉ định một hoặc nhiều mô hình dữ liệu khác. Nói cách khác, một siêu mô hình ở mức độ trừu tượng cao hơn. Thay vì xác định mối quan hệ dữ liệu giữa các khái niệm dữ liệu ITS (ví dụ: “Xe” “Va chạm", v.v.), nó được sử dụng để xác định mối quan hệ giữa các loại khái niệm dữ liệu được xác định trong Tiêu chuẩn này (tức là “lớp đối tượng", “phần tử dữ liệu Tài liệu từ điển ”, v.v.). Trong Tiêu chuẩn này, siêu mô hình luôn được chỉ định bằng cách gắn nhãn cho mỗi lớp UML với khuôn mẫu “siêu lớp”.

Hình 3 mô tả siêu mô hình xác định mối quan hệ giữa các khái niệm dữ liệu tài liệu.

Các khái niệm dữ liệu tài liệu bao gồm các khái niệm dữ liệu cấp cao nhất mà chúng tôi đã mô tả trong Hình 2.

Hình 3 - Khung khái niệm dữ liệu tài liệu

Mỗi ô trong sơ đồ tương ứng với một khái niệm dữ liệu được định nghĩa trong Tiêu chuẩn này. Các đường giữa các khái niệm dữ liệu biểu thị các liên kết. Dấu hoa thị (*) bên cạnh cuối mỗi dòng cho biết rằng có thể có bội số của khái niệm dữ liệu. Do đó, sơ đồ chỉ ra rằng một tài liệu từ điển có thể chứa nhiều mô-đun. Nó cũng chỉ ra rằng một mô-đun nhất định có thể được chứa trong nhiều tài liệu từ điển.

6.2.1 Tài liệu từ điển

Khái niệm dữ liệu tài liệu từ điển có thể đại diện cho một tiêu chuẩn hoặc bất kỳ thông số kỹ thuật chính thức nào khác định nghĩa hoặc tham chiếu đến các khái niệm dữ liệu khác. Nỏ phải bao gồm không hoặc nhiều mô-đun và các lớp đối tượng được phê duyệt như một đơn vị duy nhất để đáp ứng một tập hợp các yêu cầu cụ thể. Tài liệu thực tế cũng có thể chứa văn bản và / hoặc thông tin bổ sung không được ghi lại trong biểu diễn khái niệm dữ liệu.

CHÚ THÍCH: Khái niệm dữ liệu “tài liệu từ điển” được thiết kế để cho phép quản lý và kiểm soát phiên bản thích hợp của các khái niệm dữ liệu được sử dụng bởi nhiều tài liệu. Nó không thay thế các tài liệu thực tế; nó chỉ đại diện cho họ trong một DD.

...

...

...

6.2.2  Mô đun

Một mô-đun phải là một nhóm các khái niệm dữ liệu mô hình dữ liệu và giao diện được phiên bản điều khiển như một đơn vị và có thể được biểu diễn trong một tệp máy tính có thể đọc được đê trao đổi các khái niệm dữ liệu này. Một mô-đun nhất định có thể xuất hiện trong nhiều tài liệu từ điển. Mỗi lần sử dụng như vậy phải được ghi lại trong siêu thuộc tính "ngữ cảnh" của mô-đun. Để quản lý tốt nhất việc kiểm soát phiên bản, một mô-đun phải chứa một hộp thoại giao diện duy nhất, một thông điệp duy nhất hoặc một số kết hợp của các khái niệm dữ liệu khác

6.3  Khái niệm dữ liệu mô hình dữ liệu

Khái niệm dữ liệu mô hình dữ liệu là các khái niệm dữ liệu xuất hiện trong một mô hình dữ liệu. Hình 4 mô tả các khái niệm dữ liệu mô hình dữ liệu khác nhau được sử dụng trong Tiêu chuẩn này và các mối quan hệ của chúng

Hình 4 - Khung khái niệm dữ liệu mô hình dữ liệu

CHÚ THÍCH: TCVN 7789-3 (ISO 11179-3) xác định một số khái niệm dữ liệu khác, chẳng hạn như “thuộc tính”, “khái niệm phần từ dữ liệu”, “miền khái niệm”, v.v. các khái niệm dữ liệu này trong các tài liệu từ điển ITS. Thay vào đó, Tiêu chuẩn này đơn giản hóa số lượng các khái niệm dữ liệu đang được định nghĩa.

Một lớp đối tượng có thể được chứa trong nhiều tài liệu từ điển và mỗi tài liệu từ điển có thể chứa nhiều lớp đối tượng. Phần tử dữ liệu và miền giá trị được chứa trong không hoặc nhiều mô-đun (không được hiển thị trong Hình 4 cho ngắn gọn) và mỗi mô-đun có thể chứa nhiều phần tử dữ liệu và miền giá trị (không được hiển thị trong Hình 4 cho ngắn gọn.)

Một lớp đối tượng cũng có thể được mô tả bằng 0 hoặc các thuộc tính phức tạp hơn, được biểu diễn như các lớp đối tượng khác. Nói cách khác, một lớp đối tượng (ví dụ: “Va chạm”) có thể có một liên kết với một lớp đối tượng khác (ví dụ: “Xe”) để mô tả một số thuộc tính của lớp đối tượng đầu tiên (ví dụ: “RelatedVehicles”); “RelatedVehicles” phải được biểu diễn dưới dạng một lớp đối tượng vì nó có tập hợp các phần tử dữ liệu riêng (ví dụ: “make”, “model”, “yin”, v.v.) mô tả từng phương tiện liên quan.

...

...

...

Một mô hình dữ liệu mẫu được trình bày trong Hình 5. Mẫu này chỉ ra rằng lớp đối tượng Va chạm có một thuộc tính phức tạp của các báo cáo được biểu thị bằng không hoặc nhiều lớp đối tượng Va chạm. Mỗi lớp đối tượng Va chạm được mô tả bằng ba thuộc tính đơn giản (tức là phần từ dữ liệu): Thời gian xảy ra (được biểu thị dưới dạng ngày-giờ), mức độ nghiêm trọng (được biểu thị dưới dạng mã) và

Xelnvolved (được biểu thị dưới dạng số lượng). Mỗi lớp đối tượng Collision cũng được mô tả bởi một thuộc tính phức tạp được gọi là RelatedVehicles, được đại diện bởi không hoặc nhiều lớp đối tượng Xe. Mỗi lớp đối tượng Xe được mô tả bằng năm thuộc tính đơn giản: make (được biểu thị dưới dạng tên), kiểu máy (được biểu thị dưới dạng tên), vin (được biểu thị dưới dạng mã định danh), năm (được biểu thị dưới dạng mã định danh) và licensePlate (được biểu thị dưới dạng mã định danh )

6.3.1  Lớp đối tượng

Một lớp đối tượng sẽ mô tả một tập hợp các cá thể đối tượng có cùng thuộc tính, mối quan hệ và ngữ nghĩa trong một miền diễn ngôn nhất định mà cần phải đại diện cho một số thông tin.

Các bổ ngữ đủ điều kiện hoặc chuyên môn hóa hơn nữa lớp đối tượng có thể được sử dụng.

Trong Hình 5, các lớp đối tượng được minh họa là “Va chạm”, “Va chạm” và “Phương tiện”.

6.3.2  Phần tử dữ liệu

Một phần tử dữ liệu sẽ là một đại diện chính thức của một số thông tin (tức là một thuộc tính) về một lớp đối tượng, với một miền giá trị rõ ràng. Hình 5 mô tả tám phần tử dữ liệu:

...

...

...

- “Collision.severity: code”;

- “Collision.vehicleslnvolved: số lượng”;

- “phương tiện.make: tên”;

- “Kiểu phương tiện: tên”;

- “Xe.vimidentifier”;

- “phương tiện.year: số nhận dạng";

- “Vehicle.licencePlate: mã định danh”.

Phần tử dữ liệu có thể tinh chỉnh thêm miền giá trị được tham chiếu.

6.3.3  Miền giá trị

...

...

...

6.4  Khái niệm dữ liệu giao diện

Hình 6 trình bày các khái niệm dữ liệu giao diện và mối quan hệ của chúng.

Sự trao đổi thông tin giữa hai thành phần ITS cho một dịch vụ cụ thể sẽ được xác định bằng một cuộc hội thoại giao diện. Một cuộc hội thoại giao diện sẽ sử dụng một tập hợp một hoặc nhiều bản tin có thứ tự và thời gian truyền được xác định dựa trên một khái niệm hoặc kịch bản hoạt động đã xác định.

Một thông điệp phải chứa không hoặc nhiều phần tử dữ liệu và / hoặc khung dữ liệu. Một thông điệp có thể được sử dụng bởi không hoặc nhiều hộp thoại giao diện.

Một phần tử dữ liệu tương tự về mặt ngữ nghĩa với một khung dữ liệu; sự khác biệt duy nhất là phần tử dữ liệu là một phần dữ liệu không giống nhau trong khi khung dữ liệu là một tập hợp dữ liệu. Phần tử dữ liệu được đại diện bởi chính xác một miền giá trị trong khi khung dữ liệu được đại diện bởi chính xác một miền tổng hợp.

Hình 6 - Khung khái niệm dữ liệu giao diện

Miền tổng hợp phải chứa không hoặc nhiều phần tử dữ liệu và/hoặc khung dữ liệu.

Cả hai phần tử dữ liệu và khung dữ liệu có thể được chứa trong không hoặc nhiều thông điệp và / hoặc trong không hoặc nhiều miền tổng hợp.

...

...

...

Một giao diện có thể được trình bày trong một mô hình giao diện trông tương tự như một mô hình dữ liệu, nhưng một mô hình giao diện chỉ đại diện cho dữ liệu được chứa trong một trao đổi dữ liệu duy nhất trong khi một mô hình dữ liệu thường cung cấp một ngữ cảnh lớn hơn, chẳng hạn như chỉ ra tất cả thông tin có thể tồn tại trong một cơ sở dữ liệu. Do đó, một mô hình giao diện thường là một tập hợp con của thông tin chứa trong một mô hình dữ liệu tương ứng. Một mô hình dữ liệu ví dụ được cung cấp trong Hình 7. Các mô hình giao diện được chỉ ra bởi các khuôn mẫu được áp dụng cho các lớp UML.

Hình 7 chỉ ra CollisionReportDialogue bao gồm chính xác một yêu cầu CollisionReportRequest và chính xác một phản hồi Va chạm. Phản hồi Va chạm chứa không hoặc nhiều khung dữ liệu báo cáo, được đại diện bởi miền tổng hợp CollisionReport (là dạng xem đơn giản của lớp đối tượng Collision được trình bày trong Hình 5). Mỗi miền tổng hợp CollisionReport bao gồm một phần tử dữ liệu thời gian xảy ra (được biểu thị dưới dạng miền giá trị ngày-giờ) và một phần tử dữ liệu mức độ nghiêm trọng (được đại diện bởi miền giá trị mã).

Mỗi miền tổng hợp CollisionReport cũng bao gồm danh sách không hoặc nhiều khung dữ liệu RelatedVehicle, được đại diện bởi miền tổng hợp VehicleDescription (là một dạng xem đơn giản của lớp đối tượng Xe được trình bày trong Hình 5). Mỗi miền tổng hợp của VehicleDescription bao gồm phần từ dữ liệu make (được đại diện bởi miền giá trị tên), phần tử dữ liệu mô hình (được đại diện bởi miền giá trị tên) và phần tử dữ liệu licensePlate (được đại diện bởi miền giá trị nhận dạng).

Hình 7 - Mô hình giao diện mẫu

6.4.1  Hội thoại giao diện

Hội thoại giao diện phải là một chuỗi thông điệp tạm thời, bao gồm các biến thể, trong số hai hoặc nhiều thành phần hệ thống được sử dụng để hoàn thành một dịch vụ / kết quả có thể quan sát được. Trong một mô hình giao diện, một hội thoại giao diện xuất hiện dưới dạng một lớp UML với khuôn mâu là "Hội thoại". Trong Hình 7, ví dụ hội thoại giao diện là “CollisionReportDialogue”.

6.4.2  Thông điệp

Thông điệp phải là một nhóm có cấu trúc gồm các phần từ dữ liệu và / hoặc khung dữ liệu. Trong một mô hình giao diện, một thông điệp sẽ xuất hiện dưới dạng một lớp UML với khuôn mẫu là “Thông điệp”. Trong Hình 7, có hai thông điệp: “CollisionReportRequest” và “Coll va chạm”.

...

...

...

Một khung dữ liệu có thể được sử dụng để bắt chước một liên kết giữa các lớp đối tượng trong mô hình dữ liệu (ví dụ: “RelatedVehicles” xuất hiện dưới dạng một liên kết trong Hình 5 và như một khung dữ liệu trong Hình 7) hoặc có thể được sử dụng để nhóm các phần tử dữ liệu theo cách hữu ích (ví dụ: kết hợp một số phần tử dữ liệu với nhau thành một gói có thể sử dụng lại). Ví dụ: “Message.header” có thể được định nghĩa đề bao gồm một số phần tử dữ liệu thường được sử dụng cùng nhau trong các thông điệp khác nhau. Trong một mô hình giao diện, khung dữ liệu sẽ xuất hiện dưới dạng tên vai trò liên kết UML kết nối với một miền tổng hợp. Trong Hình 7, có hai khung dữ liệu: “Collisions.report” và “CollisionReport.involvedVehicle”.

6.4.4  Miền tổng hợp

Miền tổng hợp sẽ là đại diện của một lớp đối tượng, nhưng thường chỉ đại diện cho một tập con của các thuộc tính được xác định cho lớp đối tượng. Nó xác định chính xác và rõ ràng dạng biểu diễn của khung dữ liệu. Trong khi một số miền tổng hợp chỉ có thể được sử dụng bởi một khung dữ liệu, những miền khác có thể được một số khung dữ liệu sử dụng. Ví dụ: miền tổng hợp Vị trí có thể được dùng bởi Vehicle.position, Vehicle.origin và Vehicle.destination. Trong một mô hình giao diện, miền tổng hợp sẽ xuất hiện dưới dạng một lớp UML với khuôn mẫu là “AggregateDomain”. Trong Hình 7, có hai miền tổng hợp: “CollisionReport” và “VehicleDescription”. Một miền tổng hợp có thể có cùng tên với lớp đối tượng mà nó đang mô tả, mặc dù nó thường hữu ích để phân biệt tập con thông tin được bao gồm trong một miền tổng hợp cụ thể.

7  Siêu thuộc tính

Mọi khái niệm dữ liệu sẽ được mô tả bằng một số siêu thuộc tính. Các siêu thuộc tính cụ thể áp dụng cho một khái niệm dữ liệu nhất định được trình bày trong Phụ lục A. Điều khoản này cung cấp định nghĩa đầy đủ về từng siêu thuộc tính được xác định bởi Tiêu chuẩn này.

7.1  Nhận dạng và đặt tên cho các siêu thuộc tính

Các siêu thuộc tính nhận dạng sẽ phân biệt một khái niệm dữ liệu này với một khái niệm dữ liệu khác. Các khái niệm dữ liệu có nhiều siêu thuộc tính nhận dạng để hỗ trợ việc phân biệt các khái niệm dữ liệu với nhau trong các ngữ cảnh khác nhau. Ví dụ: siêu thuộc tính “mã định danh khái niệm dữ liệu” có thể được sử dụng để xác định khái niệm dữ liệu trong cơ sở dữ liệu và siêu thuộc tỉnh “phiên bản khái niệm dữ liệu” có thể được sử dụng để phân biệt giữa nhiều phiên bản lịch sử của cùng một khái niệm dữ liệu như được lưu trữ bên trong kho dữ liệu. Tuy nhiên, các định danh số này không thân thiện với người dùng, và do đó, mỗi khái niệm dữ liệu cũng có một “tên mô tả” để hỗ trợ con người sử dụng. Các siêu thuộc tính nhận dạng khác được xác định cho các ngữ cảnh khác.

7.1.1  Định danh khái niệm dữ liệu

DD địa phương sẽ chỉ định số nhận dạng này, tốt nhất là theo cách tự động và sẽ không bao giờ thay đổi nó. Giá trị của siêu thuộc tỉnh này cho phép quản lý cơ sở dữ liệu thích hợp và cho phép theo dõi một khái niệm dữ liệu nhất định ngay cả khi đã có những thay đổi đối với Tên mô tả, số nhận dạng đối tượng, v.v.

...

...

...

7.1.2  Phiên bản khái niệm dữ liệu

Các phiên bản được thiết lập để ghi lại các thay đổi quy chuẩn, bao gồm bất kỳ thay đổi quy chuẩn nào về ngữ nghĩa và / hoặc thông tin đại diện về một khái niệm dữ liệu. Phiên bản sẽ bắt đầu với giá trị một (1) và tăng dần khi có bất kỳ thay đổi quy chuẩn nào đối với khái niệm dữ liệu nếu và chỉ khi, phiên bản hiện tại đã được phê duyệt. Bảng 2 xác định các siêu thuộc tính quy chuẩn của khái niệm dữ liệu và mối quan hệ của chúng với việc đánh số phiên bản.

Bảng 2 - Các siêu thuộc tính có thể dẫn đến thay đổi phiên bản

Điều

Siêu thuộc tính

Thay đổi phiên bản

7.1.11

Định danh đối tượng

Phải được cập nhật với mỗi thay đổi của phiên bản

...

...

...

Định nghĩa

Buộc thay đổi phiên bản, ngoại trừ các chỉnh sửa biên tập nghiêm ngặt^a

7.2.3

Kiểu khái niệm dữ liệu

Không bao giờ có thể thay đổi khi khái niệm dữ liệu đã được ghi lại

7.2.6

Quy tắc trình tự hội thoại

Buộc thay đổi phiên bản, ngoại trừ các chỉnh sửa biên tập nghiêm ngặt^a

7.3.1

...

...

...

Buộc thay đổi phiên bản^a

7.3.5

Trừu tượng

Buộc thay đổi phiên bản^a

7.3.6

Đa dạng

Buộc thay đổi phiên bản^a

7.3.7

Siêu lớp

...

...

...

7.4.1

Kiểu dữ liệu

Buộc thay đổi phiên bản^a

7.4.2

Định dạng

Buộc thay đổi phiên bản^a

7.4.3

Đơn vị đo lường

Buộc thay đổi phiên bản^a

...

...

...

Quy tắc giá trị hợp lệ

Buộc thay đổi phiên bản^a

7.4.5

Ràng buộc

Buộc thay đổi phiên bản^a

^a Chỉ khi phiên bản hiện tại đã được phê duyệt

CHÚ THÍCH: Xem ISO 14817-2 để biết các quy trình chi tiết như xử lý các phiên bản nháp chưa bao giờ được phê duyệt (tức là các nhánh loại bỏ của kiểm soát phiên bản)

7.1.3  Sửa đổi khái niệm dữ liệu

Các bản sửa đổi được thiết lập để theo dõi những thay đổi nhỏ, không bao gồm những thay đổi về ngữ nghĩa hoặc thông tin đại diện về một khái niệm dữ liệu. Việc sửa đổi phải bắt đầu với giá trị không (0) và sẽ tăng dần theo từng thay đổi đối với khái niệm dữ liệu mà không dẫn đến một phiên bản khái niệm dữ liệu mới. Bản sửa đổi sẽ đặt lại về không (0) khi tăng phiên bản khái niệm dữ liệu.

...

...

...

7.1.4  Phiên bản danh nghĩa

Con người thường gán số phiên bản của riêng họ cho các khái niệm dữ liệu. Ví dụ, phiên bản danh nghĩa của tiêu chuẩn quốc tế được xác định là năm nó được phê duyệt.

7.1.5  Định danh tài liệu

Thường được tạo thành từ viết tắt của cơ quan tiêu chuẩn hóa và số được gán bởi cơ quan đó. Ví dụ, định danh tài liệu cho Tiêu chuẩn này là ISO 14817-1

7.1.6  Tên theo ngữ cảnh

Tên theo ngữ cảnh là phần tên mô tả duy nhất cho khái niệm dữ liệu. Ví dụ, định nghĩa đầy đủ của một phần tử dữ liệu bao gồm một tham chiếu chính thức đến một lớp đối tượng xác định và một miền giá trị xác định. Tên ngữ cảnh của phần tử dữ liệu sẽ chỉ bao gồm thuật ngữ thuộc tính, vì nó sẽ kế thừa tên lớp đối tượng và tên miền giá trị từ các khái niệm dữ liệu được tham chiếu. Xem B.1 để biết thêm thông tin.

7.1.7  Tên mô tả

Tèn mô tả phải được xây dựng theo yêu cầu của B.2. Tên mô tả thể hiện ý nghĩa của khái niệm dữ liệu và hỗ trợ hiểu biết ngữ nghĩa. Chúng có thể được sử dụng để nhanh chóng định vị một khái niệm dữ liệu trong DD. Tên mô tả có thể được tạo tự động nếu DD hỗ trợ Tên theo ngữ cảnh.

7.1.8  Tên mô tả lịch sử

...

...

...

7.1.9  Tên ASN.1

Tên của một khái niệm dữ liệu được thể hiện bằng cú pháp ASN.1. Tên ASN.1 phải được xây dựng theo yêu cầu của B.3.

7.1.10  Tên ASN.1 lịch sử

Các khái niệm dữ liệu thường được phát triển và đưa vào sử dụng trước khi chúng hoàn toàn phù hợp với các quy ước đặt tên của Tiêu chuẩn này. Siêu thuộc tính này cho phép DD ghi lại Tên ASN.1 đã được xác định trước đó cho một khái niệm dữ liệu có thể được dựa trên trên một Tên lịch sử hoặc các quy ước đặt tên khác.

CHÚ THÍCH: Siêu thuộc tính này thay thế siêu thuộc tính "Tên tượng trưng” của phiên bản trước của Tiêu chuẩn này vì tèn ASN.1 là tên chương trình ứng dụng duy nhất mà DD cần quan tâm.

7.1.11  Định danh đối tượng

OID cho phép các chương trình ứng dụng xác định và tham chiếu một cách nhanh chóng và duy nhất các khái niệm dữ liệu trong trao đổi dữ liệu. Để tối đa hóa khả năng tương tác

a) OID không thay đổi đối với phiên bản đã được phê duyệt của khái niệm dữ liệu, và

b) OID thay đổi bất cứ khi nào phiên bản khái niệm dữ liệu thay đổi.

...

...

...

7.1.12  Bộ định vị tài nguyên thống nhất

URL cung cấp một cách dễ dàng để truy cập thông tin bổ sung về khái niệm dữ liệu qua Internet. URL của một mô-đun sẽ là không gian tên của mô-đun.

Đề xuất OID nên được xây dựng theo yêu cầu trong TCVN 13910-3:2024

7.2  Siêu thuộc tính định nghĩa

Các siêu thuộc tính định nghĩa sẽ mô tả các khía cạnh ngữ nghĩa của một khái niệm dữ liệu. Các siêu thuộc tính này có thể giải quyết trực tiếp các ý nghĩa ngữ nghĩa (ví dụ: Định nghĩa, Chú thích, Tóm tắt) hoặc gián tiếp cung cấp thông tin chi tiết về các khía cạnh ngữ nghĩa của khái niệm dữ liệu (ví dụ: Nguồn, Loại khái niệm dữ liệu).

7.2.1  Định nghĩa

Định nghĩa cung cấp ý nghĩa chính thức, chuẩn mực của khái niệm dữ liệu trong văn bản ngôn ngữ tự nhiên.

7.2.2 Nguồn

Nguồn là tham chiếu đến tài liệu gốc (ví dụ: sách trắng, kiến trúc hoặc tiêu chuẩn) xác định yêu cầu đối với khái niệm dữ liệu.

...

...

...

Kiểu khái niệm dữ liệu của khái niệm dữ liệu sẽ không được thay đổi sau khi tạo ban đầu. Các giá trị hợp lệ cho kiểu khái niệm dữ liệu là:

- Tài liệu từ điển;

- Mô-đun;

- Lớp đối tượng;

- Phần tử dữ liệu;

- Miền giá trị;

- Giao diện hội thoại;

- Thông điệp;

- Khung dữ liệu;

...

...

...

7.2.4  Nhận xét

Siêu thuộc tính này không bị giới hạn đối với nội dung nguyên bản của nó.

7.2.5 Ngữ cảnh

Ngữ cảnh của hầu hết các khái niệm dữ liệu sẽ là tên mô tả của mô-đun mà nó được chứa trong đó. Đối với mô-đun khái niệm dữ liệu và lớp đối tượng, ngữ cảnh sẽ là định danh tài liệu của tài liệu từ điển. Một tài liệu từ điển sẽ không có ngữ cảnh.

CHÚ THÍCH: Bằng cách cho phép nhiều mục nhập của siêu thuộc tính này cho một khái niệm dữ liệu duy nhất, DD sẽ có thể theo dõi việc sử dụng lại các khái niệm dữ liệu.

7.2.6  Quy tắc thứ tự hội thoại

Các quy tắc sắp xếp phải mô tả các chuỗi thông điệp được phép, bao gồm các điều kiện lỗi và có thể thảo luận về các vấn đề như tần suất truyền, logic ưu tiên, xác minh thông điệp, v.v.

7.3  Siêu thuộc tính quan hệ

Các siêu thuộc tính quan hệ sẽ ghi lại các mối quan hệ giữa hoặc giữa các khái niệm dữ liệu.

...

...

...

Điều này cho biết lớp đối tượng mà một phần tử dữ liệu hoặc khung dữ liệu mô tả.

7.3.2  Lớp phía trên

Khái niệm dữ liệu tương ứng nên tham chiếu khái niệm dữ liệu này như là khái niệm kế thừa của nó.

Khái niệm dữ liệu được tham chiếu phải được thể hiện bằng tên mô tả đủ điều kiện của nó khi được trình bày cho người dùng

7.3.3  Phần tử kế tiếp

Khái niệm dữ liệu tương ứng nên tham chiếu khái niệm dữ liệu này như là lớp phía trên của nó. Khái niệm dữ liệu được tham chiểu phải được thể hiện bằng tên mô tả đủ điều kiện của nó khi được trình bày cho người dùng.

7.3.4  Từ đồng nghĩa

Điều này có thể bao gồm bất kỳ khái niệm dữ liệu nào mà nhà phát triển tin rằng đủ tương tự để được quan tâm. Nó có thể có ngữ nghĩa hơi khác hoặc hình thức biểu diễn khác. Khái niệm dữ liệu được tham chiểu phải được thể hiện bằng tên mô tả đủ điều kiện của nó khi được trình bày cho người dùng.

7.3.5  Tóm tắt

...

...

...

7.3.6  Tính đa dạng

Đặc tả về số lượng trường hợp tối thiểu và tối đa có thể tồn tại của khái niệm dữ liệu này cho lớp đối tượng cha tương ứng. Giá trị có thể là một số duy nhất, cho biết giá trị nhỏ nhất bằng số lớn nhất; hoặc có thể là một phạm vi được biểu thị bằng một số hai dấu chấm và một số khác (ví dụ: “0..5”). Giá trị tối đa có thể được biểu thị bằng dấu hoa thị (“*”) thay vì một số để hiển thị phạm vi không bị giới hạn. Ví dụ: khi xác định phần tử dữ liệu mô tả màu xe, siêu thuộc tính này sẽ cho biết phương tiện có được phép liên kết với các màu 0, 1, 2, v.v. hay không. Trong trường hợp này, nhà thiết kế có thể quyết định răng tất cả các loại xe phải có ít nhất một màu hoặc nhiều nhất là 2 màu; trong trường hợp đó, giá trị của siêu thuộc tính này sẽ là “1..2”.

7.3.7 Siêu lớp

Siêu thuộc tính siêu lớp của một khái niệm dữ liệu phải tham chiếu đến siêu lớp, nếu có, của khái niệm dữ liệu cụ thể đang được mô tả. Lớp con (tức là khái niệm dữ liệu đang được mô tả) kế thừa tất cả các thuộc tính của siêu lớp.

7.3.8  Tin nhắn được tham chiếu

Cơ quan đăng ký khái niệm dữ liệu nên triển khai siêu thuộc tính này theo cách cho phép tham chiếu chéo từ thông điệp đến hộp thoại giao diện.

7.3.9  Khung dữ liệu tham chiếu

Cơ quan đăng ký khái niệm dữ liệu nên triển khai siêu thuộc tính này theo cách cho phép tham chiếu chéo từ khung dữ liệu sang khung dữ liệu hoặc thông điệp

7.3.9  Khung dữ liệu tham chiếu

...

...

...

7.3.10  Phần tử dữ liệu được tham chiếu

Cơ quan đăng ký khái niệm dữ liệu nên triển khai siêu thuộc tính này theo cách cho phép tham chiếu chéo từ phần tử dữ liệu đến khung dữ liệu hoặc thông điệp.

7.4  Siêu thuộc tính đại diện

Các siêu thuộc tính biểu diễn mô tả các yêu cầu đối với biểu diễn vật lý của các khái niệm dữ liệu. Các siêu thuộc tính này xác định cách các phần tử dữ liệu được trao đổi qua các giao diện hệ thống và không nhất thiết hạn chế cách dữ liệu được lưu trữ trong cơ sở dữ liệu hoặc xuất hiện trong giao diện người dùng.

7.4.1  Kiểu dữ liệu

Biểu diễn lôgic của khái niệm dữ liệu được thể hiện dưới dạng Loại ASN.1 hợp lệ, như được định nghĩa trong ISO / IEC 8824-1. Dạng chính xác của siêu thuộc tính này cho thông điệp, khung dữ liệu, miền tổng hợp, phần tử dữ liệu và miền giá trị được chỉ định trong các điều khoản phụ sau.

CHÚ THÍCH: Các siêu thuộc tính bổ sung để hỗ trợ các cú pháp khác (ví dụ: CORBA IDL, Cú pháp đồ họa EDIFACT, Lược đồ XML) có thể được thêm vào trong các bản sửa đổi trong tương lai và một số thuộc tính bắt buộc hiện có có thể trở thành tùy chọn.

7.4.1.1  Kiểu dữ liệu cho thông điệp

Siêu thuộc tính Kiểu dữ liệu của khái niệm dữ liệu Thông điệp thường sẽ là “SEQUENCE”, “SEQUENCE OF" hoặc “CHOICE”, nhưng bất kỳ Loại ASN.1 nào cũng được phép. Nếu Kiểu dữ liệu là “SEQUENCE”, nó sẽ tuân theo các quy tắc được xác định trong 7.4.1.1.1. Nếu Kiểu dữ liệu là "SEQUENCE OF", nó sẽ tuân theo các quy tắc được xác định trong 7.4.1.1.2. Nếu Kiểu dữ liệu là “LỰA CHỌN”, thì nó sẽ tuân theo các quy tắc được xác định trong 7.4.1.1.3.

...

...

...

Trường Loại của mỗi Loại Named trong Loại “SEQUENCE” ASN.1 sẽ tham chiếu đến siêu thuộc tính Tên ASN.1 của Phần tử dữ liệu hoặc Khung dữ liệu đã xác định. Nếu khái niệm dữ liệu được tham chiếu không được xác định trong cùng một mô-đun, nó sẽ được viết dưới dạng externalTypeReference, như được định nghĩa trong ISO / IEC 8824-1. Không có hạn chế nào được đặt trên trường định danh, ngoài những hạn chế được chỉ định bởi các quy tắc thông thường của ASN. 1.

Các nhà thiết kế nên xem xét cẩn thận việc kiểm soát phiên bản và khả năng tương thích ngược. Đặc biệt, Loại SEQUENCE thường phải bao gồm một điểm đánh dấu tiện ích mở rộng để cho phép mở rộng trong phiên bản mới hơn, trừ khi nhà thiết kế tự tin rằng sẽ không cần mở rộng.

VÍ DỤ Trong ví dụ sau, chế tạo xe và kiểu xe phải là ASN.1 Tên của các phần từ dữ liệu hoặc khung dữ liệu đã xác định trong mô-đun IS14817-1 -bc-1

7.4.1.1.2  Trình bày loại “trình tự”

Trường loại ASN.1 “SEQUENCE OF” sẽ tham chiếu đến siêu thuộc tính Tên ASN.1 của Phần từ dữ liệu hoặc Khung dữ liệu đã xác định. Nếu khái niệm dữ liệu được tham chiếu không được xác định trong cùng một mô-đun, nó sẽ được viết dưới dạng externalTypeReterence, như được định nghĩa trong ISO / IEC 8824-1.

VÍ DỤ Trong ví dụ sau, thông tin về xe phải là ASN.1 Tên của phần tử dữ liệu hoặc khung ngày đã xác định trong mô-đun IS14817-1-ac-1:

Loại dữ liệu SEQUENCE OF IS14817-1-ac-1.Vehicle-information 7.4.11.3 Trình bày loại “lựa chọn”

Trường Loại của mỗi Loại Named trong Loại “CHOICE” ASN.1 sẽ tham chiếu đến siêu thuộc tính Tên ASN.1 của Phần từ dữ liệu hoặc Khung dữ liệu đã xác định. Nếu khái niệm dữ liệu được tham chiếu không được xác định trong cùng một mô-đun, nó sẽ được viết dưới dạng extemalTypeReterence, như được định nghĩa trong ISO / IEC 8824-1. Không có hạn chế nào được đặt trên trường định danh, ngoài những hạn chế được chỉ định bởi các quy tắc thông thường của ASN. 1.

...

...

...

VÍ DỤ Trong ví dụ sau, Kiểu xe và Kiểu xe phải là ASN.1 Tên của các phần tử dữ liệu hoặc khung dữ liệu đã xác định trong mô-đun IS14817-1 -bc-1:

7.4.12  Kiểu dữ liệu cho khung dữ liệu

Siêu thuộc tính Kiểu dữ liệu của khái niệm dữ liệu Khung ngày sẽ là ASN.1 Tên của khái niệm dữ liệu Miền tổng hợp.

7.4.13  Kiểu dữ liệu cho các miền tổng hợp

Siêu thuộc tính Kiểu dữ liệu của khái niệm dữ liệu Tên miền tổng hợp sẽ là “SEQUENCE”, “SEQUENCE OF” hoặc “LỰA CHỌN”; nó sẽ không phải là bất kỳ loại nguyên thủy nào. Nếu Kiểu dữ liệu là “SEQUENCE”, nó sẽ tuân theo các quy tắc được xác định trong 7.4.111 Nếu Kiểu dữ liệu là "SEQUENCE OF", nó sẽ tuân theo các quy tắc được xác định trong 7.4.112. Nếu Kiểu dữ liệu là “LỰA CHỌN”, thì nó sẽ tuân theo các quy tắc được xác định trong 7.4.113.

7.4.14  Kiểu dữ liệu cho các phần tử dữ liệu

Siêu thuộc tính Kiểu dữ liệu của khái niệm dữ liệu Phần từ dữ liệu sẽ là Tên ASN. 1 của Miền giá trị.

7.4.15  Kiểu dữ liệu cho các miền giá trị

...

...

...

Một kiểu số nguyên có thể được sử dụng để đại diện cho kiểu số thập phân có dấu chấm cố định nếu thuộc tính siêu dữ liệu hoặc siêu dữ liệu Đơn vị đo trong Kiểu dữ liệu cho biết độ lệch của số thập phân.

UTF8String sẽ được sử dụng cho kiểu chuỗi ký tự trong trường hợp trao đổi thông tin quốc tế. BMPString và IA5String có thể được sử dụng trong DD theo khu vực hoặc quốc gia cụ thể.

Các miền giá trị được liệt kê nên sử dụng kiểu INTEGER với nameValues nếu bạn muốn liên kết chặt chẽ giá trị số với một ý nghĩa. Loại ENUMERATED không cung cấp loại liên kết giá trị cứng nhắc này.

Các nhà thiết kế nên xem xét cẩn thận việc kiểm soát phiên bản và khả năng tương thích ngược. Đặc biệt, các loại ENUMERATED thường phải bao gồm một điểm đánh dấu mở rộng để cho phép mở rộng trong phiên bản mới hơn, trừ khi nhà thiết kế tự tin rằng sẽ không cần đến phần mở rộng.

VÍ DỤ Trong ví dụ sau, miền giá trị được biểu diễn bằng một giá trị tích phân từ 0 đến 255, một phạm vi hữu ích vì nó có thể được mã hóa trong một byte trong một số lược đồ mã hóa.

Data Type   INTEGER (0. 255)

CHÚ THÍCH: “Người gửi” các định nghĩa ASN.1 phiên bản 1 được khuyến khích cung cấp các điểm đánh dấu mở rộng nếu thích hợp, Ví dụ: trong phần tử “loại xe ENUMERATED {không xác định, xe hơi, xe hàng hóa nặng, xe dịch vụ cống cộng, ...} chắc chắn phải bao gom dấu chấm lửng để biểu thị các bổ sung có thể có trong phiên bản 2.

7.4.2  Định dạng

Siêu thuộc tính định dạng sẽ không được hiểu để ghi đè các hạn chế trong các siêu thuộc tính quy tắc kiểu dữ liệu hoặc giá trị hợp lệ. Bố cục cụ thể phụ thuộc vào kiểu dữ liệu của miền giá trị.

...

...

...

Các đơn vị phải được xác định theo ISO 80000-1. Đối với các đơn vị liệt kê, chẳng hạn như thiết bị hoặc đơn vị của vấn đề, thước đo sẽ được xác định bằng cách sử dụng siêu thuộc tính này

7.4.4  Quy tắc giá trị hợp lệ

Trong mọi trường hợp, Quy tắc giá trị hợp lệ sẽ không cho phép các giá trị không phù hợp với siêu thuộc tính Loại dữ liệu. Mặc dù định dạng trao đổi dữ liệu trừu tượng chính xác được xác định bởi siêu thuộc tính Loại dữ liệu, quy tắc giá trị hợp lệ có thể được sử dụng để ràng buộc thêm các giá trị hợp lệ (ví dụ: do mối quan hệ với các khái niệm dữ liệu khác) hoặc để cung cấp định nghĩa văn bản ngôn ngữ tự nhiên của dữ liệu định dạng.

7.4.5  Ràng buộc

Ràng buộc phải là Phần tử kiểu con ASN.1 như được định nghĩa trong ISO / IEC 8824-1: -, Điều 47. Kiểu con sẽ được áp dụng cho Kiểu dữ liệu, nếu nó là kiểu ASN.1 nguyên thủy hoặc sẽ được áp dụng cho Loại thành phần “giá trị" nếu Loại dữ liệu phân giải thành loại “SEQUENCE". Mặc dù Phần tử loại phụ ASN.1 có thể được bao gồm trong siêu thuộc tính Loại dữ liệu, bạn nên đặt nó trong siêu thuộc tính Constraint đề cho phép tái sử dụng các khái niệm dữ liệu nhiều nhất có thể và để phù hợp với quy trình xác thực hai lần được phép bằng cách triển khai XML. Ví dụ: điều này cho phép một miền giá trị “mã” chung duy nhất được xác định và sử dụng cho tất cả các giá trị được liệt kê. Sau đó, một phần tử dữ liệu cụ thể có thể tham chiếu đến Miền giá trị “mã” trong khi xác định Ràng buộc thích hợp của riêng nó để sửa đổi Miền giá trị chung chung hơn. Với xác thực hai lần XML, lần chuyển đầu tiên sẽ đảm bảo rằng kiểu dữ liệu hợp lệ trong khi lần chuyển thứ hai sẽ đảm bảo rằng giá trị được mã hóa thực tế là hợp lệ.

Ràng buộc phải được xác định chặt chẽ khi thích hợp để giảm thiểu kích thước mã hóa của thông tin đồng thời đáp ứng nhu cầu trao đổi dữ liệu

Phụ lục A

(Quy định)

...

...

...

A.1  Khái quát

Phụ lục này chỉ ra cách áp dụng siêu thuộc tính cho mỗi khái niệm dữ liệu

A.2  Tổng quan

Định nghĩa của các siêu thuộc tính được tham chiếu trong Phụ lục này được tìm thấy trong Điều 7.

Trong các bảng có trong Phụ lục này, mỗi hàng biểu thị khả năng áp dụng của một siêu thuộc tính cụ thể cho từng khái niệm dữ liệu. Cột đầu tiên của mỗi hàng cung cấp tên của siêu thuộc tính, số mệnh đề, trong đó siêu thuộc tính được tham chiếu được xác định, được đưa ra trong cột thứ hai. 11 cột tiếp theo liệt kê khả năng áp dụng của siêu thuộc tính cho từng khái niệm dữ liệu. Cột cuối cùng dành cho bất kỳ ghi chú nào liên quan đến siêu thuộc tính và mối quan hệ của nó với các khái niệm dữ liệu.

Khả năng áp dụng của một siêu thuộc tính được xác định bởi một mã được định nghĩa như sau:

- “M” = bắt buộc. Các siêu thuộc tính bắt buộc là bắt buộc đối với khái niệm dữ liệu được tham chiếu, không có ngoại lệ.

- “O" = tùy chọn. Các siêu thuộc tính tùy chọn có thể được triển khai, nếu muốn.

- “I” = biểu thị. Các siêu thuộc tính chỉ định phụ thuộc vào điều kiện “nếu” độc lập với bất kỳ siêu thuộc tính nào khác. Nếu điều kiện “if đánh giá là 'true', thì meta-thuộc tính được mã hóa “I” là bắt buộc; nếu không, nó không được áp dụng.

...

...

...

- “N / A" = không áp dụng.

Cột ghi chú của mỗi bảng giải thích bản chất của từng siêu thuộc tính chỉ định và cung cấp thông tin giải thích khác.

LƯU Ý Chỉ cho phép các giá trị đơn lẻ đối với từng siêu thuộc tính trừ khi được xác định cụ thể là “Được phép cho phép bội số”.

A.3  Yêu cầu siêu thuộc tính

Bảng A.1 xác định khả năng áp dụng của từng siêu thuộc tính cho từng khái niệm dữ liệu được

Bảng A.1 Yêu cầu siêu thuộc tính

Khái niệm dữ liệu

...

...

...

Điều

Tài liệu từ điển

Mô đun

Lớp đối tượng

Phần tử dữ liệu

Miền giá trị

Hội thoại giao diện

Bản tin

Khung dữ liệu

...

...

...

Ghi chú

Định danh khái niệm dữ liệu

7.1.1

A

A

A

A

A

A

...

...

...

A

A

Cùng một mã định danh khái niệm dữ liệu có thể được sử dụng cho các phiên bản khác nhau của khái niệm dữ liệu.

Phiên bản khái niện dữ liệu

7.1.2

A

A

A

A

...

...

...

A

A

A

A

Cùng một phiên bản có thể được sử dụng cho các phiên bản khác nhau của một khái niệm dữ liệu.

Sửa đổi khái niệm dữ liệu

7.1.3

A

A

...

...

...

A

A

A

A

A

A

Phiên bản chuẩn

7.1.4

...

...

...

O

O

O

O

O

O

O

O

Thường chỉ được sử dụng cho khái niệm dữ liệu chuẩn

...

...

...

7.1.5

M

N/A

N/A

N/A

N/A

N/A

N/A

N/A

...

...

...

Tên ngữ cảnh

7.1.6

M

M

M

M

M

M

...

...

...

M

M

Phải tuân theo B.1. Từ điển dữ liệu có thể gián tiếp cung cấp siêu thuộc tính này bằng cách xác định tên mô tả và / hoặc tên ASN 1 phù hợp với Phụ lục B.

Tên mô tả

7.1.7

A

A

A

A

...

...

...

A

A

A

A

Tên mô tả lịch sử

7.1.8

O

O

...

...

...

O

O

O

O

O

O

Multiples allowed

Tên ASN.1

7.1.9

...

...

...

A

A

A

A

A

A

A

A

...

...

...

7.1.10

N/A

O

N/A

O

O

N/A

O

O

...

...

...

Multiples allowed

Định danh đối tượng^a

7.1.11

M

M

M

M

M

M

...

...

...

M

M

Phù hợp với ISO 14817-3

Định vị tài nguyên thống nhất

7.1.12

O

I

O

O

...

...

...

O

O

O

O

Bắt buộc đối với các mô-đun nếu chúng có thể được sử dụng trong XML

Định nghĩa^a

7.2.1

M

M

...

...

...

M

M

M

M

M

M

Nguồn

7.2.2

...

...

...

O

O

O

O

O

O

O

O

được phép nhận nhiều giá trị

...

...

...

7.2.3

M

M

M

M

M

M

M

M

...

...

...

Nhận xét

7.2.4

O

O

O

O

O

O

O

...

...

...

O

được phép nhận nhiều giá trị

Ngữ cảnh

7.2.5

N/A

M

M

M

M

...

...

...

M

M

M

Quy tắc trình tự hội thoại^a

7.2.6

N/A

N/A

N/A

N/A

...

...

...

M

N/A

N/A

N/A

lớp đối tượng cha^a

7.3.1

N/A

N/A

...

...

...

M

N/A

N/A

N/A

M

N/A

Lớp phía trên

7.3.2

...

...

...

O

O

O

O

O

O

O

O

được phép nhận nhiều giá trị

...

...

...

7.3.3

O

O

O

O

O

O

O

O

...

...

...

Đồng nghĩa

7.3.4

O

O

O

O

O

O

O

...

...

...

O

Tóm tắt^a

7.3.5

N/A

N/A

M

N/A

N/A

N/A

...

...

...

N/A

N/A

Tính đa dạng^a

7.3.6

N/A

N/A

N/A

M

N/A

...

...

...

N/A

M

N/A

Siêu lớp^a

7.3.7

N/A

N/A

I

...

...

...

N/A

N/A

N/A

N/A

N/A

Bắt Puộc, nếu lớp đối tượng là lớp con

Tin nhắn được tham chiếu

7.3.8

N/A

...

...

...

N/A

N/A

N/A

M

N/A

N/A

N/A

được phép nhận nhiều giá trị

Khung dữ liệu được tham chiếu

...

...

...

N/A

N/A

N/A

N/A

N/A

N/A

O

N/A

O

...

...

...

Phần tử dữ liệu được tham chiếu

7.3.10

N/A

N/A

N/A

N/A

N/A

N/A

O

...

...

...

O

được phép nhận nhiều giá trị

Kiểu dữ liệu^a

7.4.1

N/A

N/A

N/A

M

M

...

...

...

M

M

M

Định dạng^a

7.4.2

N/A

N/A

N/A

...

...

...

I

N/A

N/A

N/A

N/A

Bắt buộc, nếu có và chưa được xác định

Đơn vị đo lường

7.4.3

N/A

...

...

...

N/A

I

I

N/A

N/A

N/A

N/A

Quy tắc giá trị hợp lệ^a

7.4.4

...

...

...

N/A

N/A

I

I

N/A

N/A

I

I

Bắt buộc, nếu có vá chưa được xác định

...

...

...

7.4.5

N/A

N/A

N/A

I

N/A

N/A

N/A

I

...

...

...

^a Siêu thuộc tính chuẩn; bất kỳ thay đổi nào đối với giá trị của siêu thuộc tính này đối với khái niệm dữ liệu đã được phê duyệt sẽ dân đến một phiên bản mới.

Phụ lục B

(Quy định)

Quy ước đặt tên

B.1  Tên ngữ cảnh

Tên theo ngữ cảnh phải được xây dựng khi phát triển các khái niệm dữ liệu theo các yêu cầu được mô tả trong Điều khoản này. Các yêu cầu này sẽ áp dụng cho toàn bộ môi trường dử liệu ITS.

Tên theo ngữ cảnh sẽ thể hiện ý nghĩa của khái niệm dữ liệu trong một ngữ cảnh đã biết và đóng vai trò như một bản tóm tắt định nghĩa của khái niệm dữ liệu.

Tên theo ngữ cảnh phải là duy nhất trong ngữ cảnh của nó.

...

...

...

Bảng B.1 trình bày tóm tắt về các định dạng tên cụ thể; các quy tắc chính xác tương ứng với điều cụ thể.

Bảng B.1 - Định dạng tên ngữ cảnh cho các khái niệm dữ liệu ITS

khái niệm dữ liệu

Điều

Định dạng ví dụ

Tài liệu từ điển

B.1.2

Tên theo ngữ cảnh khái niệm dữ liệu

Mô đun

...

...

...

ORG-DictionaryDocument-Module

Lớp đối tượng

B.1.5

DataConceptContextualName

Phần tử dữ liệu

B.1.6

dataConceptContextualName

Miền giá trị

B.1.7

...

...

...

Giao diện hội thoại

B.1.4

DataConceptContextualName:dialogue

Bản tin

B.1.4

DataConceptContextualName:message

Khung dữ liệu

B.1.6

dataConceptContextualName

...

...

...

B.1.5

DataConceptContextualName

B.1.2  Định dạng tên ngữ cảnh của tài liệu từ điển

Tên theo ngữ cảnh của tài liệu từ điển phải là tên nguyên văn của tài liệu từ điền, bao gồm cả dấu cách và dấu câu, sử dụng các quy tắc viết hoa thông thường cho tài liệu.

VÍ DỤ: Hệ thống giao thông thông minh - Từ điển dữ liệu ITS - Phần 1: Yêu cầu đối với định nghĩa dữ liệu ITS

B.1.3  Định dạng tên theo ngữ cảnh của mô-đun

Tên ngữ cảnh của mô-đun phải bao gồm số nhân dạng tổ chức, số nhận dạng tài liệu và số nhận dạng mô-đun.

Số nhận dạng tổ chức phải có từ 3 đến 6 ký tự chữ hoa, chữ cái (A-Z) để xác định duy nhất tổ chức chịu trách nhiệm về mô-đun. Kể từ khi xuất bản Tiêu chuẩn này, các số nhận dạng tổ chức được công nhận bao gồm:

- CEN: Ủy ban tiêu chuẩn hóa châu Âu

...

...

...

Sau đó, tổ chức sẽ chỉ định một mã định danh tài liệu cho mỗi tài liệu từ điển và phải đảm bảo rằng mỗi mã định danh tài liệu là duy nhất trong tổ chức của mình. Định danh tài liệu có thể bao gồm các số bộ phận, có thể được phân tách bằng dấu gạch ngang.

Người soạn thảo tài liệu phải xác định mã định danh mô-đun cho từng mô-đun trong tài liệu từ điển. Số nhận dạng mô-đun phải là upper camel case term từ 1 đến 48 ký tự.

Ba thành phần của tên sau đó được kết hợp, phân tách bằng dấu gạch ngang.

EXAMPLE  ISO-14817-1-ValueDomains

B.1.4  Định dạng tên theo ngữ cảnh cho các bản tin và thông điệp giao diện

Tên ngữ cảnh cho các cuộc hội thoại và tin nhắn giao diện phải bao gồm một thuật ngữ chữ hoa lạc đà từ 1 đến 48 ký tự. Môi từ trong thuật ngữ phải là số ít, trừ khi một trường hợp duy nhất của khái niệm dữ liệu đại diện cho khái niệm số nhiều.

EXAMPLE   ContextualName

B.1.5  Định dạng tên theo ngữ cảnh cho các lớp đối tượng và các miền tổng hợp

Tên ngữ cảnh của các lớp đối tượng và các miền tổng hợp phải là một thuật ngữ viết hoa dạng lạc đà từ 1 đến 64 ký tự. Mỗi từ trong thuật ngữ phải là số ít, trừ khi một trường hợp duy nhất của khái niệm dữ liệu đại diện cho khái niệm số nhiều. Tên riêng, giới từ và liên từ không được khuyến khích. Việc sử dụng dấu gạch nối không được khuyến khích vì có thể có xung đột với các quy tắc chuyển đổi tên.

...

...

...

B.1.6  Định dạng tên theo ngữ cảnh cho các phần tử dữ liệu và khung dữ liệu

Tên ngữ cảnh của các phần tử dữ liệu và khung dữ liệu phải là một thuật ngữ viết hoa lạc đà từ 1 đến 64 ký tự. Thuật ngữ này sẽ chỉ ra thực tế, mệnh đề hoặc quan sát về lớp đối tượng được mô tả. Một đối tượng có thể có nhiều trường hợp của thuộc tính, trong trường hợp đó thuật ngữ sẽ ở dạng số nhiều của một danh từ; nếu không nó sẽ ở dạng danh từ số ít. Tên riêng, giới từ và liên từ không được khuyến khích. Nếu cần phân định thêm, có thể thêm dấu gạch ngang cùng với tên ngữ cảnh của miền giá trị hoặc miền tổng hợp được tham chiếu bởi siêu thuộc tính kiểu dữ liệu của khái niệm dữ liệu.

EXAMPLE contextualName

B.1.7  Định dạng tên theo ngữ cảnh của miền giá trị

B.1.7.1  Tổng quan

Tên theo ngữ cảnh của miền giá trị phải được xây dựng dưới dạng một chuỗi gồm một hoặc nhiều từ hoặc chữ viết tắt, được thiết kế để truyền tải nhanh chóng định dạng mà thông tin được trình bày. Mỗi từ hoặc từ viết tắt phải viết toàn chữ thường, có dấu gạch nối ngăn cách các từ. Tên ngữ cành phải bắt đầu bằng một trong các thuật ngữ biểu diễn được xác định trong B.1.7.2 để xác định bản chất chung của miền giá trị. Các từ còn lại sẽ đặc trưng duy nhất cho miền giá trị cụ thể. Độ dài tối đa của tên theo ngữ cảnh là 64 ký tự.

EXAMPLE  code-country (ví dụ: mã quốc gia gồm hai chữ cái)

B.1.7.2  Thuật ngữ lớp đại diện

Tên theo ngữ cảnh của miền giá trị sẽ bắt đầu bằng một trong các thuật ngữ hoặc chữ viết tắt của lớp biểu diễn như được liệt kê bên dưới. Một chữ viết tắt của lớp đại diện không nên viết tắt thèm, số tiền (amt): Định lượng bằng số của giá trị tiền tệ được biểu thị bằng đơn vị tiền tệ, chẳng hạn như đô la và xu. Một số ví dụ về miền giá trị rõ ràng cho thuật ngữ biểu diễn này là $$$$.cc, €€€€,cc và £$$£.pp, trong đó “$$$$”, “€€€€” và “££££’’ đại diện cho đô la, euro hoặc bảng Anh (hoặc mệnh giá tiền tệ chính khác) với bất kỳ số chữ số có nghĩa nào được yêu cầu và “cc” hoặc “pp” đại diện cho xu hoặc xu. Đối với các giá trị số phi tiền tệ, hãy sử dụng thuật ngữ miền giá trị “số lượng”.

...

...

...

Mã (cd): Một tập hợp các giá trị trong đó mỗi giá trị đại diện cho một ý nghĩa cụ thể

CHÚ THÍCH: Miền giá trị ví dụ: ANSI X3.38-1988, ISO 3166-1:2013, ISO 3166-2:2013, ISO 3166-3:2013 và ISO/IEC 5218:2004 đều thuộc “mã" lớp biểu diễn.

Ngày (dt): Một ngày dương lịch cụ thể

Ngày-giờ (dtm): Một thời điểm cụ thể trong toàn bộ lịch sử Thời lượng (dur): Một khoảng thời gian.

Định danh (id): Giá trị được sử dụng để nhận dạng duy nhất một đối tượng trong ngữ cảnh đã biết.

chỉ báo (ind): Danh sách hai giá trị loại trừ lẫn nhau thể hiện trạng thái duy nhất có thể có của một thực thể.

Hình ảnh (img): Một mục đồ họa hoặc hình ảnh, chẳng hạn như bản đồ, sơ đồ, hình ảnh, hình ảnh chuyển động hoặc biểu tượng.

Số do (ms): Một giá trị số có thể được đo bằng các đơn vị SI tiêu chuẩn và có thể chịu được các thao tác tính toán.

Tên (nm): Một chuỗi ký tự có thể phát âm được của con người được sử dụng để nhận dạng.

...

...

...

Phần trăm (pet): Tỷ lệ của hai đại lượng được biểu thị ở dạng sổ dưới dạng số thập phân nhân với 100.

Số lượng (qty): Một giá trị số có thể đếm được, phi tiền tệ (ví dụ: số lượng phương tiện) có thể phải chịu đến các thao tác tính toán.

Tỷ lệ (rt): Tỷ lệ số không có bất kỳ đơn vị nào biểu thị số lượng hoặc thước đo của mục này với mục khác với cùng đơn vị, ví dụ: 1:10.

Âm thanh (snd): Một chuỗi âm thanh có phần đầu và phần cuối rõ ràng. Một ví dụ về miền giá trị rõ ràng có thể áp dụng cho phần tử dữ liệu sử dụng thuật ngữ miền giá trị này phải được chỉ định trong siêu thuộc tính miền giá trị của nó, ví dụ: “wav.”

Văn bản (txt): Một chuỗi chữ và số (được định dạng hoặc không được định dạng), có thể bao gồm khoảng trắng; ví dụ. tên đường hoặc nội dung của tài liệu, tin nhắn hoặc tệp khác. Một ví dụ về miền giá trị rõ ràng cho “văn bản” là ISO/IEC 10646.

Thời gian (tm): Một khoảnh khắc thời gian xảy ra hàng ngày.

Video (vid): Một hình ảnh đồ họa video

B.2  Tên mô tả.

B.2.1  Tên mô tả - Quy tắc chung

...

...

...

Ngoại trừ mô-đun, hội thoại, thông điệp, phần tử dữ liệu và khung dữ liệu, tên mô tả của khái niệm dữ liệu phải giống với tên ngữ cảnh của nó.

Tên mô tả đủ tiêu chuẩn phải được xác định trong B.3.8.

B.2.2  Tên mô tả cho một mô-đun

Tên mô tả của mô-đun phải bao gồm tên theo ngữ cảnh, theo sau là dấu gạch ngang, theo sau là phiên bản khái niệm dữ liệu

EXAMPLE   ISO-14817-1-ValueDomains-1

B.2.3  Tên mô tả cho các cuộc hội thoại và tin nhắn

Tên mô tả của các hộp thoại và thông điệp giao diện phải bao gồm tên theo ngữ cảnh, theo sau là dấu hai chấm và theo sau là thuật ngữ mở rộng được xác định trong Bảng B.2.

Bảng B.3 - Điều khoản mở rộng

Khái niệm dữ liệu

...

...

...

giao diện hội thoại

Hội thoại

Bản tin

Bản tin

B.2.4  Tên mô tả cho các phần tử dữ liệu và khung dữ liệu

Tên mô tả của các phần tử dữ liệu và khung dữ liệu phải bao gồm ba phần. Phần đầu tiên sẽ là tên ngữ cảnh của lớp đối tượng được tham chiếu bởi siêu thuộc tính lớp đối tượng mẹ của phần tử dữ liệu. Phần thứ hai sẽ là Tên ngữ cảnh của phần tử dữ liệu hoặc khung dữ liệu. Phần thứ ba sẽ là tên mô tả của miền giá trị hoặc miền tổng hợp được tham chiếu bởi siêu thuộc tính kiểu dữ liệu của phần tử dữ liệu (hoặc của khung dữ liệu). Hai phần đầu tiên phải được phân tách bằng dấu chấm (“.”) Trong khi hai phần cuối cùng được phân tách bằng dấu hai chấm (“”:).

VÍ DỤ 1 Đối với phần tử dữ liệu: ObjectClassTerm.propertyTerm: value-domain-term

VÍ DỤ 2 Đối với khung dữ liệu: ObjectClassTerm.propertyTerm: AggregateDomainTerm

B.2.5  Định dạng tên mô tả đủ điều kiện

...

...

...

Bất cứ khi nào tham chiếu đến một khái niệm dữ liệu được định nghĩa chính thức trong một mô- đun khác, thì tham chiếu phải sử dụng tên mô tả đủ điều kiện. Tên mô tả đủ điều kiện của bất kỳ khái niệm dữ liệu nào được lấy bằng cách nối tên mô tả của thuộc tính ngữ cảnh của khái niệm dữ liệu với dấu hai chấm và tên mô tả của khái niệm dữ liệu.

VÍ DỤ ISO-14817-1-Location-1 :: GeoLocation.latitude: đo lường

B.3  Tên ASN1

B.3.1  Tổng quan

Quy ước phát triển tên mô tả cho các khái niệm dữ liệu được biểu diễn trong DD được đưa ra ở trên. Tuy nhiên, các quy ước được sử dụng để tạo tên mô tả xung đột với một số quy tắc của ASN.1, do đó, tên phải được thay đổi một chút khi được sử dụng trong ngữ cảnh ASN.1. Các tên mô tả có thể được chuyển đổi thành tên ASN.1 bằng cách sử dụng các quy tắc được mô tả trong điều khoản này. Tên tuân theo ASN.1 sẽ được biểu diễn trong từ điển dữ liệu ITS bằng cách sử dụng siêu thuộc tính được gọi là ASN.1 Name.

Cung cấp một cái nhìn tổng quan về các ràng buộc được đặt trên tên theo tiêu chuẩn ASN. 1. B.3.3 đến B.3.7 cung cấp các quy tắc chi tiết để chuyển đổi tên mô tả sang tên ASN.1. B.3.8 cung cấp các quy tắc để chuyển đổi Tên ASN.1 thành Tên ASN.1 đủ điều kiện.

B.3.2  Sử dụng cú pháp ASN. 1

Các quy tắc đặt tên ASN.1 như sau;

- Tập hợp các ký tự mà từ đó tên có thể được tạo trong ASN.1 là: A-Z, a-z, gạch nối và 0-9;

...

...

...

- số nhận dạng là tên phải bắt đầu bằng chữ cái thường;

- tên (nghĩa là một người đánh máy hoặc một số nhận dạng) không được chứa hai hoặc nhiều dấu gạch nối liền nhau, cũng như bắt đầu hoặc kết thúc bằng dấu gạch nối. Lưu ý rằng tên ASN.1 có phân biệt chữ hoa chữ thường;

- trong khi không có độ dài tối đa nào được đặt trên các tên bởi ASN.1; Tiêu chuẩn này giới hạn tên theo Phụ lục này

ví dụ như sau

Personlnfo, Person-name, Person-age, Person-homeĐịa chỉ, Tên, số lượng và Địa chỉ là những người đánh máy; tên, tuổi và địa chỉ là các định danh.

B.3.3  Tên ASN.1 của tài liệu từ điển

Tên ASN.1 của tài liệu từ điển phải giống với mã định danh tài liệu của nó với dấu cách bị xóa bỏ. B.3.4 Tên ASN. 1 của mô-đun, lớp đối tượng và miền tổng hợp

...

...

...

B.3.5  Tên ASN. 1 của phần tử dữ liệu và khung dữ liệu

Tên ASN.1 của các phần tử dữ liệu và khung dữ liệu phải bắt đầu bằng tên ngữ cảnh của lớp đối tượng được tham chiếu bởi meta-thuộc tính lớp đối tượng mẹ của khái niệm dữ liệu. Tiếp theo là dấu gạch ngang và ngay sau đó là tên ngữ cảnh của khái niệm dữ liệu.

EXAMPLE 1  GeoLocation-latitude

EXAMPLE 2  GeoLocation-latitude-measure

EXAMPLE 3  Vehicle-position

EXAMPLE 4  Vehicle-position-GeoLocation

B.3.6 ASN.1 tên miền giá trị

Tên ASN.1 của miền giá trị phải giống với tên ngữ cảnh của nó với chữ cái đầu tiên được viết hoa và ngay sau đó là từ “Loại”.

EXAMPLE  CodeType

...

...

...

Tên ASN.1 của thông điệp và hội thoại giao diện sẽ giống với tên ngữ cảnh của nó với phần mở rộng message” hoặc“: hội thoại” bị xóa.

EXAMPLE  CollisionRequestMessage

B.3.8  Định dạng tên hoàn toàn đủ điều kiện

Bởi vì có một số lượng lớn các nhóm độc lập có thể phát triển các khái niệm dữ liệu, sẽ là vấn đề khi yêu cầu các tên ASN.1 duy nhất trên toàn cầu cho mọi khái niệm dữ liệu. Thay vào đó, Tiêu chuẩn này chỉ yêu cầu tên là duy nhất trong phạm vi của mô-đun xác định.

Bất cứ khi nào tham chiếu đến một khái niệm dữ liệu được định nghĩa chính thức trong một mô- đun khác, tham chiếu phải sử dụng một tên đủ điều kiện. Tên mô tả đủ điều kiện của bất kỳ khái niệm dữ liệu nào có được bằng cách ghép tên ASN.1 của mô-đun với một dấu chấm và tên ASN.1 của khái niệm dữ liệu.

EXAMPLE  ISO-14817-1-Location-1.GeoLocation-latitude

Phụ lục C

(quy định)

...

...

...

C.1  Tổng quát

CHÚ THÍCH: Các khái niệm dữ liệu được ưu tiên xác định cú pháp và ngữ nghĩa được khuyến nghị sẽ được sử dụng khi thảo luận vẽ khái niệm này ở bất kỳ đầu trong miền ITS. Các khái niệm dữ liệu sử dụng cú pháp và ngữ nghĩa; các khái niệm dữ liệu ưu tiên được chi định như vậy để khuyến khích việc áp dụng chúng nếu khả thi. Các nhà phát triển tiêu chuẩn được coi là chuyên gia cuối cùng về các nhu cầu của tiêu chuẩn và vẫn được phép hoàn toàn linh hoạt của ASN.1 trong thiết kế của họ.

C.2  Các lớp đối tượng

Bảng C.1 xác định các lớp đối tượng được sử dụng trong ngữ cảnh của Tiêu chuẩn này

Bảng C.1 Các lớp đối tượng

Tên ngữ cảnh

OID^a

Định nghĩa

Nguồn

...

...

...

Siêu lớp

Tác nhân

{its 2}

thực thể cung cấp một số Dịch vụ

Sai

Amount

{its

...

...

...

định lượng bằng số của giá trị tiền tệ được chỉ định bằng một loại tiền tệ rõ ràng; đơn vị tiền tệ có thể được xác định trong định nghĩa khái niệm dữ liệu và / hoặc trong cách trình bày số tiền trong bảng mã

UBL 2.1

Sai

BinaryObject

{its

129}

tập hợp các chuỗi có độ dài hữu hạn của các bộ tám nhị phân

UBL2.1

...

...

...

CodeList

{its

130}

một loạt các đại diện viết tắt của các khái niệm cuối cùng

Sai

GeoLocation

...

...

...

134}

điểm trên hoặc gần bề mặt Trái đất

Sai

Vị trí

Location

{its

131}

định vị địa điểm hoặc vị trí

...

...

...

Sai

MeasureObject

{its

132}

giá trị sổ được xác định bằng cách đo một đối tượng cùng với đơn vị đo được chỉ định

Sai

...

...

...

{its

133}

chuỗi ký tự có thể phát âm, thường ở dạng các từ trong một ngôn ngữ

UBL 2.1

Sai

Phương tiện

{its 1}

Phương tiện vận chuyển hàng hóa và con người trên bộ

...

...

...

Dai

^a Để biết định nghĩa về các cung gốc của OID, xem ISO 14817-3.

C.3  Mô-đun

Bảng C.2 xác định các mô-đun được xác định trong ngữ cảnh của Tiêu chuẩn này.

Bảng C.2 - Mô dun

Tên ngữ cảnh

OID^a

Định nghĩa

...

...

...

mains-1

{value-do- mains-modules 1}

Mô-đun xác định hội thoại để trao đổi báo cáo va chạm.

^a Để biết định nghĩa về các cung gốc của OID, xem ISO 14817-3.

C.4  Khung dữ liệu

Bảng C.3 xác định các khung dữ liệu được xác định trong mô-đun ISO-14817-1-Vehicle-1.

Bảng C.3 - Khung dữ liệu

Tên ASN.1

OID^a

...

...

...

Đa dạng

Kiểu dữ liệu

Vehicle-

position3D

{vehicle

1}

Vị trí thực tế hiện tại của chiếc xe

1

ISO-14817-1-Location-1.

...

...

...

Vehicle.position2 D

{vehicle

2}

Vị trí thực tế hiện tại của chiếc xe

1

ISO-14817-1 -Location-1. GeoLocation2D

^a Để biết định nghĩa về các cung gốc của OID, xem ISO 14817-3.

C.5  Tên miền tổng hợp

Bảng C.4 xác định các miền tổng hợp được xác định trong mô-đun ISO-14817-1-Domains-1.

...

...

...

Bảng C.4 - Miền tổng hợp

Tên ASN.1

OIDa

Định nghĩa

Lớp đối tượng chính

Kiểu dữ liệu

CodeList

{codelist 0 1}

...

...

...

CodeList

Measure

{measure 0 1}

Một giá trị số có thể được đo bằng các đơn vị tiêu chuẩn. Đơn vị phải chỉ ra các đơn vị được sử dụng trong phép đo. Khi có sẵn, các đơn vị sẽ là một trong các mã được liệt kê tại http://www.schemacentral.com/sc/ubl20/a- unitCode-3.html

Measure

Text

{text 0 1}

...

...

...

Text

Bảng C.5 - Miền Tổng hợp Vị trí

ASN.1 Name

OID^a

Định nghĩa

Lớp đối tượng cha

Kiểu dữ liệu

GeoLocation3D

...

...

...

Vị trí địa lý ba chiều.

GeoLocation

GeoLocation2D

{geoLocation 0 2}

Vị trí địa lý hai chiều.

GeoLocation

...

...

...

Bảng C.6 xác định các phần tử dữ liệu được xác định trong mô-đun TCVN xxxx:202x- Domains-1.

Bảng C.6 - Phần tử dữ liệu

Tên mô tả

OID^a

Định nghĩa

Nguồn

Đa dạng

Kiểu dữ liệu

Agency.id:oid

...

...

...

Giá trị nhân dạng duy nhất trên toàn cầu cho tác nhân

0..1

OidType

Agency.name:name

{agency 2}

Tên mà tác nhân được biết đến.

0..*

...

...

...

Amount, currencylD:identifier

{amount 1}

Mã giới hạn ba chữ cái theo phiên bản hiên tai của ISO 4217.

UBL2.1

1

IdentifierType

Amount. value:amountb

{amount 2}

Số lượng tiền tệ.

...

...

...

1

AmountType

BinaryObject.mimeCode:identifier

{binaryObject 1}

Loại giao thức mine đã đăng ký mô tả mã hóa của giá trị nhị phân.

UBL2.1

1

IdentifierType

BinaryObject.format:identifier

...

...

...

Thông tin bố cục hợp lệ cho giá trị.

UBL 2.1

0..1

IdentifierType

BinaryObject.encodingCode:identifier

{binaryObject 3}

Thuật toán giải mã đối tượng nhị phân

UBL 2.1

0..1

...

...

...

BinaryObject.characterSet:identitier

{binaryObject 4}

Bộ ký tự được sử dụng bởi giá trị

UBL2.1

0..1

IdentifierType

BinaryObject.uri:identifier

{binaryObject 5}

Định danh tài nguyên thống nhất hợp lệ xác định vị trí của đối tượng nhị phân.

...

...

...

0..1

IdentifierType

BinaryObject.filena

me:identifier

{binaryObject 6}

Tên của tệp được sử dụng để lưu trữ đối tượng nhị phân.

UBL2.1

0..1

IdentifierType

...

...

...

{binaryObject 7}

Các octet đại diện cho giá t trị nhị phân.

JBL2.1

1

BinaryType

CodeList.id:oid

{codelist 1}

Số nhận dạng duy nhất trên toàn cầu được chỉ định cho CodeList.

JBL2.1

...

...

...

OidType

CodeList,name:name

{codelist 2}

Tên mà CodeList được biết đến.

JBL2.1

0..*

NameType

CodeList.version:identifier

{codelist 3}

...

...

...

JBL2.1

1

IdentitierType

CodeList.language:identifier

{codelist 4}

Ngôn ngữ được CodeList sử dụng như được xác định bởi RFC 5646 và RFC 4647.

UBL2.1

1

IdentitierType

...

...

...

{codelist 5}

Mã định danh tài nguyên thống nhất hợp lệ chỉ định nơi CodeList có thể được tìm thấy.

UBL2.1

0..1

IdentifierType

CodeList.scheme:identifier

{codelist 6}

Định danh tài nguyên thống nhất hợp lệ chỉ định nơi có thể tìm thấy lược đồ CodeList.

UBL2.1

...

...

...

IdentifierType

CodeList.value:identitier

{codelist 7}

Mã được chọn từ Danh sách mã phản hồi giá trị được mã hóa.

UBL2.1

1

IdentifierType

Measure.unit:identifier

{measure 1}

...

...

...

UBL2.1

1

IdentifierType

Measure.value:measure

{measure 2}

Số lượng đơn vị được chuyển tải bởi giá trị

UBL2.1

1

MeasureTyp

...

...

...

Text.language:identifier

{text 1}

Ngôn ngữ được trường văn bản sử dụng làm định danh bởi RFC 5646 và RFC 4647.

UBL2.1

1

IdentifierT yp e

Text.value:text

{text 2}

Văn bản được chuyển tải.

...

...

...

1

TextType

Bảng C.7 xác định các phần tử dữ liệu được xác định trong mô-đun ISO-14817-1-Location-1.

Bảng C.7 - Phần từ dữ liệu vị trí

Tên mô tả

OIDa

Sự đa dạng

Kiểu dữ liệu

Đơn vị đo lường

...

...

...

{geoLoca- tion 1}

1

ISO-14817-1-Domains-1.

MeasureType

(-900000000..900000 001)

c

1/10 micro degrees

(10^-7 degrees)

C.7  Miền giá trị

...

...

...

Bảng C.8 - Miền giá trị

Tên ASN.1

OIDa

Định nghĩa

Nhận xét

nguồn

kiểu dữ liệu

đơn vị đo lường

AmountType

...

...

...

định lượng bằng số của giá trị tiền tệ được chỉ định bằng đơn vị tiền tệ rõ ràng

UBL2.1

INTEGER

Shall be defined by data element

BinaryType

{value- do- mains 2}

chuỗi các octet nhị phân có độ dài hữu hạn đại diện cho một số loại thông tin.

...

...

...

OCTETSTRING

CodeType

{value- do- mains 3}

danh sách các giá trị số nguyên trong đó mỗi giá trị được xác định rõ ràng để có ý nghĩa chính xác, thường không liên quan đến ý nghĩa toán học của giá trị số nguyên

INTEGER

...

...

...

{value- do- mains 4}

Ngày dương lịch

DATE

DateTimeType

{value- do- mains 5}

Thời điểm cụ thể giờ trong ngày theo lịch dương

...

...

...

DATE-TIME

DuratíonType

{value- do- mains 6}

khoảng thời gian kéo dài từ điểm bắt đầu đến điểm kết thúc

DURATION

...

...

...

IdentifierType

{value- do- mains 7}

chuỗi ký tự được sử dụng để phân biệt phiên bản của một đối tượng trong một ngữ cảnh đã biết

Số nhận dạng tích phân phải sử dụng số miền giá trị.

UBL 2.1

VisibleString

IndicatorType

{value- do- mains 8}

...

...

...

BOOLEAN

MeasureType

{value- do- mains 9}

giá trị số có thể được đo bằng đơn vị tiêu chuẩn

UBL2.1

...

...

...

Shall be defined by data element

NameType

{value- do- mains 10}

Chuỗi ký tự có thể phát âm của con người được sử dụng để nhận dạng

UBL2.1

UTF8String

NumericType

...

...

...

Thông tin số được chỉ định và có thể được sử dụng để nhận dạng

Các kiểu số không nhằm mục đích sử dụng trong tính toán. Ví dụ, đây có thể là một số điện thoại.

UBL2.1

INTEGER

OidType

{value- do- mains 12}

mã định danh duy nhất toàn cầu được đăng ký trên cây nhận dạng đối tượng liên quốc gia và được sử dụng để phân biệt duy nhất một thể hiện của đối tượng trong ngữ cảnh đã biết.

...

...

...

OBJECT IDENTIFIER

PercentType

{value- do- mains 13}

tỉ số của hai đại lượng. Tỷ lệ phần trăm phải là tỷ số nhân với 100 và được làm tròn đến giá trị tích phân gần nhất, trừ khi có chỉ dẫn khác.

UBL2.1

INTEGER

1 phần trăm, trử khi được chỉ định khác bởi phần tử dữ liệu

...

...

...

{value- do- mains 14}

giá trị số có thể đếm được, phi tiền tệ (ví dụ: số lượng xe) có thể chịu các thao tác tính toán

Giá trị sử dụng đơn vị SI nên sử dụng miền giá trị đo lường.

UBL2.1

INTEGER

đơn vị đếm được; sẽ được xác định thêm bởi phần tử dữ liệu

RateType

{value- do- mains 15}

tỉ số của hai đại lượng. Tỷ lệ phải lả tỷ lệ được làm tròn đến số tích phân gần nhất, trừ khi có chỉ định khác (ví dụ: tỷ lệ 10: 1 sẽ được biểu thị bằng 10)

...

...

...

UBL2.1

INTEGER

toàn bộ giá trị, trừ khi được chỉ định khác bởi phần tử dữ liệu

TextType

{value- do- mains 16}

chuỗi văn bản có thể phát âm của con người

UBL2.1

UTF8String

...

...

...

TimeType

{value- do- mains 17}

Thời gian 24h trong ngày

TIME-OF-DAY

^a Định nghĩa arcs gốc của OID, xem ISO 14817-3

C.8  Mô đun ASN.1

...

...

...

ISO-14817-1-Domains-1 DEFINITIONS AUTOMATIC TAGS::= BEGIN

C.8.2  Mô đun vị trí, phiên bản 1.0

C.8.3  Mô đun phương tiện giao thông, phiên bản 1.0

Phụ lục D

...

...

...

Mô hình dữ liệu

D.1  Yêu cầu chung

Để trao đổi thông tin và sử dụng hiệu quả thông tin, các hệ thống giao tiếp cần có sự hiểu biết chung về dữ liệu được trao đổi. Điều này bao gồm sự hiểu biết chung về các mối quan hệ ngữ nghĩa giữa các phần dữ liệu khác nhau cũng như cách biểu diễn cú pháp của nó. Bất kỳ sự bất đồng nào về các mối quan hệ này có thể là một dấu hiệu cho thấy các ý nghĩa ngữ nghĩa khác nhau của dữ liệu, cần phải được giải quyết. Tuy nhiên, khi phát triển sự đồng thuận về các mối quan hệ này, các bên nên nhớ rằng sự hiểu biết chung về dữ liệu trên một giao diện không yêu cầu các triển khai giống hệt nhau trong nội bộ hệ thống.

Các mối quan hệ dữ liệu được xác định cho một giao diện phải được thiết kế để hỗ trợ một tập hợp lớn của tất cả các nhu cầu trao đổi thông tin trên giao diện. Tuy nhiên, bất kỳ hệ thống nhát định nào có thể chỉ hỗ trợ một tập hợp con nhỏ của các chức năng giao diện đã xác định và có thể cung cấp thêm các tính năng khác không liên quan đến giao diện. Thiết kế phù hợp nhất của một hệ thống phụ thuộc vào tất cả các yêu cầu chức năng của hệ thống đó với định nghĩa giao diện chì là một yêu cầu. Do đó, mỗi hệ thống có thể sẽ sử dụng cách trình bày dữ liệu cụ thể của chính nó trong nội bộ. Các mối quan hệ bên trong được xác định bởi một lược đồ cơ sở dữ liệu, mô hình đối tượng hoặc một số kỹ thuật khác và sau đó được dịch khi cần thiết thành biểu diễn chung được xác định bởi định nghĩa giao diện.

Bởi vì nhiều nhà thiết kế hệ thống phải hiểu định nghĩa giao diện, điều quan trọng là nó phải được ghi chép đầy đủ. Kinh nghiệm cho thấy rằng một trong những cách tốt nhất mà con người có thể đọc được để thể hiện các mối quan hệ này là thông qua việc sử dụng các mô hình dữ liệu. Sau đó, các mô hình dữ liệu này có thể được chuyển đổi thành các định dạng máy tính có thể đọc được nếu cần.

Phụ lục này xác định các hướng dẫn để tạo ra các mô hình dữ liệu trong miền ITS. Chúng dựa trên các khái niệm dữ liệu được định nghĩa trong Điều 6 và được minh họa trong ví dụ dưới đây bằng cách sử dụng ký hiệu đồ họa của Ngôn ngữ tạo mô hình hợp nhất.

CHÚ THÍCH: Xem thông số kỹ thuật cho UML 1.3 trong ISO / IEC 19501

D.2  Ví dụ về mô hình hóa dữ liệu

Mô hình dữ liệu ở đây được mô tả thông qua việc sử dụng một ví dụ. Một ví dụ duy nhất được sử dụng trong Phụ lục này để trình bày triết lý cơ bản cũng như để chứng minh các quy tắc và hướng dẫn được xác định bởi Tiêu chuẩn này. Ví dụ mô tả mối quan hệ chung giữa Điểm dừng và Đường, như được định nghĩa trong Giao thông công cộng Tính năng của tiêu chuẩn Tệp Dữ liệu Dia ly (GDF 4 0. ISO CD 14825).

...

...

...

Hình D.1- Mô hình dữ liệu đơn giản

Hình D. 1 mô tả hai lớp đối tượng: StopPoint và Line, được biểu thị dưới dạng hình chữ nhật với tên lớp đối tượng trong phân vùng trên cùng. Một đường nối hai hình chữ nhật đại diện cho một liên kết và các phần tô điểm ở mỗi đầu của đoạn thẳng đặc trưng cho liên kết đó. Hình D.1 cũng mô tả bốn thuộc tính đã được gán cho lớp đối tượng StopPoint là stopldentifier, stopType, nationallD và các dòng. Ba trong số các thuộc tính được bao gồm trong phân vùng thuộc tính của hình chữ nhật lớp đối tượng trong khi thuộc tính thứ tư (các dòng) được đặt bên cạnh lớp đối tượng Dòng để biểu thị vai trò được thực hiện bởi lớp đối tượng Line liên kết với lớp đối tượng StopPoint. Có ba thuộc tính được gán cho Line: lineName, lineOperator và các điểm dừng. Hai trong số các thuộc tính được bao gồm trong hình chữ nhật lớp đối tượng trong khi phần thứ ba (điểm dừng) được đặt bên cạnh lớp đối tượng StopPoint để biểu thị vai trò được thực hiện bởi lớp đối tượng StopPoint liên kết với lớp đối tượng Dòng. Thuộc tính “điểm dừng” của Dỏng có thể có một số trường hợp (tức là một Dòng được liên kết với n Điểm dừng) và một Điểm dừng được liên kết với từ 0 đến n phiên bản của Dòng. Cuối cùng, hình chỉ ra rằng miền giá trị “Chuỗi" xác định dạng biểu diễn của stopldentifier.

Tuy nhiên, một số hệ thống có thể muốn ghi lại nhiều ngữ nghĩa cấu trúc hơn liên quan đến bối cảnh giao thông công cộng này. về mặt này, Hình D.2 cung cấp một tập hợp dữ liệu và các mối quan hệ toàn diện hơn. Trình bày này cung cấp tất cả thông tin được cung cấp trong ví dụ trước, cùng với thông tin bổ sung về sự tham gia của StopPoint trong các ngữ cảnh khác nhau. Xem Bảng D.1 để biết tóm tắt và ví dụ về mối quan hệ StopPoint. Ví dụ về Điểm dừng ví dụ, “Regent Street 1200-1”, là một phần của tuyến đường cao tốc có thể chỉ có một số Điểm dừng khác giữa điểm xuất phát và điểm đến của nó. Đồng thời, “Đường Regent 1200-1” nằm trên hai Tuyến đường khác đóng vai trò là các tuyến đường nhánh. Do đó, “Regent Street 1200-1” được đăng ký đồng thời với ba Tuyến đường, trong khi nhiều hoặc tất cả các Điểm dừng trên các tuyến đường gom có thể chỉ là một phần của một Tuyến đường.

Hình D.2 - Mô hình dữ liệu toàn diện

Bảng D.1 - Mối quan hệ StopPoint

ObjectClass:

StopPoint

...

...

...

Line

Property:

stopldentifier

routeOrigin

routeName

lineName

Value Domain:

String

String

...

...

...

String

Instance:

Regent street 1200-1

Green Square

Green Square inbound express

Penfield station

Instance:

Regent street 1200-1

Templestowe

...

...

...

Templestowe District

Instance:

Regent street 1200-1

Longfield

Longfield- Templestowe

Templestowe District

Instance:

Lavender Lane 200-1

Templestowe

...

...

...

Templestowe District

Instance:

Fountain Circuit 400-2

Longfield

Longfield-Templestowe

Templestowe District

Mô hình toàn diện cũng chỉ ra rằng Line xác định StopPoint thông qua mã định danh được chỉ định (stopNumber), trong khi StopPoint kết nối với các tuyến khác nhau của nó bằng routeNumber và lineName. Mô hình toàn diện cũng chỉ ra rằng một Tuyển đường nhất định (cá thể) có thể được liên kết với không có hoặc chỉ một Đường. Cuối cùng, mô hình chỉ ra rằng MaximumRouteTravelTime chỉ có liên quan trong mô hình nếu Tuyến đường là Tuyến theo yêu cầu, trong trường hợp đó, AverageServicelnterval cũng được ghi lại cho mục đích thông tin khách du lịch.

Hình chiếu thứ ba thay thế của mô hình này được mô tả trong Hình D.3. Sơ đồ này cho phép một hệ thống lưu trữ tất cả thông tin được xác định trong Hình D.2, nhưng nó không cung cấp cho người đọc một số mối quan hệ ngữ nghĩa cụ thể hơn. Ví dụ, Hình D.3 bỏ qua bất kỳ mối quan hệ nào giữa routeDestination đầu tiên và routeOrigin đầu tiên. Điều này không có nghĩa là không tồn tại, nhưng mô hình không gọi ra chi tiết này. Tuy nhiên, người triển khai có thể dễ dàng phát triển hệ thống dựa trên mô hình thứ ba trong khi áp dụng các quy tắc được xác định trong mô hình thứ hai và có thể cung cấp thành công cùng một dữ liệu như được cung cấp trong Hình D.1 và D.2.

...

...

...

Do đó, Hình D.1 và D.3 là các mô hình triển khai hợp lệ cho mô hình dữ liệu được xác định bởi Hình D.2 (mặc dù hệ thống thực hiện Hình D.1 sẽ chỉ hỗ trợ một tập hợp con của thông tin đã xác định). Mục đích đằng sau mô hình dữ liệu là xác định chính xác dữ liệu và các mối quan hệ để tất cả các bên liên quan hiểu được mục đích của mô hình nhưng việc triển khai mô hình được phép đơn giản hóa thiết kế để đáp ứng các yêu cầu khác của hệ thống.

D.3  Ví dụ về trao đổi thông tin

Quy trình đăng ký khái niệm dữ liệu được xác định trong Tiêu chuẩn này là nhất quán để cho phép triển khai (các) kiến trúc ISO ITS như được định nghĩa trọng ISO / TR 14813-2 và ISO / TR 14813-

3. Tuy nhiên, điều này không loại trừ việc áp dụng DD bằng phương pháp hoặc kỹ thuật thay thế của Kiến trúc Hệ thống Quốc tế, Khu vực hoặc Quốc gia, thực sự, CIDCR sẽ dễ dàng di chuyển và khả năng tương tác giữa các phương pháp tiếp cận như vậy. Ví dụ dưới đây phác thảo cách các khái niệm dữ liệu có thể được phát triển và minh họa một số siêu thuộc tính quan trọng được công nhận cho một DD.

Các siêu thuộc tính cần thiết để ghi lại các khái niệm dữ liệu trong DD được liệt kê trong các bảng trong Phụ lục A. Các siêu thuộc tính quan trọng nhất áp dụng cho việc lập mô hình Hội thoại Giao diện được minh họa bằng ví dụ sau. Ví dụ dựa trên ngữ nghĩa của mô hình dữ liệu của Hình D.2.

Hội thoại giao diện ví dụ bắt nguồn từ sơ đồ ca sử dụng phương tiện giao thông công cộng trong ISO 14813-2, Hình 19. Một phần nhỏ của sơ đồ đó được mô phỏng lại trong Hình D.4. Hình D.4 mô tả việc cung cấp thông tin giao thông công cộng cho khách du lịch.

Hình D.4 - Sơ đồ ca sử dụng phương tiện công cộng (tập hợp con)

CHÚ THÍCH: Các ký hiệu đồ họa trong Hình D.4 là từ Ngôn ngữ tạo mô hình thống nhất. Hình gậy biểu thị một tác nhãn, một hệ thống bên ngoài hoặc người dùng, có được hoặc tham gia vào chức năng của hệ thống ITS. Hình elip biểu thị một đơn vị chức năng được gọi là ca sử dụng. Một ca sử dụng mang lại kết quả có ý nghĩa cho một hoặc nhiều tác nhân.

...

...

...

Các khái niệm dữ liệu tham chiếu của ví dụ được mô tả trong Bảng D.2. Các ô trong Bảng D.2 tương ứng với các trường hợp của các siêu thuộc tính bắt buộc chính được chỉ định trong Bảng A.1 liên quan đến hội thoại giao diện. Các giá trị trong mỗi ô (ví dụ: “id 1”) biểu thị các số nhận dạng duy nhất cho các trường hợp khái niệm dữ liệu. Các giá trị này sẽ được triển khai bằng cách sử dụng một trong các siêu thuộc tính được xác định trong Bảng D.1 là các mã định danh khái niệm dữ liệu duy nhất (ví dụ: mã định danh khái niệm dữ liệu hoặc mã định danh đối tượng). Sử dụng cách tiếp cận từ trên xuống, hộp thoại giao diện, Traveler « BusQuery » ISP, tham chiếu các thông điệp với Bộ phân định khái niệm dữ liệu (DCI) của m1 và m2. Thông điệp m1, RouteRequest (): thông điệp, tham chiếu đến một phần tử dữ liệu duy nhất có DCI là de2 và có “Tên mô tả” là Route.routeNumber: mã định danh. Route.routeNumber: mã định danh tham chiếu đến lớp đối tượng có DCI là c2 và “Tên mô tả” là Tuyến. Sau đó, điều này có thể liên quan trở lại Hình D.2, nơi routeNumber được xác định là một thuộc tính của lớp đối tượng Route. Giống như thời trang, các mối quan hệ xung quanh thông điệp m2 có thể được truy tìm. Thông tin mô hình bổ sung được chứa trong các khái niệm dữ liệu kết hợp a1 và a2 đại diện cho các mối quan hệ giữa ba lớp đối tượng được trình bày trong Hình D.2

Hình D.5 - Sơ đồ tương tác cho truy vấn bus

CHÚ THÍCH: Hộp thoại giao diện có thể là một chuỗi gồm một tập hợp các thông điệp và một tập hợp các thông điệp. Thời gian chạy dọc theo sơ đồ

Bảng D.2 - Siêu thuộc tính hội thoại giao diện

ID khái niệm dữ liệu

Kiểu khái niệm dữ liệu

Tên mô tả

Định nghĩa

...

...

...

Lớp Ref

Thông điệp Ref

id 1

Hội thoại giao diện

Traveller <-Bus- Query-> ISP

Cho phép nhà cung cấp dịch vụ thông tin đáp ứng truy vấn: điểm dừng trên tuyến đường là gì?

c1, c2, c3

m1, m2

...

...

...

Thông điệp

RouteRequest:message

Cho phép hỗ trợ khách du lịch từ xa đặt câu hỏi: điểm dừng trên tuyến đường là gì

de2

m2

Thông điệp

Stop List:mes- sage

...

...

...

de2, de3, de4, de5

de1

Phần tử dữ liệu

Line.lineName:-

text

Tên tuyến vận tải công cộng

...

...

...

de2

Phần tử dữ liệu

Route, route- Number: identifier

Mã định danh của Tuyến đường trên Tuyến giao thông công cộng

c2

de3

...

...

...

StopPoint.stopldentifier:identifier

An identifier in a limited context for a public transport stop Point

c3

de4

Phần tử dữ liệu

StopPoint.Stop- Number:number

Thứ tự của Điểm dừng giao thông công cộng trong Tuyến đường

...

...

...

c3

de5

Phần tử dữ liệu

StopPoint. natlonallD: identifier

Mã định danh quốc gia cho điểm dừng qiao thông công công

c3

...

...

...

Lớp đối tượng

Line

Lớp đối tượng được sử dụng để mô tả tất cả các tuyến giao thông công cộng

del

c2

Lớp đối tượng

Route

...

...

...

de2

c3

Lớp đối tượng

StopPoint

Lớp đối tượng được sử dụng để mô tả tất cả các điểm dừng giao thông công cộng

de3, de4, de5

...

...

...

a1

Khung dữ liệu

Line. Routes: <- aggre- gate-> Route

Tập hợp các tuyến giao thông công cộng trong một tuyến

c1, c2

a2

Kết hợp

...

...

...

Liên kết một tuyến đường với các điểm dừng của nó

c2, c3

D.4  Hướng dẫn về mô hình hóa dữ liệu

D.4.1  Dữ liệu ITS được sử dụng trong các thay đổi phải được biểu diễn trong một mô hình dữ liệu

Để đạt được khả năng tương tác, sự hiểu biết chung về các mối quan hệ ngữ nghĩa giữa các dữ liệu là rất quan trọng. Kinh nghiệm cho thấy răng các mô hình dữ liệu cung cấp một công cụ hữu ích trong việc ghi lại các mối quan hệ này. Do đó, tất cả các khái niệm dữ liệu phải được lập thành văn bản trong mô hình dữ liệu trước khi được nâng cấp lên trạng thái chất lượng “Đủ tiêu chuẩn” (xem ISO 14817-2).

D.4.2  Biểu đồ lớp UML nên được sử dụng để mô tả các mô hình dữ liệu

Theo thời gian, đã có nhiều kỹ thuật mô hình hóa được phát triển để mô tả mối quan hệ giữa các dữ liệu. UML đã hợp nhất các khái niệm được tìm thấy trong nhiều kỹ thuật này và hiện đã trở thành phương pháp luận được công nhận rộng rãi nhất để ghi lại các mối quan hệ. Do đó, miền ITS nên sử dụng UML để mô tả các khái niệm dữ liệu được ghi lại trong bất kỳ DD nào. Yêu cầu này bao gồm việc mô tả các hiệp hội và chuyên môn.

...

...

...

Phụ lục này thiết lập một đường cơ sở các tính năng được coi là thích hợp cho các đối tượng mục tiêu khác nhau của các tiêu chuẩn ITS. Nó cũng đóng vai trò như một hướng dẫn về cách đọc các ký hiệu và sổ quy tắc về cách ánh xạ giữa định dạng DD và UML. Các tác giả của các tiêu chuẩn ITS nên nhớ rằng các sơ đồ UML nhằm cung cấp một cái nhìn tổng quan về miền thông tin; ngữ nghĩa chi tiết đầy đủ của miền thông tin luôn được đưa vào nội dung của DD.

Tuy nhiên, nếu các nhà phát triển tiêu chuẩn nhận thấy nhu cầu đặc biệt để sử dụng các ký hiệu khác, tiêu chuẩn chủ đề phải bao gồm văn bản giải thích để giải thích ngữ nghĩa được áp dụng bởi kỹ thuật sơ đồ.

LƯU Ý UML là một ngôn ngữ rất toàn diện, mạnh mẽ và nhiều người đọc các tiêu chuẩn ITS có thể không quen với các tính năng phức tạp hơn của nó. Do đó, nên tránh một số ký hiệu phức tạp hơn để không gây nhầm lẫn cho người đọc hoặc không khuyến khích các bên liên quan đọc và sử dụng các tiêu chuẩn.

D.4.4  Mỗi lớp đối tượng được xác định phải được biểu diễn trong ít nhất một sơ đồ lớp UML

Biểu đồ lớp UML có thể hiển thị nhiều hơn một lớp đối tượng và một lớp đối tượng nhất định có thể xuất hiện trong nhiều biểu đồ

Ngăn tên lớp nên hiện diện cho tất cả các lớp đối tượng được hiển thị trong sơ đồ. Các lớp đối tượng trừu tượng nên được mô tả bằng tên lớp của chúng được in nghiêng.

Các thuộc tính và ngăn hoạt động của sơ đồ lớp UML có thể bị bỏ qua đối với bất kỳ lớp đối tượng nào.

Nếu một lớp đối tượng là một chuyên môn hỏa của một lớp đối tượng khác, thì mối quan hệ phải được mô tả trong ít nhất một sơ đồ lớp UML. Chuyên môn Từ điển dữ liệu giống với chuyên môn UML. Sơ đồ có thể hiển thị nhiều cấp độ chuyên môn hóa, nhưng nó không bắt buộc.

D.4.5  Tất cả các phần tử dữ liệu thành phần và khung dữ liệu của lớp đối tượng phải được xác định trong sơ đồ lớp UML

...

...

...

Phần tử dữ liệu được mô tả như một thuộc tính và có nhiều giá trị có thể vượt quá một (1) nên được mô tả dưới dạng một mảng bằng cách bao gồm một cặp dấu ngoặc vuông (“[]”) sau tên thuộc tính.

CHÚ THÍCH: Mặc dù mỗi khái niệm phần tử dữ liệu phải được mô tả trong ít nhất một sơ đồ lớp UML, nhưng không bắt buộc phải mô tả tất cả các khái niệm phần tử dữ liệu cho một lớp đối tượng nhất định trong một sơ đồ UML. Tính linh hoạt này được cung cấp để các chuyên gia miền có thể cấu trúc các sơ đồ lớp để có thể đọc được tối đa; điều này có thể đạt được tốt nhất bằng cách hiển thị thông tin này trong một loạt các sơ đồ thay vì trong một sơ đồ đơn lẻ. Cũng có thể có trường hợp các thuộc tính chỉ áp dụng trong một số trường hợp nhất định.

D.4.6  Miền giá trị có thể được hiển thị

Miền giá trị cho một phần tử dữ liệu có thể được chì ra trong sơ đồ lớp UML.

Khi được hiển thị, miền giá trị phải được chỉ định là kiểu dữ liệu UML của thuộc tính được liên kết (tức là chuyển đổi biểu diễn khái niệm phần tử dữ liệu thành biểu diễn phần tử dữ liệu). Tên loại phải giống với tên mô tả của miền giá trị được liên kết.

LƯU Ý Các phần tử dữ liệu tương ứng với bộ ba kiểu thuộc tính lớp trong UML.

D.4.7  Các bảng phải được định nghĩa là một cặp lớp đối tượng liên kết

Một bảng logic nên được định nghĩa bằng cách sử dụng một lớp đối tượng bảng cung cấp thông tin về nội dung bảng và một lớp đối tượng mục nhập được liên kết xác định nội dung của môi bản ghi trong bảng.

Nội dung của một bảng, tức là các mục nhập, có thể được truy cập bởi nhiều lớp đối tượng bảng. Mỗi đường dẫn truy cập phải xác định khóa được sử dụng để xác định các mục nhập cụ thể trong bảng.

...

...

...

D.4.8.1 Quy tắc thuộc tính

Cách đặt tên và ngữ nghĩa của thuộc tính phải đủ chung để cho phép sử dụng thuộc tính với nhiều hơn một đối tượng. Tên và ngữ nghĩa cũng phải đủ chung để cho phép sử dụng thuộc tính với nhiều miền giá trị.

Ví dụ: thuộc tính “tốc độ” có thể được định nghĩa là “Chỉ báo về tốc độ mà đối tượng chủ thể đang di chuyển qua một khoảng cách như được ghi lại tại một thời điểm duy nhất trong thời gian hoặc được đo tại một điểm cụ thể". Lưu ý rằng định nghĩa đủ chung để áp dụng cho nhiều loại đối tượng khác nhau cũng như không phụ thuộc vào dạng biểu diễn (cho dù ở đơn vị chi tiết, mã lớp, v.v.) Cũng lưu ý rằng nó đủ rõ ràng đề không bị nhầm lẫn với tốc độ trung bình trên một số khoảng cách hoặc liên quan đến các thực thể bên thứ ba (ví dụ: nếu được áp dụng cho liên kết, nó sẽ xác định tốc độ mà liên kết đang di chuyển - không phải tốc độ xe ô tô trên liên kết đang di chuyển).

D.4.8.2  Quy tắc phần tử dữ liệu

Mỗi phần tử dữ liệu phải là duy nhất. Không được tồn tại hai phần tử dữ liệu có cùng lớp đối tượng, cùng thuộc tính và cùng miền giá trị. Nếu hai phần tử dữ liệu có cùng một lớp đối tượng và cùng một thuộc tính, thì hai phần tử dữ liệu phải có liên quan với nhau thông qua thuộc tính đồng nghĩa.

Ví dụ: Car.speed: Tốc độ và Car.speed: SpeedMPH có thể là hai phần tử dữ liệu. Mỗi tài liệu ghi lại thuộc tính tốc độ của lớp đối tượng Xe, nhưng một tài liệu được biểu thị theo miền giá trị Tốc độ, có thể tính bằng mét trên giây, trong khi tài liệu kia được biểu thị theo miền giá trị SpeedMPH, có thể tính bằng dặm trên giờ. Hai phần tử dữ liệu sẽ được yêu cầu tham chiếu đến nhau thông qua thuộc tính Từ đồng nghĩa.

Phụ lục E

(tham khảo)

...

...

...

E.1  Yêu cầu chung

Phụ lục này mô tả cách các khái niệm dữ liệu hiện có, có thể không phù hợp với Tiêu chuẩn này, có thể được nâng cấp để đáp ứng các yêu cầu tuân thủ tối thiểu.

Các tiêu chuẩn giao diện dữ liệu hiện có trong cộng đồng ITS thường xác định dữ liệu của chúng trong các Lược đồ ASN.1 hoặc XML. Ví dụ được trình bày trong phụ lục này dựa trên ASN.1, nhưng quy trình đối với XML cũng tương tự.

Tối thiểu, một đặc tả ASN.1 phải xác định cấu trúc dữ liệu liên quan đến cú pháp ASN.1 chính thức và có mô tả kèm theo của từng trường trong cấu trúc. Tuy nhiên, nhiều tiêu chuẩn giao diện ITS đã được viết ra để hoàn thành mục tiêu trong tầm tay mà không tính đến việc làm cho dữ liệu có thể dễ dàng sử dụng lại. Ví dụ: tên của các trường trong cấu trúc được viết tắt theo những cách ít rõ ràng hơn nếu không biết về các phần khác của tiêu chuẩn. Hơn nữa, định nghĩa của các trường thường được đưa vào văn bản của tiêu chuẩn. Kết quả là, để người đọc hiểu đầy đủ cấu trúc hoặc thậm chí một trường, người đọc thường phải đọc một phần đáng kể của tiêu chuẩn. Mặc dù điều này được mong đợi đối với bất kỳ ai đang cố gắng thực hiện tiêu chuẩn, nhưng nó gây khó khăn cho các nhà phát triển các tiêu chuẩn khác trong việc nhanh chóng sử dụng lại các khái niệm dữ liệu đã xác định

Việc ghi lại các định nghĩa khái niệm dữ liệu ở định dạng chung sẽ thúc đẩy việc tái sử dụng dữ liệu với một lượng nỗ lực tối thiểu.

E.2 cung cấp một ví dụ về dữ liệu vì nó có thể xuất hiện trong tài liệu từ điển không phù hợp với tiêu chuẩn này. Ví dụ này dựa trên cùng ngữ nghĩa cơ bản được mô tả trong Điều 6 và được mô tả trong Hình 5 và 7. E.2 cung cấp phân tích về dữ liệu này và định dạng kế thừa. E.4 xác định các khái niệm dữ liệu tương tự như được định nghĩa trong E.2, nhưng được cập nhật để phù hợp tối thiểu với Tiêu chuẩn này. E.5 đưa ra bình luận về thời điểm nên thực hiện loại dịch này.

E.2  Dữ liệu kế thừa mẫu

Khi nhận được thông điệp CollisionReportRequest, hệ thống chủ sẽ gửi cho hệ thống yêu cầu một bản tin va chạm

...

...

...

Thông điệp Va chạm sẽ được sử dụng để cung cấp danh sách các va chạm đã biết, đang hoạt động và được định nghĩa như sau:

E.2.2  Va chạm

Khung dữ liệu Va chạm sẽ được sử dụng để cung cấp thông tin về một va chạm và được định nghĩa như sau:

E.2.3  Ngày giờ

Trường thời gian sẽ cung cấp thời gian ước tính tại đó tai nạn xảy ra và được xác định như sau:

...

...

...

E.2.4  Mức độ nghiêm trọng

Mã mức độ nghiêm trọng cho biết loại mức độ nghiêm trọng như sau:

E.2.5  Phương tiện

Mỗi Phương tiện được mô tả theo kiểu dáng, kiểu dáng và biển số của nó.

E.3  Phân tích dữ liệu kế thừa mâu

Phân tích ví dụ về dữ liệu kế thừa cho thấy rằng các định nghĩa về khái niệm dữ liệu không phù hợp với Tiêu chuẩn này theo một số cách, bao gồm cả những cách sau đây.

a) Tên khái niệm dữ liệu phải tuân theo các quy ước đặt tên, ví dụ:

...

...

...

2) thời hạn tài sản phải luôn được giải thích rõ ràng.

b) Tất cả các khái niệm dữ liệu phải được xác định (ví dụ: miền giá trị phải được phân biệt với các phần tử dữ liệu)

c) Các định nghĩa phải được nêu rõ ràng và riêng biệt cho từng khái niệm dữ liệu (ví dụ: định nghĩa về cấu tạo của phương tiện bị giới hạn và kết hợp với định nghĩa về kiểu xe và biển số xe).

d) Trong khi ngữ cảnh cung cấp các manh mối hợp lý, kiểu khái niệm dữ liệu phải được xác định rõ ràng.

e) Các biểu diễn được sử dụng phải luôn tuân theo các miền giá trị ưu tiên.

f) Tên mô-đun phải được cung cấp cho mã ASN.1 đầy đủ.

Tuy nhiên, bằng cách đọc đầy đủ tiêu chuẩn, chúng ta có thể hiểu rõ từng vấn đề này để phát triển các khái niệm dữ liệu phù hợp vẫn tương thích ngược với đặc điểm kỹ thuật gốc. Bước đâu tiên là phân tích dữ liệu và đưa ra mô hình dữ liệu mà dữ liệu đại diện. Các mô hình dữ liệu này giống với các mô hình được trình bày trong Hình 5 và 7. Bước tiếp theo là ghi lại từng mục trong mô hình này, được thực hiện trong điều khoản tiếp theo.

Dữ liệu sửa đổi có thể được trình bày theo một số cách, E.4 trình bày dữ liệu ở định dạng bảng sử dụng cấu trúc bảng hơi khác cho từng loại khái niệm dữ liệu với các màu của bảng tương ứng với các siêu thuộc tính khác nhau được xác định trong Tiêu chuẩn này. Mỗi hàng của bảng biểu thị một khái niệm dữ liệu riêng biệt của loại được đặc trưng bởi bảng

Cấu trúc bảng cho phép dễ dàng nhập vào các công cụ như sổ đăng ký dữ liệu, nhưng số lượng cột thường có nghĩa là nó dễ đọc hơn ở định dạng ngang.

...

...

...

E.4.1  Tài liệu Từ điển

Bảng E.1 xác định khái niệm dữ liệu tài liệu từ điền đại diện cho Phụ lục này.

Bảng E.1 - Tải liệu Từ điển

Mã định danh tài liệu

Tên theo ngữ cảnh

Định nghĩa

ISO 14817-1, Annex E

Hệ thống giao thông thông minh - Từ điển dữ liệu ITS - Phần 1: Yêu cầu đối với định nghĩa Dữ liệu ITS

Tài liệu từ điển xác định một tập hợp các khái niệm dữ liệu kiểm tra để trình bày cách nâng cấp các định nghĩa khái niệm dữ liệu từ các định dạng cũ.

...

...

...

CHÚ THÍCH 2: Không cần phải bao gồm một cách rõ ràng cột cho siêu thuộc tính kiểu khái niệm dữ liệu vì Bảng E.1 được định nghĩa để chì xác định một kiểu khái niệm dữ liệu.

CHÚ THÍCH 3: Thông thường, định danh tài liệu sẽ không bao gồm bắt kỳ phụ lục hoặc phần nào; tuy nhiên, chúng tôi đã thêm nó vào đây để phân biệt dữ liệu mẫu này với dữ liệu thực

E.4.2  Các lớp đối tượng

Bảng E.2 xác định các lớp đối tượng được sử dụng trong ngữ cảnh của Phụ lục E

Bảng E.2 - Các Iớp đối tượng

Tên theo ngữ cảnh

Định nghĩa

Nguồn

Tóm tắt

...

...

...

Các va chạm

Hồ sơ va chạm

Sai

Va chạm

ghi lại mô tả sự kiện tai nạn phương tiện giao thông đường bộ trong đó một phương tiện giao thông đâm vào hoặc bị một phương tiện khác, người tham gia giao thông hoặc chướng ngại vật đâm phải với thiệt hại và / hoặc thương tích sau đó

ISO 6813:1998, (3.3)

Sai

...

...

...

Phương tiện giao thông

phương tiện vận chuyển hàng hóa và con người trên bộ

ISO 11783-1:2007, (3.70)

Sai

CHÚ THÍCH 1: Các khái niệm này không được định nghĩa rõ ràng trong văn bản gốc, nhưng các định nghĩa hiện có, có thể áp dụng được tìm thấy bằng cách sử dụng Nền tảng duyệt trực tuyến ISO.

CHÚ THÍCH 2: Không cần bao gồm một cách rõ ràng một cột cho siêu thuộc tính ngữ cành vì bảng được giới thiệu với một cầu lệnh xác định ngữ cành cho mỗi mục

E.4.3  Mô-đun

Bảng E.3 xác định các mô-đun được xác định trong ngữ cảnh của Phụ lục E.

...

...

...

Tên ngữ cảnh

Định nghĩa

ISO-14817-1 -E-Dialoque-1

Mô-đun xác định hội thoại để trao đổi báo cáo va chạm

ISO-14817-1-E- CollisionReportRe- quest-1

Mô-đun xác định phiên bản đầu tiên của thông điệp yêu cầu cho dữ liệu báo cáo xung đột.

ISO-14817-1 -E-Collisions-1

Mô-đun xác định phiên bản đầu tiên của thông điệp trả lời cho dữ liệu báo cáo xung đột.

ISO-14817-1 -E-Data-1

...

...

...

LƯU Ý Văn bản gốc không xác định các mô-đun. Mặc dù, trong các quy tắc của ASN.1, tất cả các khái niệm dữ liệu có thể được kết hợp thành một mô-đun duy nhất, Tiêu chuẩn này chỉ ra rằng chúng phải được tách thành các mô-đun riêng biệt. Việc tách từng thông điệp thành mô-đun riêng cho phép khả năng tương thích ngược và kiểm soát phiên bản tốt hơn. Các bộ phận khác của dữ liệu được thiết kế để thúc đẩy việc tái sử dụng các mô-đun giữa các tiêu chuẩn khác nhau.

E.4.4  Hội thoại giao diện

Bảng E.4 xác định các hội thoại giao diện được xác định trong mô-đun ISO-14817-1-E-Dialogue-1.

Bảng E.4 - Hội thoại giao diện

Tên ngữ cảnh

Định nghĩa

Quy tắc đặt hàng hộp thoại

Tin nhắn tham chiếu

Collision ReportDialogue: dialogue

...

...

...

a) Hệ thống chủ sẽ truyền một bản tin CollisionReportRequest đến hệ thống đích.

CollisionReportRequest: message

b) Hệ thống đích sẽ phản hồi bằng thông điệp Va chạm.

Collisions: message

CHÚ THÍCH: Văn bản gốc đã mô tả quá trình này trong văn bản của tiêu chuẩn. Trong các tiêu chuẩn dài dòng, thông tin này thường có thể khó tìm. Bằng cách đặt thông tin quan trọng này ở một nơi, người đọc sẽ dễ dàng hơn và nhập vào sổ đăng ký dễ dàng hơn.

E.4.5  Bản tin

Bảng E.5 xác định các bản tin được xác định trong các mô-đun được chỉ ra.

Bảng E.5 - Bán tin

...

...

...

Tên ASN.1 lịch sử

HistoricASN.1 Name

Định nghĩa

Kiểu dữ liệu

ISO-14817-1-E-

Collision-

ReportRequest-1

CollisionReportRequest

yêu cầu

...

...

...

NULL

ISO-14817-1-E-

Colli-

sions-1

Collisions

trả lời

Một tin nhắn trả lời bao gồm danh sách các va chạm đang hoạt động được lưu trữ trong hệ thống.

SEQUENCE{

reports ISO-14817- 1-E-Data.

...

...

...

}

CHÚ THÍCH 1: Bằng cách tuân theo các quy ước đặt tên, chúng tôi có thể cung cấp một tên duy nhất (trong trường hợp này là tên ASN.1) và người đọc có thể dễ dàng tìm ra bất kỳ tên nào khác mà họ có thể quan tâm.

CHÚ THÍCH 2: Tên ASN.1 Lịch sử cung cấp liên kết trở lại phiên bản trước của tiêu chuẩn. Do đó, thay đổi duy nhất đã xảy ra là trong tài liệu, cấu trúc thực tế có thể không thay đổi.

CHÚ THÍCH 3: Đây là một ví dụ đơn giản; thường thì một thông điệp sẽ chứa nhiều khung dữ liệu và các phần từ dữ liệu và định nghĩa của thông điệp cung cấp mô tế bao quát về nội dung và cách nó được sử dụng.

CHÚ THÍCH 4; Mặc dù Kiểu dữ liệu cho Xung đột đã thay đổi so với phiên bản gốc (tức là “ISO-14817-1-E- Dữ liệu-1. Báo cáo về sự va chạm” thay vi “SEQUENCE OF Va chạm”), cả hai câu lệnh đều giải quyết thành cấu trúc giống hệt nhau, do đó định dạng lại định dạng vẫn tương thích ngược 100% với định nghĩa cũ

E.4.6  Khung dữ liệu

Bảng E.6 xác định các khung dữ liệu được xác định trong mô-đun ISO-14817-1-E-Data-1.

Bảng E.6 - Khung dữ liệu

Tên ASN.1

...

...

...

Định nghĩa

T

Kiểu dữ liệu

Coliision-

involvedVe-hicles

Danh sách các phương tiện bị ảnh hưởng trong vụ va chạm

1

SEQUENCE OF VehicleDe-scription

...

...

...

Ngày và giờ ước tính xảy ra vụ va chạm

1

DateTime

Collisions-reports

Danh sách các va chạm đang hoạt động trong hệ thống

1

SEQUENCE OF Collision- Report

...

...

...

E.4.7  Tên miền tổng hợp

Bảng E.7 xác định các miền tổng hợp được xác định trong mô-đun ISO-14817-1-E-Data-1

Bảng E.7 - Miền Tổng hợp

Tên ASN.1

Tên ASN.1 lịch sử

Định nghĩa

Lớp đối tượng chính

Kiểu dữ liệu

CollisionReport

...

...

...

thông tin về một vụ va chạm

Va chạm

DateTime

thời gian cụ thể tức thì theo dương lịch ở múi giờ địa phương

Thời gian

VehicleDescription

...

...

...

mô tả ngắn và nhận dạng một phương tiện

Phương tiện giao thông

4.8  Phần tử dữ liệu

Bảng E.8 xác định các phần tử dữ liệu được xác định trong mô-đun TCVN xxxx:202x-E- Data-1

Bảng E.8 - Phần tử dữ liệu

Tên ASN.1

Tên ASN.1 lịch sử

Định nghĩa

...

...

...

Kiểu dữ liệu

Đơn vị đo lường

Collision-

severity

SeverityCode

Mức độ nghiêm trọng của va chạm.

1

...

...

...

Ngày lịch trong tháng cho Thời gian được mô tả.

1

Ngày

Time-hour

Giờ trong ngày đối với Thời gian được mô tả.

1

...

...

...

giờ

Time-millisecond

Phần nghìn giây trong giây cho Thời gian được mô ta.

1

Mill giày

Time-minute

...

...

...

1

Phút

Time-month

Tháng trong năm cho Thời gian được mô tả.

1

Tháng

...

...

...

Thứ hai trong vòng một phút cho Thời gian được mô tả.

1

Giây

Time-year

Năm dương lịch cho Thời gian được mô tả.

1

...

...

...

Năm

Vehicle-

license-Plate

Biển số phương tiện hiển thị

1

Vehicle-make

...

...

...

Việc tạo ra chiếc xe theo các dấu hiệu bên ngoài.

1

Vehicle-model

Mô hình của chiếc xe theo dấu hiệu bên ngoài.

1

...

...

...

CHÚ THÍCH 1: Các định nghĩa bằng văn bản về khái niệm dữ liệu mức thấp không đề cập đến việc sử dụng dữ liệu. Mặc dù điều này rất quan trọng đối với các khái niệm dữ liệu cấp cao (ví dụ: một thông điệp), các phần tử dữ liệu và khung dữ liệu phải được viết để có thể tái sử dụng cho nhiều mục đích.

CHÚ THÍCH 2: Mặc dù ưu tiên hơn là các phần tử dữ liệu tham chiếu đến các miền giá trị có thể tái sử dụng và được xác định riêng, nhưng chúng có thể tham chiếu trực tiếp bất kỳ cấu trúc ASN.1 hợp lệ nào. Điều này cho phép bất kỳ cấu trúc ASN.1 kế thừa hiện có nào được ghi lại ở định dạng này mà không thay đổi cấu trúc bên dưới

E.4.9  Miền giá trị

Không có định nghĩa miền giá trị rõ ràng trong mô-đun TCVN 13910-1: 2024-E-Data-1.

Thư mục tài liệu tham khảo

1. ISO14817-1:2015 "Intelligent transport systems - ITS central data dictionaries - Part 1: Requirements for ITS data definitions”