Tiêu chuẩn TCVN 13600-1:2022 Hệ thống giám sát và thông tin giao thông

TIÊU CHUẨN QUỐC GIA

TCVN 13600-1:2022

ISO 14827-1:2005

HỆ THỐNG GIÁM SÁT VÀ THÔNG TIN GIAO THÔNG - GIAO DIỆN DỮ LIỆU GIỮA CÁC TRUNG TÂM PHỤC VỤ HỆ THỐNG GIÁM SÁT VÀ THÔNG TIN GIAO THÔNG - PHẦN 1: CÁC YÊU CẦU ĐỊNH NGHĨA THÔNG ĐIỆP

Transport information and control systems - Data interfaces between centres for transport information and control systems - Part 1: Message definition requirements

Lời nói đầu

TCVN 13600-1:2022 hoàn toàn tương đương với ISO 14827- 1:2005 “Transport information and control systems - Data interfaces between centres for transport information and control systems - Part 1: Message definition requirements” của Tổ chức tiêu chuẩn hóa quốc tế ISO.

TCVN 13600-1:2022 do Bộ Giao thông Vận tải biên soạn và đề 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ố.

HỆ THỐNG GIÁM SÁT VÀ THÔNG TIN GIAO THÔNG - GIAO DIỆN DỮ LIỆU GIỮA CÁC TRUNG TÂM PHỤC VỤ HỆ THỐNG GIÁM SÁT VÀ THÔNG TIN GIAO THÔNG - PHẦN 1: CÁC YÊU CẦU ĐỊNH NGHĨA THÔNG ĐIỆP

Transport information and control systems - Data interfaces between centres for transport information and control systems - Part 1: Message definition requirements

1  Phạm vi áp dụng

Tiêu chuẩn này xác định định dạng cần được sử dụng để mô tả các thông điệp ứng dụng cuối, được trao đổi giữa hai và nhiều hệ thống trung tâm. Định dạng là độc lập về giao thức với thực tế quy mô. Ví dụ, một định dạng này có thể được sử dụng để định nghĩa các trao đổi dữ liệu có thể áp dụng cho DATEX-ASN, CORBA hoặc các giao thức ứng dụng khác.

Tổng quát, mỗi hệ thống có thể được xem như bao gồm các giao diện được mô tả ở Hình 1.

CHÚ DẪN

1. Giao diện ứng dụng

2. Giao diện vận hành

3. Giao diện truyền thông

4. Giao diện cơ sở dữ liệu

5. Đám mây truyền thông

6. Hệ thống máy khách

7. Hệ thống máy chủ

CHÚ THÍCH: Đám mây truyền thông giữa các hệ thống có thể phức tạp hoặc đơn giản.

Hình 1 - Giao diện hệ thống

Tiêu chuẩn này chỉ đề cập đến giao diện truyền thông và ở mức rất cao. Các tiêu chuẩn khác định nghĩa cách thức các thông điệp ứng dụng cuối có thể được trao đổi sử dụng các giao thức tầng ứng dụng khác nhau.

Trong khi tiêu chuẩn này được xây dựng đáp ứng các yêu cầu xác định của môi trường TICS, tiêu chuẩn được xây dựng theo phương thức tổng quát và do đó cũng có thể được sử dụng cho các trao đổi dữ liệu khác.

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

Các tài liệu viện dẫn sau 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 9696-4:2013 (ISO/IEC 7498-4:1989) - Công nghệ thông tin - Liên Kết Hệ Thống Mở - Mô Hình Tham Chiếu Cơ Sở - Phần 4: Khung Tổng Quát về Quản Lý.

TCVN ISO 9735-1:2003 (ISO 9735-1:2002) - Trao đổi dữ liệu điện tử trong quản lý hành chính, thương mại và vận tải (EDIFACT) - Các quy tắc cú pháp mức ứng dụng (Số hiệu phiên bản cú pháp: 4, số hiệu phát hành cú pháp: 1) - Phần 1: Quy tắc cú pháp chung.

ISO/IEC 8824-1, Information technology ‒ Abstract Syntax Notation One (ASN.1) ‒ Specification of basic notation (Công nghệ thông tin ‒ Cú pháp trừu tượng ký hiệu một (ASN.1) - Đặc tả ký hiệu cơ bản).

ISO/IEC 8824-2, Information technology ‒ Abstract Syntax Notation One (ASN.1) ‒ Information object specification (Công nghệ thông tin - Cú pháp trừu tượng ký hiệu một (ASN.1) - Đặc tả đối tượng thông tin).

ISO/IEC 8825-1, Information technology ‒ ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) (Công nghệ thông tin - Các quy tắc mã hóa ASN.1: Đặc tả các quy tắc mã hóa cơ bản (BER), các quy tắc mã hóa chuẩn (CER) và các quy tắc mã hóa phân biệt (DER)).

ISO/IEC 8825-2, Information Technology ‒ ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) (Công nghệ thông tin - Các quy tắc mã hóa ASN.1: Đặc tả các quy tắc mã hóa gói (PER)).

3  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 sau:

3.1

Tầng ứng dụng (application layer)

Tầng trên cùng của mô hình bảy tầng OSI được định nghĩa trong TCVN 9696-4:2013 (ISO/IEC 7498- 4:1989).

CHÚ THÍCH: Tầng này định nghĩa cấu trúc và định dạng của nội dung gói dữ liệu cùng với các quy tắc và các thủ tục để trao đổi các gói dữ liệu.

3.2

Trung tâm (center)

Máy tính hoặc mạng đáp ứng các yêu cầu của một giao diện truyền thông tiêu chuẩn trên một mạng truyền thông điểm cố định, bất kể nó chỉ là hệ thống trong tòa nhà hoặc chỉ là một trong nhiều hệ thống, hoặc thậm chí nỏ được đặt ở vị trí từ xa.

CHÚ THÍCH: Tiêu chuẩn này đề cập đến truyền thông giữa các trung tâm.

3.3

Máy khách (client)

Máy tính hoặc ứng dụng yêu cầu và tiếp nhận dữ liệu từ máy chủ hoặc ứng dụng sử dụng một số loại giao thức.

3.4

Lệnh (command)

Gói dữ liệu được chuẩn bị bởi một hệ thống để điều khiển một số chức năng của hệ thống khác.

CHÚ THÍCH: Các lệnh có thể được vận chuyển như là một đăng ký (yêu cầu) hoặc xuất bản (phúc đáp) phụ thuộc vào thiết kế của trao đổi dữ liệu cụ thể.

3.5

Gói dữ liệu (data packet)

Thực thể dữ liệu có thể được gửi giữa các hệ thống ứng dụng cuối để trao đổi thông tin.

CHÚ THÍCH: Một gói dữ liệu liên quan đến Tầng ứng dụng của mô hình OSI và có thể phân tách thành một số phần bởi các giao thức tầng thấp hơn.

3.6

Thông điệp ứng dụng cuối (end application message)

Cấu trúc dữ liệu thông điệp được kết hợp với nghĩa xác định và khi được gửi chính xác trong gói dữ liệu, một trường hợp của cấu trúc có thể vận chuyển thông tin giữa các hệ thống.

CHÚ THÍCH: Một cấu trúc dữ liệu có thể, ví dụ, được xác định bao gồm danh sách các tốc độ từ các trạm dò xe. cấu trúc dữ liệu này có thể được sử dụng để xác định nội dung của một số thông điệp (ví dụ danh sách các tốc độ hiện tại được phát hiện, danh sách các tốc độ đã lưu trữ sẽ kích hoạt cảnh bảo tắc nghẽn nếu các giá trị hiện tại thấp hơn mức được chỉ thị hoặc yêu cầu một danh sách các vị trí mà tốc độ hiện tại thấp hơn tốc độ được chỉ thị). Một trường hợp của thông điệp sau đó sẽ bao gồm các giá trị thực.

3.7

Trường hợp thông điệp (message instance)

Trường hợp xác định của một thông điệp ứng dụng cuối.

3.8

Đặc tả thông điệp (message specification)

Tài liệu định nghĩa nghĩa của thông điệp, kết quả của việc áp dụng tiêu chuẩn này cho một thông điệp xác định.

3.9

Hồ sơ (profile)

Tiêu chuẩn định nghĩa các quy tắc chỉ bằng cách kết hợp các yêu cầu của tiêu chuẩn khác.

VÍ DỤ: Một hồ sơ ứng dụng là hồ sơ đặc tả các tầng ứng dụng, trình diễn và phiên bằng cách tham chiếu một nhóm các tiêu chuẩn khác.

3.10

Giao thức (protocol)

Tập các quy tắc chính thức mô tả phương thức truyền dữ liệu, đặc biệt qua một mạng.

3.11

Xuất bản (publication)

Dữ liệu phúc đáp được chuẩn bị bởi một máy chủ, thường để đáp ứng tới một đăng ký.

CHÚ THÍCH: Trong một số trường hợp, một xuất bản có thể được gọi là một “phúc đáp” hoặc một “đáp ứng”.

3.12

Máy chủ (server)

Máy tính hoặc ứng dụng thu nhận và phản hồi yêu cầu dữ liệu từ máy khách hoặc ứng dụng sử dụng một số loại giao thức.

3.13

Đăng ký (subscription)

Gói dữ liệu yêu cầu được chuẩn bị bởi máy khách để yêu cầu xuất bản (các xuất bản) hiện tại hoặc tương lai.

CHÚ THÍCH: Trong một số trường hợp, một đăng ký có thể được gọi là một “yêu cầu”.

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

5  Các yêu cầu

Tiêu chuẩn này cung cấp một định dạng tiêu chuẩn có thể được sử dụng để định nghĩa các thông điệp ứng dụng cuối cho nhiều giao thức ứng dụng; mỗi giao thức ứng dụng có tập các dịch vụ duy nhất của chính mình. Để cung cấp định nghĩa thực tế các thông điệp, một số giả thiết được thực hiện về các dịch vụ được cung cấp bởi các tầng thấp hơn của kiến trúc giao thức và toàn bộ các khái niệm thiết kế. Các giả thiết này được mô tả trong mục này.

CHÚ THÍCH: Không có mục nào trong tiêu chuẩn này loại bỏ trách nhiệm của tổ chức đảm bảo rằng thông điệp không vi phạm nghĩa vụ pháp lý đặt ra cho chúng bởi các điều luật của quốc gia tương ứng.

5.1  Trao đổi dữ liệu hai chiều

Tiêu chuẩn này giả thiết rằng giao thức cung cấp phương thức truyền thông yêu cầu-phúc đáp, trong đó phúc đáp có thể ở định dạng khác so với yêu cầu. Hơn nữa, một số giao thức cho phép một chuỗi các phúc đáp tới một yêu cầu đơn; do đó, nó cũng được thiết kế cho phép tác vụ này. Giả thiết rằng các yêu cầu được gửi đi tự nguyện và các phúc đáp hầu hết luôn không tự nguyện. Giả thiết rằng chỉ có một loại phúc đáp khởi đầu có thể thu được đối với một yêu cầu xác định, và chỉ một loại phúc đáp kế tiếp cho các yêu cầu cho phép nhiều phúc đáp.

Nếu hệ thống muốn gửi một chú ý không được yêu cầu, mà không cần thiết một phúc đáp (khác so với phân phát được đảm bảo), nó cần được đặc tả như một xuất bản.

5.2  Định nghĩa mức cao

Tiêu chuẩn này chỉ cung cấp định nghĩa các thông điệp ở mức cao. Các giao thức khác nhau sẽ thực hiện trao đổi này theo các phương thức khác nhau. Các quy tắc thực hiện các thông điệp này trong một giao thức xác định sẽ hoặc là được định nghĩa trong tài liệu giao thức hoặc là ở hồ sơ ứng dụng. Một hồ sơ ứng dụng cuối cũng có thể được yêu cầu để mô tả các quy tắc xác định không mơ hồ đối với một thông điệp xác định.

Ví dụ, một phúc đáp có thể diễn ra nhiều lần có thể được ánh xạ tới một gói dữ liệu xuất bản ở dạng DATEX-ASN, trong khi nó có thể được ánh xạ tới một phương pháp gọi trong CORBA.

5.3  Các định nghĩa xác định chức năng kỳ vọng

Trong ngữ cảnh của tiêu chuẩn này, một thông điệp ngụ ý một mức chức năng bên trong một hệ thống. Chức năng chính xác được yêu cầu bởi một thông điệp xác định sẽ được mô tả tài liệu ở thuộc tính định nghĩa.

Ví dụ, nếu hệ thống A yêu cầu một hành trình chuyến đi từ điểm X tới điểm Z, hệ thống B cần đáp ứng với dữ liệu được yêu cầu (hoặc giá trị lỗi phù hợp). Do đó, một trong những yêu cầu chức năng đặt ra cho hệ thống B là phải đáp ứng với dữ liệu được yêu cầu (giả thiết một danh sách các tuyến luân phiên). Các yêu cầu khác cũng có thể được đặt ra (ví dụ có nên xem xét chế độ vận chuyển bất kỳ khác không). Tiêu chuẩn này định nghĩa chức năng như vậy bằng cách kết hợp một xuất bản với mỗi yêu cầu, các thông điệp xác định cần chỉ thị các ngữ nghĩa bổ sung (ví dụ các chế độ vận chuyển hợp lệ) phù hợp.

5.4  Định thời và các vấn đề khác

Tiêu chuẩn này không giải quyết các vấn đề định thời; tuy nhiên, các bên thực hiện cần chú ý rằng nhiều thông điệp yêu cầu các mức chất lượng xác định mà một số giao thức không thể đáp ứng.

5.5  Các thuộc tính bổ sung

Tiêu chuẩn này định nghĩa các thuộc tính được yêu cầu để đảm bảo sự trao đổi dữ liệu rõ ràng trong khi vẫn sử dụng giao thức tương đối tổng quát. Các thuộc tính này cần được định nghĩa cho mỗi thông điệp như được chỉ thị. Các thuộc tính khác có thể được mô tả tài liệu, nếu được yêu cầu.

Ví dụ, tiêu chuẩn ISO 14817-3 định nghĩa một sơ đồ phân loại để quản lý các danh sách thông điệp, bên cạnh các thuộc tính khác. Các tiêu chuẩn khác có thể định nghĩa các thuộc tính được yêu cầu để ánh xạ thông điệp tới một giao thức xác định. Một thông điệp tuân thủ tiêu chuẩn này cũng có thể bao gồm bất kỳ thuộc tính như vậy, cùng với các thuộc tính yêu cầu được định nghĩa trong tiêu chuẩn này cũng được cung cấp.

6  Các yêu cầu định nghĩa thông điệp

Một thông điệp ứng dụng cuối tuân thủ tiêu chuẩn này sẽ được định nghĩa chính thức với các thuộc tính được định nghĩa trong các mục con sau đây. Phụ lục A cung cấp đặc tả đối tượng thông tin ASN.1 chính thức được sử dụng để mô tả tài liệu các thuộc tính này.

6.1  Tên

Mỗi thông điệp sẽ được gán một tên mô tả, duy nhất. Tên này có thể được sử dụng bởi một số giao thức cho các mục đích định danh.

6.2  Định nghĩa

Mỗi thông điệp sẽ được gán một định nghĩa dạng văn bản, chính thức. Định nghĩa văn bản có thể tham chiếu các hình vẽ và thông tin khác phù hợp. Định nghĩa sẽ cung cấp một mô tả có nghĩa về thông điệp và chỉ thị rõ ràng chức năng được yêu cầu bởi hệ thống cuối.

6.3  Các nhận xét

Đặc tả thông điệp cũng có thể bao gồm các nhận xét bổ sung. Các nhận xét như vậy không cần được xem xét chuẩn hóa, nhưng có thể được viết để cung cấp sự hiểu tốt hơn về thông điệp hoặc để cung cấp thông tin bổ sung cho người đọc

6.4  Phần chính của thông điệp

Phần chính của thông điệp sẽ được định nghĩa toàn diện trong phần này, như là kiểu ASN.1 sử dụng cú pháp được định nghĩa trong ISO/IEC 8824-1.

CHÚ THÍCH: Điều này cho phép phương pháp chặt chẽ trong việc mô tả tài liệu dữ liệu; không ngụ ý việc sử dụng các quy tắc mã hóa ASN.1. Một giao thức có thể chọn quy tắc vả thủ tục mã hóa ASN.1 bất kỳ (ví dụ được định nghĩa đối với EDIFACT và CORBA).

6.5  Kiểu thông điệp

Kiểu thông điệp sẽ được chỉ thị nếu thông điệp định nghĩa một cấu trúc thông điệp xuất bản hoặc đăng ký. Các đặc tả thông điệp đăng ký sẽ bao gồm các thuộc tính “loại-đăng ký”, “xuất bản ban đầu” và “các xuất bản kế tiếp”. Các đặc tả thông điệp xuất bản sẽ không bao gồm các thuộc tính này.

6.6  Kiểu đăng ký

Kiểu đăng ký phải được bao gồm trong đặc tả thông điệp nếu kiểu thông điệp là “đăng ký”. Thuộc tính này chỉ ra các phương thức mà thông điệp có thể được sử dụng, như sau;

- Đơn: Một trường hợp của thông điệp này sẽ chỉ hợp lệ khi yêu cầu là cho một đáp ứng đơn. Đáp ứng sẽ được chỉ thị bằng thuộc tính “xuất bản ban đầu”.

- Phụ thuộc sự kiện: Một trường hợp của thông điệp này sẽ chỉ hợp lệ khi yêu cầu là cho thông báo phụ thuộc sự kiện. Dựa trên sự thu được, một trường hợp của “xuất bản ban đầu” sẽ được gửi, và khi sự kiện được định nghĩa được phát hiện, một trường hợp của “các xuất bản kế tiếp” sẽ được gửi. Sự kiện sẽ được định nghĩa trong thuộc tính định nghĩa.

- Định kỳ: Một trường hợp của thông điệp này sẽ chỉ hợp lệ khi yêu cầu là cho các cập nhật định kỳ. Dựa trên sự thu được, bên thu sẽ gửi một trường hợp của “xuất bản ban đầu” và máy chủ sẽ gửi định kỳ các cập nhật “các xuất bản kế tiếp” theo các quy tắc của giao thức xác định.

- Đơn hoặc sự kiện: Một trường hợp của thông điệp này sẽ chỉ hợp lệ nếu yêu cầu là cho đáp ứng đơn hoặc nếu yêu cầu là cho đáp ứng phụ thuộc sự kiện; một trường hợp của thông điệp này sẽ không thể được gửi như là một yêu cầu định kỳ. Phương thức (hoặc là đơn hoặc là sự kiện) sẽ được chỉ thị rõ ràng trong trường hợp thông điệp. Tác vụ của hệ thống thu nhận sẽ phù hợp với phương thức của trường hợp thông điệp.

- Đơn hoặc định kỳ: Một trường hợp của thông điệp này sẽ chỉ hợp lệ nếu yêu cầu là cho đáp ứng đơn hoặc nếu yêu cầu là cho đáp ứng định kỳ; một trường hợp của thông điệp này sẽ không thể được gửi như là một yêu cầu phụ thuộc sự kiện. Phương thức (hoặc là đơn hoặc là định kỳ) sẽ được chỉ thị rõ ràng trong trường hợp thông điệp. Tác vụ của hệ thống thu nhận sẽ phù hợp với phương thức của trường hợp thông điệp.

- Sự kiện hoặc định kỳ: Một trường hợp của thông điệp này sẽ chỉ hợp lệ nếu yêu cầu là cho đáp ứng phụ thuộc sự kiện hoặc đáp ứng định kỳ; một trường hợp của thông điệp này sẽ không thể được gửi để yêu cầu một đáp ứng đơn. Phương thức (hoặc là sự kiện hoặc là định kỳ) sẽ được chỉ thị rõ ràng trong trường hợp thông điệp. Tác vụ của hệ thống thu nhận sẽ phù hợp với phương thức của trường hợp thông điệp.

- Đơn, sự kiện, định kỳ: Một trường hợp của thông điệp này có thể yêu cầu một đáp ứng đơn, một đáp ứng phụ thuộc sự kiện hoặc một đáp ứng định kỳ. Phương thức (hoặc là đơn, sự kiện hoặc định kỳ) sẽ được chỉ thị rõ ràng trong trường hợp thông điệp. Tác vụ của hệ thống thu nhận sẽ phù hợp với phương thức của trường hợp thông điệp.

6.7  Xuất bản ban đầu

Thuộc tính xuất bản ban đầu sẽ chỉ được bao gồm trong đặc tả của các thông điệp đăng ký. Nó sẽ định nghĩa thông điệp được phát dựa trên việc thu nhận sự đăng ký kết hợp.

6.8  Các xuất bản kế tiếp

Thuộc tính các xuất bản kế tiếp sẽ chỉ được bao gồm trong đặc tả các thông điệp đăng ký không phải là kiểu thông điệp “đơn”. Nó sẽ định nghĩa thông điệp xuất bản được phát cho tất cả các thông điệp kế tiếp sau xuất bản ban đầu.

6.9  Id

Mỗi thông điệp sẽ được gán một định danh đối tượng ASN.1, duy nhất toàn cầu trong trường Id. Một số giao thức có thể sử dụng định danh này để mô tả kiểu thông điệp, không chỉ là tên thông điệp.

Phụ lục A

(Quy định)

Đặc tả đối tượng thông tin

A.1  Tổng quát

Phụ lục B

(Tham khảo)

Các ví dụ

B.1  Danh sách ứng viên yêu cầu

Một thông điệp đơn giản có thể không bao gồm bất kỳ dữ liệu nào. Ví dụ, một thông điệp yêu cầu danh sách các ứng viên không cần bao gồm thông tin bất kỳ nào khác ngoài định danh.

B.2  Yêu cầu các ứng viên bởi chủ đề

Một yêu cầu phức tạp hơn có thể bao gồm tham số để mô tả loại ứng viên mà thông tin đang được yêu cầu. Trong trường hợp này, phần chính của thông điệp sẽ định nghĩa cấu trúc dữ liệu được sử dụng để chỉ thị loại ứng viên.

B.3  Phúc đáp danh sách ứng viên

Mặc dù đăng ký phải chỉ thị chính xác cách thức xuất bản được cho phép, xuất bản tương tự có thể được sử dụng để đáp ứng tới nhiều đăng ký. Ví dụ, xuất bản sau đây được xác định trước đó cho mỗi một trong các thông điệp trên. Ví dụ này cũng chỉ thị rằng phần chính của thông điệp có thể được định nghĩa trong đặc tả thông điệp, bên cạnh là một tham chiếu được sử dụng trong ví dụ trên.

B.4  Yêu cầu các cập nhật ứng viên

Ví dụ cuối cùng sau chỉ thị cách thức một thông điệp có thể được định nghĩa để không chỉ yêu cầu danh sách ban đầu các ứng viên, mà cũng yêu cầu các cập nhật khi các ứng viên mới được thuê.

Phụ lục C

(Tham khảo)

Khái niệm phương thức hoạt động

Tiêu chuẩn này cung cấp một cơ chế để đặc tả các thông điệp ở mức trừu tượng. Việc thực hiện thực sự các thông điệp này sẽ được định nghĩa bởi các tiêu chuẩn khác.

Ví dụ, tiêu chuẩn TCVN 13600-2 (DATEX-ASN) định nghĩa một phương thức để trao đổi các thông điệp này. Trong giao thức này, một đăng ký sẽ được gửi qua giao diện bên trong gói dữ liệu đăng ký DATEX-ASN. Tuy nhiên, các tiêu chuẩn khác có thể định nghĩa phương thức trao đổi dữ liệu này thông qua giao diện CORBA.Tiêu chuẩn như vậy có thể đặt mỗi đăng ký với một phương pháp và mỗi xuất bản với đáp ứng tới phương pháp.

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

[1]. ISO 14827-2:2005, Transport information and control systems - Data interfaces between centres for transport information and control systems - Part 2: DATEX-ASN (Hệ thống giám sát và thông tin giao thông - Giao diện dữ liệu giữa các trung tâm phục vụ hệ thống giám sát và thông tin giao thông - Phần 2: DATEX-ASN).

[2]. ISO 14827-3:2019, Transport Information and control systems - Data interfaces between centres for transport information and control systems - Part 3: Data interfaces between centres for intelligent transport sytems (ITS) using XML (Profile A) (Hệ thống giám sát và thông tin giao thông - Giao diện dữ liệu giữa các trung tâm phục vụ hệ thống giám sát và thông tin giao thông - Phần 3: Giao diện dữ liệu giữa các trung tâm phục vụ hệ thống giao thông thông minh (ITS) sử dụng XML (Hồ sơ A)).

Mục lục

Lời nói đầu

1  Phạm vi áp dụng

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

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

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

5  Các yêu cầu

5.1  Trao đổi dữ liệu hai chiều

5.2  Định nghĩa mức cao

5.3  Các định nghĩa xác định chức năng kỳ vọng

5.4  Định thời và các vấn đề khác

5.5  Các thuộc tính bổ sung

6  Các yêu cầu định nghĩa thông điệp

6.1  Tên

6.2  Định nghĩa

6.3  Các nhận xét

6.4  Phần chính của thông điệp

6.5  Kiểu thông điệp

6.6  Kiểu đăng ký

6.7  Xuất bản ban đầu

6.8  Các xuất bản kế tiếp

6.9  Id

Phụ lục A (Quy định) - Đặc tả đối tượng thông tin

Phụ lục B (Tham khảo) - Các ví dụ

Phụ lục C (Tham khảo) - Khái niệm phương thức hoạt động

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