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

TIÊU CHUẨN QUỐC GIA

TCVN 13600-2:2022

ISO 14827-2: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 2: DATEX-ASN

Transport information and control systems - Data interfaces between centres for transport information and control systems - Part 2: DATEX-ASN

Lời nói đầu

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

TCVN 13600-2: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 2: DATEX-ASN

Transport information and control systems - Data interfaces between centres for transport information and control systems - Part 2: DATEX-ASN

1  Phạm vi áp dụng

DATEX-ASN cho phép các hệ thống khác nhau trao đổi dữ liệu liên quan. Dữ liệu được bao gồm trong các thông điệp ứng dụng cuối. Mỗi thông điệp này được xác định là “đăng ký” hoặc “xuất bản” theo định dạng được mô tả trong TCVN 13600-1:2022. DATEX-ASN định nghĩa phương thức các thông điệp ứng dụng cuối này được đóng gói để tạo thành gói dữ liệu toàn diện và cũng định nghĩa các quy tắc và các thủ tục để trao đổi các gói dữ liệu này. Các hệ thống sử dụng DATEX-ASN là độc lập thực hiện các chức năng ứng dụng cuối bổ sung theo các yêu cầu người sử dụng.

Mạng DATEX-ASN gồm một số lượng các hệ thống nhất định. Hình 1 cung cấp ví dụ về mạng DATEX-ASN.

CHÚ DẪN

1. Hệ thống thời tiết

2. Hệ thống quản lý điều hành giao thông

3. Hệ thống quản lý chuyển tiếp

4. Hệ thống quản lý khản cấp

5. Nhà cung cấp dịch vụ thông tin

Hình 1 - Ví dụ một mạng DATEX-ASN

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

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ủ

Hình 2 - Các giao diện hệ thống

Tiêu chuẩn này chỉ đề cập đến giao diện truyền thông. Tiêu chuẩn này có mục tiêu đáp ứng các yêu cầu duy nhất của TICS, tiêu chuẩn được xây dựng một cách tổng quát và do đó cũng có thể được sử dụng cho các trao đổi dữ liệu khác.

Các hệ thống thực hiện tiêu chuẩn này đôi khi hoạt động đồng thời như là máy khách và máy chủ, sử dụng nhiều phiên. Đám mây truyền thông giữa hai hệ thống có thể phức tạp hoặc đơn giản.

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 6558:2008 (ISO 4217:2001) - Mã thể hiện các đồng tiền và quỹ.

TCVN 13600-1:2022 - 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.

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

ISO 8825-2, Information technology ‒ ASN.1 encoding rules ‒ Part 2: 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

Hồ sơ truyền tải không kết nối (connectionless transport profile)

Dịch vụ cung cấp truyền thông từ hệ thống cuối tới hệ thống cuối mà không yêu cầu thiết lập kết nối bất kỳ.

VÍ DỤ: UDP/IP.

3.2

Hồ sơ truyền tải định hướng kết nối (connection-oriented transport profile)

Dịch vụ cho phép một hệ thống cuối trao đổi một luồng dữ liệu liên tục với hệ thống cuối khác, dữ liệu được đảm bảo được phân phát theo cùng thứ tự mà nó được gửi mà không gây lặp đúp.

CHÚ THÍCH: Dịch vụ này thường đạt được trước tiên bằng cách thiết lập một kết nối, sau đó gửi dữ liệu, và cuối cùng ngắt kết nối.

VÍ DỤ: TCP/IP.

3.3

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

Biểu diễn chính thức cú pháp của một số đơn vị thông tin quan tâm duy nhất (ví dụ một thực tế, tuyên bố, quan sát,...) về một số (thực thể) lớp quan tâm (ví dụ một người, địa điểm, quá trình, đặc tính, khái niệm, kết hợp, trạng thái, sự kiện,...).

3.4

Gói dữ liệu (datagram)

Thực thể dữ liệu bao gồm đầy đủ thông tin được định tuyến từ nguồn tới đích mà không dựa vào cấu hình mạng trước đó.

Ví dụ: Gói dữ liệu IP.

3.5

Xuất bản gói dữ liệu (datagram publication)

Xuất bản DATEX-ASN (phúc đáp) được gửi trực tiếp qua hồ sơ truyền tải xác định, ngược lại với một xuất bản tệp.

3.6

Đích (destination)

Hệ thống hoặc thiết bị mà thông tin trong gói dữ liệu định gửi.

3.7

Các quy tắc mã hóa (encoding rules)

Các quy tắc mô tả việc biểu diễn trong suốt quá trình truyền tải các giá trị của các kiểu ASN.1.

CHÚ THÍCH 1: Các quy tắc mã hóa cũng cho phép các giá trị được khôi phục từ biểu diễn, với hiểu biết về kiểu.

CHÚ THÍCH 2: Đối với mục đích mô tả các quy tắc mã hóa, các ký hiệu kiểu tham chiếu khác nhau (và giá trị), có thể cung cấp các ký hiệu luân phiên cho các kiểu được xây dựng (và các giá trị), là không phù hợp.

3.8

Ethernet

Kết hợp cụ thể các giao thức tầng vật lý và tầng liên kết dữ liệu được định nghĩa trong IEEE 802.3, cho phép nhiều hệ thống nhận được truy nhập tới một môi trường được chia sẻ và truyền thông với nhau.

3.9

Tệp (file)

Đối tượng lưu trữ dữ liệu, có thể được đặt ở hệ thống tệp bất kỳ như đĩa cứng, đĩa mềm, bộ nhớ RAM,..

3.10

Xuất bản tệp (file publication)

Xuất bản DATEX-ASN (phúc đáp) được lưu trữ trên hệ thống tệp của máy chủ cho đến khi máy khách có cơ hội để nhận được nó qua giao thức truyền tải tệp, ngược lại với xuất bản gói dữ liệu.

3.11

Phân phát được đảm bảo (guaranteed delivery)

Cơ chế DATEX-ASN trong đó máy khách xác nhận việc thu được một xuất bản (phúc đáp).

3.12

Nhịp giám sát (heartbeat)

Gói dữ liệu được gửi để chỉ thị rằng hệ thống gửi vẫn tồn tại và đang truyền thông.

3.13

Thời gian quay vòng cực đại (maximum turn-around time)

Lượng thời gian cực đại mà một hệ thống cung cấp một đáp ứng phù hợp tới gói dữ liệu tới.

3.14

Nguồn gốc (origin)

Hệ thống hoặc thiết bị là nguồn cho tất cả thông tin trong gói dữ liệu.

CHÚ THÍCH: Trong nhiều trường hợp, điều này tương tự như bên gửi, nhưng có thể khác nhau. Ví dụ, một cầu (hoặc tác nhân proxy) có thể biên dịch giữa các giao thức; trong trường hợp này cầu (hoặc tác nhân proxy) có thể là bên gửi, trong khi hệ thống tạo ra dữ liệu sẽ là nguồn gốc.

3.15

Cổng (port)

Kênh logic trong một hệ thống truyền thông.

CHÚ THÍCH: UDP và TCP sử dụng các số cổng để ghép kênh các gói dữ liệu từ nhiều ứng dụng vào một hệ thống truyền thông đơn.

3.16

Chu kỳ quá hạn đáp ứng (response time-out period)

Khoảng cực đại mà một hệ thống được yêu cầu để đợi gói dữ liệu đáp ứng trước khi giả thiết rằng gói dữ liệu đã được gửi trước đó chưa bao giờ thu được bởi ứng dụng khác.

3.17

Bên gửi (sender)

Hệ thống tạo ra và gửi gói dữ liệu DATEX-ASN.

3.18

Phiên (session)

Khoảng thời gian trong đó một máy khách và một máy chủ trao đổi nhiều gói dữ liệu.

3.19

Bỏ qua lặng lẽ (silently drop)

Bỏ qua một gói dữ liệu.

CHÚ THÍCH: Một gói dữ liệu bị bỏ qua lặng lẽ không gây ra bất kỳ tác vụ nào xảy ra trong hệ thống thu nhận hoặc đáp ứng bất kỳ được gửi tới gói dữ liệu mục tiêu.

3.20

Hồ sơ truyền tải (transport profile)

Tập các dịch vụ chịu trách nhiệm cung cấp kết nối điểm tới điểm hầu như không lỗi, do đó máy chủ A có gửi các gói dữ liệu tới máy chủ B và các gói sẽ đến không bị ngắt quãng.

CHÚ THÍCH: Các hồ sơ truyền tải kết nối định hướng cũng có thể đảm bảo rằng các gói dữ liệu đến theo đúng thứ tự.

3.21

Thời gian quay vòng (turn-around time)

Khoảng thời gian mà một máy khách hoặc một máy chủ tiến hành và phát một gói dữ liệu đáp ứng, được tính bắt đầu từ điểm mà ở đó byte dữ liệu cuối cùng thu được từ hệ thống khác tới điểm khi byte đáp ứng cuối cùng được phát.

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

5  Các xem xét thực hiện

Trước khi trao đổi dữ liệu, các trung tâm điều hành giao thông phải thống nhất các vấn đề xác định được mô tả trong danh sách dưới đây.

CHÚ THÍCH: Một số trong các vấn đề này (ví dụ các giao thức tầng thấp hơn) có thể được đặc tả ở một số mục. Ví dụ, Phụ lục D cung cấp một định nghĩa về các tình trạng này cho các thực hiện IP chuẩn hóa.

a) Tổng quát:

1) Khoảng thời gian mà qua đó toàn bộ thỏa thuận là hợp lệ;

2) Các quy tắc kết thúc thỏa thuận trước thời gian thỏa thuận quá hạn;

3) Các tên miền máy chủ và máy khách và các chi tiết về các địa chỉ liên lạc không trực tuyến, điện thoại, fax và thư điện tử.

b) Truy nhập (DATEX-ASN yêu cầu một tên người sử dụng và mật khẩu kết hợp):

1) Địa chỉ IP của máy khách, được gán bởi tổ chức đánh số gán Internet nếu liên kết sử dụng một mạng công cộng;

2) Địa chỉ IP của máy chủ, được gán bởi tổ chức đánh số gán Internet nếu liên kết sử dụng một mạng công cộng;

3) Danh sách tên người sử dụng máy khách có thẩm quyền, được tham chiếu như là tên người sử dụng được sử dụng thông qua tiêu chuẩn này;

4) Một mật khẩu được kết hợp với mỗi tên người sử dụng máy khách.

c) Các giao thức:

1) Lựa chọn các giao thức tầng thấp hơn, bao gồm:

i) Các tầng trình diễn (ví dụ BER, EDIFACT, hoặc khác) và tầng phiên;

ii) Các tầng truyền tải và mạng (ví dụ UDP/IP, TCP/IP,...);

iii) Các tầng liên kết dữ liệu và vật lý (ví dụ Ethernet, FDDI, PPP qua ISDN).

2) Kích thước gói dữ liệu cực đại;

3) Lựa chọn các giao thức truyền tải tệp ưa thích.

d) Quản lý thông tin cơ bản:

1) Đặc tả đăng ký dữ liệu được sử dụng.

e) Quản lý thông điệp:

1) Các thông điệp phải được hỗ trợ, có thể bao gồm các thông điệp được tiêu chuẩn hóa trong các tài liệu khác và/hoặc các thông điệp duy nhất với sự thực hiện cụ thể.

6  Các thủ tục trao đổi dữ liệu

Tiêu chuẩn này định nghĩa một giao thức tầng ứng dụng mà nhờ đó các phần tử dữ liệu được trao đổi giữa một máy khách và máy chủ. Truyền thông giữa máy khách và máy chủ sẽ được hoàn thành bằng cách trao đổi các gói dữ liệu và các tệp như được định nghĩa trong phần này.

6.1  Các thủ tục gói dữ liệu tổng quát

Các gói dữ liệu DATEX-ASN sẽ được xây dựng theo các cấu trúc dữ liệu ASN.1 được định nghĩa chính thức được định nghĩa ở Phụ lục A.

6.1.1  Các phiên

Tiêu chuẩn này yêu cầu tất cả các gói dữ liệu được phát trong một phiên ứng dụng. Trong mỗi phiên, một hệ thống sẽ đóng vai trò như là một máy khách và hệ thống khác sẽ đóng vai trò máy chủ.

CHÚ THÍCH: Nhiều phiên có thể tồn tại đồng thời. Do đó, một cặp hệ thống có thể có hai phiên đồng thời, một phiên trong đó hệ thống A đóng vai trò là máy khách và hệ thống B đóng vai trò là máy chủ và một phiên trong đó hệ thống A đóng vai trò là máy chủ và hệ thống B đóng vai trò là máy khách. Các phiên này sẽ được phân biệt bởi các giao thức tầng thấp hơn (ví dụ TCP hoặc các số cổng UDP).

6.1.2  Các yêu cầu truyền tải

Dữ liệu có thể được trao đổi qua các hồ sơ truyền tải kết nối định hướng hoặc không kết nối, nhưng một hồ sơ truyền tải duy nhất sẽ được sử dụng cho tất cả các gói dữ liệu được trao đổi trong một phiên.

VÍ DỤ: Nếu gói dữ liệu đầu tiên trong thiết lập một phiên được phát sử dụng UDP, thì tất cả các gói dữ liệu trong phiên đó sẽ sử dụng UDP. Cũng giống như thế, nếu truyền dẫn khởi đầu là TCP, thì tất cả các gói dữ liệu sẽ là TCP.

6.1.3  Quá hạn đáp ứng

Máy khách và máy chủ sẽ thỏa thuận về khoảng quá hạn đáp ứng cho mỗi phiên. Khoảng quá hạn đáp ứng phải đủ dài để bao gồm các trễ truyền dẫn mạng cho cả các gói dữ liệu cũng như thời gian quay vòng được yêu cầu để điều khiển thông điệp ở đầu cuối thu. Về lý thuyết, khoảng này cần được tính từ khi byte cuối cùng được phát tới khi byte đáp ứng cuối cùng được thu; tuy nhiên, kỳ vọng rằng hầu hết các thực hiện sẽ tính thời gian từ thời điểm quay về từ yêu cầu viết hệ thống tới thời điểm quay về từ yêu cầu đọc hệ thống.

CHÚ THÍCH: Một thực hiện điển hình thiết lập khoảng quá hạn là bội số của thời gian quay vòng và bội số thường được thiết lập là ba. Tuy nhiên, bởi vì các mạng và phương tiện truyền thông có thể trải qua các trễ đáng kể, hệ thống cần cho phép bội số này được thiết lập ở thời điểm chạy.

6.1.4  Truyền dẫn lại

Nếu một gói dữ liệu xác định yêu cầu một đáp ứng và một đáp ứng phù hợp không thu được trong khoảng thời gian quá hạn, gói dữ liệu đồng nhất (ví dụ cùng số gói dữ liệu, cùng nhãn thời gian,...) sẽ chỉ được phát lại một lần. Nếu không có đáp ứng nào thu được với gói dữ liệu thứ hai, trước khoảng thời gian quá hạn đáp ứng kế tiếp, truyền dẫn gói dữ liệu sẽ được xem là không thành công. Nếu đáp ứng thu được sau khoảng thời gian quá hạn, nó có thể bị bỏ qua.

6.1.5  Lặp đúp các gói dữ liệu

Mỗi lần máy khách hoặc máy chủ thu một gói dữ liệu yêu cầu một đáp ứng, một gói dữ liệu đáp ứng mới sẽ được chuẩn bị và được phát ngay khi có thể, thậm chí nếu gói dữ liệu thu được là gói dữ liệu bị lặp đúp.

6.2  Các thủ tục tệp tổng quát

Máy khách có thể yêu cầu dữ liệu xuất bản (phúc đáp) được gửi trong gói dữ liệu xuất bản, hoặc nó có thể yêu cầu dữ liệu xuất bản được lưu trữ trong một tệp trên máy chủ trong gói dữ liệu xuất bản chỉ thị tên tệp của tệp xuất bản. Tệp sau đó có thể thu được bởi máy khách trong các ràng buộc được thiết lập bởi máy chủ. Một tệp xuất bản như vậy chỉ bao gồm “thông tin TICS” như được định nghĩa bởi cấu trúc PublicationData được định nghĩa ở mục A.9.

6.3  Các phiên

Trong mỗi phiên, một hệ thống là máy khách và hệ thống khác là máy chủ. Một máy chủ với tên miền xác định sẽ không chấp nhận nhiều hơn một phiên với bất kỳ tên miền máy khách với một hồ sơ truyền tải xác định; tuy nhiên, bởi vì một hệ thống đơn có thể có nhiều tên miền, nhiều phiên có thể tồn tại giữa một cặp hệ thống máy khách và hệ thống máy chủ xác định.

CHÚ THÍCH 1: Nhiều phiên có thể tồn tại trên một liên kết vật lý đơn đồng thời. Ví dụ, hệ thống A có thể đóng vai trò như là máy chủ trong một phiên với hệ thống B trong khi đóng vai trò là máy khách trong phiên thứ hai.

CHÚ THÍCH 2: Một máy chủ đơn có thể có các phiên với nhiều máy chủ đồng thời; do đó, số phiên đầy đủ trên hồ sơ truyền tải bất kỳ được định nghĩa bởi tên miền máy chủ được theo sau bởi tên miền máy khách.

CHÚ THÍCH 3: Một số thực hiện có thể có yêu cầu xuất bản thường xuyên các gói dữ liệu tương đối lớn. Có nhiều cách thức khác nhau để đạt được điều này, bao gồm: (1) tăng kích thước gói dữ liệu UDP/IP để hỗ trợ kích thước được yêu cầu; hoặc (2) duy trì một kết nối TCP kéo dài qua đó các gói dữ liệu lớn được gửi định kỳ. Giải pháp ưa THÍCH sẽ phụ thuộc vào một số vấn đề thực hiện cụ thể chẳng hạn như chất lượng môi trường và độ tin cậy truyền dẫn được yêu cầu.

CHÚ THÍCH 4: Các phiên đồng thời giữa một cặp máy khách đơn và máy chủ có thể tồn tại nếu các phiên sử dụng các hồ sơ truyền tải khác nhau (ví dụ một UDP và một TCP).

6.3.1 Thiết lập một phiên

Máy chủ có thể muốn thiết lập một phiên. Ví dụ, để xuất bản thông tin cho một đăng ký (yêu cầu) đã được đăng ký hoặc cho phép thu một đăng ký nếu máy chủ được bảo vệ bởi tường lửa. Trong trường hợp này, máy chủ sẽ phát một gói dữ liệu “Khởi đầu”, như được định nghĩa ở A.3, với các trường datex-Destination-txt và datex-Sender-txt được thiết lập với tên chính xác.

Một máy chủ không cần kết thúc một phiên nó đã khởi đầu trong khoảng thời gian của khoảng nhịp giám sát sau xuất bản cuối cùng.

Nếu máy khách thu được gói dữ liệu “Khởi đầu” hoặc nếu máy khách muốn thiết lập một phiên, máy khách sẽ phát một gói dữ liệu “Đăng nhập”, như được định nghĩa ở A.4.

Dựa trên việc thu gói dữ liệu “Đăng nhập”, máy chủ sẽ xác định các tên miền, tên người sử dụng, mật khẩu, khoảng nhịp giám sát cực đại, khoảng quá hạn đáp ứng, các quy tắc mã hóa được cho phép, kích thức gói dữ liệu và lý do đăng nhập hợp lệ cho yêu cầu. Máy chủ cũng sẽ đảm bảo rằng một phiên với tên miền và hồ sơ truyền tải xác định không sẵn tồn tại. Nếu yêu cầu được tìm thấy không hợp lệ, máy chủ sẽ hoặc là:

- Đáp ứng với một gói dữ liệu “loại bỏ”, như được định nghĩa ở A.12 với “mã-lỗi” được thiết lập tới số mã phù hợp nhất áp dụng cho sự từ chối, hoặc

- Không đáp ứng nếu máy chủ xác định điều này là phù hợp do các lý do bảo mật.

Nếu yêu cầu là hợp lệ, máy chủ sẽ đáp ứng bằng một gói dữ liệu “tiếp nhận”, như được định nghĩa ở A.11, và sẽ mô tả các quy tắc mã hóa đã được lựa chọn từ danh sách các tùy chọn trong yêu cầu đăng nhập. Điều này hoàn thành các thủ tục để thiết lập một phiên.

Thủ tục để thiết lập một phiên được tổng kết ở Hình 3. Tất cả các gói dữ liệu được trao đổi trong suốt thủ tục này sẽ sử dụng các quy tắc mã hóa được đồng ý là không trực tuyến. Tất cả các gói dữ liệu được trao đổi sau khi hoàn thành thành công thủ tục này sẽ sử dụng các quy tắc mã hóa, như được thỏa thuận trong các gói dữ liệu “Đăng nhập” và “Tiếp nhận”.

VÍ DỤ: ở Phụ lục D, nếu phiên được thiết lập qua TCP/IP trên cổng 355, các gói dữ liệu được trao đổi trong suốt thủ tục này sẽ sử dụng mã hóa BER; các gói dữ liệu được trao đổi sau khi hoàn thành thành công quá trình đăng nhập sẽ sử dụng các quy tắc mã hóa được thỏa thuận bởi các gói dữ liệu “Đăng nhập” và “Tiếp nhận”.

Hình 3 - Thiết lập một phiên

6.3.2  Duy trì một phiên

Các phiên được duy trì bởi máy khách và máy chủ trao đổi các gói dữ liệu “FrED”. Nếu, ở điểm bất kỳ trong một phiên, không có gói dữ liệu nào thu được từ hệ thống khác trong khoảng thời gian lớn hơn khoảng nhịp giám sát cực đại, như được mô tả trong yêu cầu đăng nhập, phiên sẽ ngay lập tức kết thúc bởi cả máy khách và máy chủ mà không trao đổi bất kỳ dữ liệu nào. Kiểu kết thúc này chỉ xảy ra do các trường hợp bất bình thường, ví dụ như ngừng hoạt động hệ thống.

CHÚ THÍCH 1: FrED viết tắt của “Trao đổi dữ liệu thân thiện”. Gói dữ liệu nói chung được sử dụng như là một gói dữ liệu xác nhận, nhưng cũng được sử dụng như là một nhịp giám sát hệ thống khi có một khoảng lặng kéo dài. Do đó, thuật ngữ “xác nhận” không thực sự áp dụng cho gói dữ liệu này và cộng đồng quyết định nên được gọi là FrED.

CHÚ THÍCH 2: Một phiên có thể được mở cố định bằng cách đáp ứng các yêu cầu của mục này.

Máy khách sẽ duy trì phiên cho đến khi thủ tục kết thúc được bắt đầu như được chỉ thị bởi 6.3.3. Máy khách sẽ lưu giữ thời gian trôi qua kể từ khi nó thu được một gói dữ liệu từ máy chủ và sẽ đảm bảo rằng thời gian này không vượt quá khoảng nhịp giám sát cực đại bằng cách tạo ra các gói dữ liệu “FrED”, được định nghĩa trong A.5, khi cần thiết. DATEX.FrED_ConfirmPacket_number-ulong sẽ bằng không (0) cho các gói dữ liệu “FrED” như vậy, sau đây được gọi là các gói dữ liệu nhịp giám sát “FrED”. Khuyến nghị rằng máy khách phát các gói dữ liệu nhịp giám sát “FrED” nhiều hơn ba lần so với thời gian được mô tả bởi khoảng nhịp giám sát cực đại.

Máy chủ sẽ xác nhận gói dữ liệu nhịp giám sát “FrED” bằng cách phát một gói dữ liệu “FrED” với DATEX-FrED_ConfirmPacket_number-ulong được thiết lập tới số gói của gói dữ liệu nhịp giám sát “FrED” đang được xác nhận. Điều này sẽ hoàn thành thủ tục duy trì phiên.

Khi mong muốn, phiên sẽ được kết thúc theo thủ tục được mô tả ở 6.3.3.

Thủ tục duy trì một phiên được tổng kết ở Hình 4.

Hình 4 - Duy trì một phiên

6.3.3  Kết thúc một phiên

Một phiên có thể chủ động kết thúc hoặc bởi máy khách hoặc máy chủ. Nếu máy chủ muốn kết thúc một phiên, nó sẽ phát một gói dữ liệu “Kết thúc”, như được định nghĩa ở A.6. Nếu máy chủ không thu được bất kỳ đáp ứng nào sau hai nỗ lực, máy chủ sẽ kết thúc phiên vào lúc cuối.

Nếu máy khách thu một gói dữ liệu “Kết thúc” hợp lệ, hoặc nếu máy khách muốn kết thúc một phiên, nó sẽ phát không hoặc nhiều lệnh hủy đăng ký, như được định nghĩa ở 6.4 và A.8, nếu nó muốn hủy đăng ký bất kỳ, được theo sau bởi gói dữ liệu “Đăng xuất”, được định nghĩa ở A.7.

CHÚ THÍCH 1: Các đăng ký đã được đăng ký không quá hạn với kết thúc một phiên nếu cờ “Duy trì” (“Persistent”) được thiếp lập trong đăng ký. Điều này cho phép các hệ thống giữ các đăng ký tích cực khi phiên không tích cực. Ví dụ, điều này có thể hữu ích cho các kết nối quay số hoặc để cực tiểu hóa tác động của các sự ngừng hoạt động hệ thống.

CHÚ THÍCH 2: Một máy chủ không cần thiết đợi một FrED đối với một xuất bản được bảo đảm cho đăng ký không liên tục.

Dựa trên việc thu được gói dữ liệu “Đăng xuất” hợp lệ, máy chủ sẽ kết thúc phiên liên kết và phát hành gói dữ liệu “FrED”, được định nghĩa ở A.5. Máy khách sẽ kết thúc phiên liên kết dựa trên việc thu gói “FrED”. Điều này hoàn thành thủ tục kết thúc phiên.

CHÚ THÍCH: Nếu máy khách không thu gói “FrED”, mặc dù tuân theo các quy tắc truyền dẫn lại, nó sẽ kết thúc phiên theo các quy tắc của 6.3.2.

Thủ tục kết thúc một phiên được tổng kết ở Hình 5.

Hình 5 - Kết thúc một phiên

6.4  Yêu cầu thông tin

Các máy khách và các máy chủ sẽ cung cấp các đăng ký không trực tuyến (các yêu cầu), được định nghĩa ở 6.4.1, các đăng ký trực tuyến được định nghĩa ở 6.4.2, hoặc cả hai.

CHÚ THÍCH: Quá trình đăng ký có thể diễn ra trực tuyến hoặc không trực tuyến. Điều này cho phép một máy chủ phát các xuất bản (các phúc đáp) (ví dụ các xuất bản sự cố) mà không cản hỗ trợ gói dữ liệu đằng ký kết hợp. Đây là điều mong muốn để đưa các hệ thống hợp pháp tuân thủ nguyên tắc hoặc cho các mục đích bảo mật.

6.4.1  Các đăng ký không trực tuyến

Các máy chủ có thể cung cấp các cơ chế nội bộ để đăng ký bất kỳ và tất cả các đăng ký mà máy chủ tuân thủ. Đặc tính này sẽ được hỗ trợ cho tất cả các máy khách được biết bởi máy chủ.

Các máy khách có thể cung cấp các cơ chế cấu hình nội bộ để tiếp nhận các xuất bản từ một máy chủ từ xa, do đó máy khách có thể tiếp nhận các xuất bản liên quan đến một đăng ký không trực tuyến.

6.4.2  Các đăng ký trực tuyến

Một máy khách có thể hỗ trợ khả năng phát các gói dữ liệu “đăng ký”, như được định nghĩa ở A.8. Nếu máy khách tuân thủ các đăng ký trực tuyến, nó sẽ hỗ trợ dịch vụ này cho tất cả các đăng ký mà nó tuân thủ.

Một máy chủ có thể tiếp nhận các gói dữ liệu “đăng ký” để cho phép các yêu cầu trực tuyến được xử lý. Nếu máy chủ tuân thủ các đăng ký trực tuyến, nó sẽ hỗ trợ các gói dữ liệu “đăng ký” cho tất cả các đăng ký mà nó tuân thủ.

Dựa trên việc thu được một gói dữ liệu đăng ký, máy chủ sẽ đáp ứng hoặc bằng gói dữ liệu “tiếp nhận” hoặc bằng gói dữ liệu “loại bỏ”, như được định nghĩa trong A.11 và A.12. Một “tiếp nhận” sẽ chỉ thị rằng dữ liệu đả thu được chính xác và được hiểu bởi hệ thống; nó không đảm bảo rằng ứng dụng cuối sẽ tiếp nhận đăng ký. Ví dụ, nếu một đăng ký hợp lệ thu được, nhưng người sở hữu phiên xác định không có thẩm quyền thu dữ liệu đã được yêu cầu, một gói dữ liệu “tiếp nhận” sẽ được phát, nhưng ứng dụng cuối sẽ ngay lập tức phát một gói “xuất bản”, như được định nghĩa ở 6.5, chỉ thị rằng đăng ký đã được kết thúc với lý do accessDenied.

Điều này sẽ hoàn thành thủ tục đăng ký.

Nếu đăng ký được tiếp nhận, máy chủ sẽ xuất bản dữ liệu theo 6.5. Một đăng ký có thể bị hủy bỏ bằng cách thiết lập trường datexSubscribe-CancelReason-cd tới một trong những lý do hủy bỏ.

Thủ tục yêu cầu thông tin được tổng kết ở Hình 6.

Hình 6 - Đăng ký một phiên

6.5  Xuất bản thông tin

Xuất bản thông tin phụ thuộc một phần vào kiểu yêu cầu. Thủ tục tổng quát được mô tả ở 6.5.1; các thủ tục cụ thể cho các kiểu yêu cầu khác nhau được mô tả trong:

- 6.5.2 đối với các đăng ký đơn, và

- 6.5.3 đối với các đăng ký đã được đăng ký.

Đối với mỗi đăng ký mà một hệ thống tuân thủ, xuất bản kết hợp sẽ được hỗ trợ. Việc hỗ trợ gói dữ liệu xuất bản là bắt buộc đối với tất cả các gói dữ liệu có kích thước nhỏ hơn kích thước gói dữ liệu cực đại. Nếu hệ thống tuân thủ các xuất bản lớn hơn kích thước gói dữ liệu cực đại, hệ thống sẽ hỗ trợ “xuất bản-chú ý” (xem 6.5.1.3) và cơ chế truyền tải tệp (xem 6.5.1.5); nếu khác, việc hỗ trợ “xuất bản- chủ ý” và cơ chế truyền tải tệp là tùy chọn. Nếu hệ thống tuân thủ “xuất bản-chú ý” và cơ chế truyền tải tệp, hệ thống sẽ hỗ trợ các tính năng này cho tất cả các đăng ký mà nó tuân thủ. Việc hỗ trợ nhiều xuất bản trong một gói dữ liệu đơn hoặc tệp đơn là bắt buộc đối với các máy khách để thu nhận và tùy chọn cho các máy chủ để gửi.

6.5.1  Các thủ tục tổng quát

Máy chủ sẽ tạo ra một gói dữ liệu “xuất bản”, như được định nghĩa ở A.9, ở các thời điểm được mô tả ở 6.5.2-6.5.3.

6.5.1.1  Cờ đảm bảo

DatexPublish-Guaranteed-bool sẽ được thiết lập tới “đúng” (“true”) nếu gói dữ liệu “đăng ký” kết hợp yêu cầu phân phát đảm bảo; nếu khác, nó sẽ được thiết lập tới “sai” (“false”).

6.5.1.2  Các xuất bản gói dữ liệu

Nếu máy khách đăng ký các xuất bản gói dữ liệu, gói dữ liệu xuất bản sẽ bao gồm dữ liệu xuất bản nếu gói dữ liệu kết quả nhỏ hơn kích thước gói dữ liệu cực đại được định nghĩa trong thỏa thuận trao đổi.

CHÚ THÍCH: Một bảng bộ nhớ hầu như được phát như là một gói dữ liệu, mặc dù nó cũng có thể được truyền tải như là một tệp bằng cách tạo ra một đĩa ảo trong bộ nhớ.

6.5.1.3  Gói dữ liệu xuất bản-chú ý

Nếu máy khách đăng ký các xuất bản tệp, hoặc nếu gói dữ liệu kết quả lớn hơn kích thước gói dữ liệu cực đại, dữ liệu sẽ được lưu trữ trong một tệp và gói dữ liệu xuất bản sẽ chỉ thị đường dẫn và tên tệp của dữ liệu xuất bản.

CHÚ THÍCH: Việc truyền tải tệp sử dụng các giao thức truyền tải tệp tiêu chuẩn; do đó, tệp được trao đổi trong một phiên riêng rẽ từ phiên được sử dụng cho các gói dữ liệu DATEX-ASN được mô tả trong tiêu chuẩn này.

6.5.1.4  Đáp ứng máy khách

Nếu máy khách quyết định rằng xuất bản được mã hóa không chính xác, ngoại trừ với cấu trúc PublicationData bất kỳ có thể được hiện diện, nó sẽ phát hành một gói dữ liệu “loại bỏ”, như được định nghĩa trong A.12. Mặt khác, nếu datexPublish-Guaranteed-bool được thiết lập tới đúng, máy khách sẽ phát hành một gói dữ liệu “tiếp nhận”, và nếu datexPublish-Guaranteed-bool được thiết lập tới sai, không đáp ứng nào được gửi.

CHÚ THÍCH: Các lỗi bất kỳ trong cấu trúc PublicationData được kiểm soát bởi các thủ tục trong 6.5.1.6.

Điều này sẽ hoàn thành các thủ tục xuất bản nếu gói dữ liệu “xuất bản” không hợp lệ hoặc nếu gói dữ liệu “xuất bản” chỉ thị một tên tệp và tệp được tải về trước đó và chưa được xác nhận bởi một gói dữ liệu xác nhận truyền tải. Nếu gói dữ liệu “xuất bản” chỉ thị một tệp trước đây không được tải về, các thủ tục trong 6.5.1.5 và 6.5.1.6 sẽ tuân theo thứ tự. Nếu gói dữ liệu “xuất bản” bao gồm dữ liệu xuất bản, các thủ tục trong 6.5.1.6 sẽ được tuân theo.

CHÚ THÍCH: Một tên tệp lặp đúp có thể thu được do thông điệp lặp đúp được gửi bởi vì lỗi truyền thông hoặc do việc phục hồi lại các tên thông điệp. Các máy chủ có thể muốn đặt tên các tệp với các số thứ tự lớn để tránh lặp đúp các tên tệp và ngăn ngừa tổn thất dữ liệu. Nếu máy khách đã sẵn sàng chú ý về xuất bản, không có lý do để bắt đầu quá trình truyền tải tệp khác.

6.5.1.5  Cơ chế truyền tải tệp

Nếu gói dữ liệu “xuất bản” chỉ thị một tên tệp mới (tức là nó không phải là một thông điệp bị lặp lại), máy khách sẽ ngay lập tức lấy lại tệp đã được chỉ thị sau khi gửi gói dữ liệu tiếp nhận, nếu được yêu cầu. Việc truyền tải tệp sẽ thực hiện bởi một trong những cơ chế truyền tải tệp được hỗ trợ, như được thỏa thuận trong các gói dữ liệu “đăng ký” và “xuất bản”. Chỉ khi tệp đã được truyền tài (hoặc máy khách đã vượt số lần cực đại cố gắng tải về tệp), máy khách sẽ phát một gói dữ liệu “truyền tải-được thực hiện” (“transfer-done”), được định nghĩa trong A.10, để kiểm tra việc thu nhận (hoặc thông báo cho máy chủ về sự thất bại). Máy chủ sẽ xác nhận gói dữ liệu “truyền tải-đã được thực hiện” bằng một gói dữ liệu “FrED”, được định nghĩa trong A.5. Máy chủ sẽ cố gắng giữ tệp khả dụng cho việc tải về cho đến khi thông báo xác nhận truyền tải thu được.

6.5.1.6  Loại bỏ dữ liệu xuất bản không hợp lệ

Đối với mỗi cấu trúc PublicationData không hợp lệ được bao gồm trong xuất bản (do mã hóa không hợp lệ), máy khách sẽ gửi một gói dữ liệu loại bỏ. Điều này sẽ hoàn thành các thủ tục này.

Thủ tục xuất bản thông tin được tổng kết ở Hình 7. Một máy chủ có thể hủy bỏ đăng ký bất kỳ ở thời điểm bất kỳ bằng cách gửi một gói dữ liệu xuất bản với trường publicationType của cấu trúc PublicationData được thiết lập tới một trong những mã kết thúc.

Hình 7 - Xuất bản thông tin

CHÚ THÍCH: Việc truyền tải tệp trong trao đổi trên là một thủ tục phức tạp, được định nghĩa bởi tiêu chuẩn truyền tải tệp. Việc truyền tải tệp được yêu cầu bởi máy khách, nhưng được biểu diễn như là mũi tên từ máy chủ chỉ thị rằng tệp là ở trên máy chủ và đang được gửi tới máy khách.

6.5.2  Các đăng ký đơn

Đối với các yêu cầu chỉ một lần, hoặc “đơn”, máy chủ sẽ xuất bản dữ liệu yêu cầu ngay khi có thể sau khi hoàn thành quá trình “đăng ký”. Xuất bản sẽ bao gồm tất cả dữ liệu đáp ứng yêu cầu đăng ký.

CHÚ THÍCH: Dữ liệu lịch sử được xem là các phần tử dữ liệu riêng; do đó, dữ liệu lịch sử có thể nhận được như thông tin khác bất kỳ.

6.5.3  Các đăng ký được đăng ký

Các đăng ký cũng có thể “được đăng ký” để yêu cầu thông tin khi nó trở nên khả dụng hoặc trên một cơ sở định kỳ.

6.5.3.1  Các đăng ký đã đăng ký sẽ hoặc là liên tục hoặc là hàng ngày (tức là được kích hoạt vào các ngày xác định trong tuần).

a) Nếu đăng ký là liên tục, đăng ký sẽ kích hoạt ở datexRegistered-StartTime và vẫn được kích hoạt 24 giờ một ngày, bảy ngày một tuần, cho đến khi đăng ký quá hạn (tức là đến datexRegistered-EndTime) hoặc bị hủy rõ ràng bởi một đăng ký kế tiếp. Nếu datexRegistered-EndTime nhỏ hơn hoặc bằng datexRegistered-StartTime, thì không xuất bản nào được thực hiện.

b) Nếu đăng ký là “hàng ngày”, đăng ký sẽ trở nên tích cực trong máy chủ ở thời điểm bắt đầu (datexRegistered-StartTime) ở mỗi ngày hợp lệ trong tuần (datexRegistered-DaysOfWeek-cd) diễn ra hoặc sau ngày bắt đầu xác định (datexRegistered-StartDate) và trước hoặc vào ngày kết thúc xác định (datexRegistered-EndDate). Nó sẽ ngay lập tức được kích hoạt nếu thời gian hiện tại là hợp lệ khi đăng ký được đăng ký. Đăng ký sẽ ngừng kích hoạt ở cuối chu kỳ được xác định bởi thời gian bắt đầu (datexRegistered-StartTimeOfDay) cộng với khoảng (datexRegistered-Duration). Ngày kết thúc sẽ không sớm hơn ngày bắt đầu. Một đăng ký hàng ngày cũng có thể bị ngừng kích hoạt bởi một yêu cầu thực hiện hủy hoặc thay đổi đăng ký. Nếu datexRegistered-EndDate nhỏ hơn datexRegistered- StartDate, thì không xuất bản nào được thực hiện.

6.5.3.2  Dựa trên việc kích hoạt đăng ký (hoặc tái kích hoạt), máy chủ sẽ xuất bản một thông điệp xuất bản khởi đầu. Nếu máy chủ không thể cung cấp thông tin ở thời điểm bắt đầu được chỉ thị, nó sẽ cung cấp thông tin ngay khi có thể.

6.5.3.3  Các đăng ký đã đăng ký cũng sẽ được phân loại là: a) phụ thuộc sự kiện (tức là cung cấp thông tin khi một sự kiện cụ thể xảy ra); hoặc b) định kỳ (tức là cung cấp thông tin ở tần suất xác định).

6.5.3.4  Sau khi xuất bản khởi đầu được cung cấp, máy chủ sẽ cố gắng cung cấp một thông điệp xuất bản kế tiếp như sau.

6.5.3.4.1  Nếu chế độ là “định kỳ”, máy chủ sẽ cố gắng cung cấp một xuất bản mới định kỳ ở một thời điểm được xác định bởi datexRegistered-UpdateDelay-qty. Nếu đăng ký được gửi sau thời gian bắt đầu, chu kỳ sẽ được đồng bộ với datexRegistered StartTime.

CHÚ THÍCH: Trong trường hợp này, xuất bản khởi đầu sẽ ở một điểm ngẫu nhiên trong chu kỳ, và xuất bản thứ hai có thể theo sau ở đoạn bất kỳ của chu kỳ sau đó, nhưng sẽ diễn ra ở một điểm chu kỳ được đo từ datexRegistered-StartTime.

Trong chế độ định kỳ, một máy chủ cần xuất bản thông tin ở mọi điểm chu kỳ. Nếu máy chủ không thể xuất bản thông tin trong khoảng 60% của một chu kỳ ngoài điểm chu kỳ, xuất bản không nên được phát. Cả máy chủ và máy khách cần kết thúc các đăng ký ít quan trọng hơn (ví dụ được phản ánh trong trường datexSubscription-Priority) để cực tiểu hóa xác suất xảy ra điều này.

CHÚ THÍCH: Ví dụ, giả thiết rằng có một đăng ký định kỳ cho dữ liệu mỗi giây. Máy chủ đáp ứng ban đầu ở thời gian bắt đầu, xuất bản kế tiếp (bao gồm thông tin về các tình trạng ở 1,0 s) được gửi ở 1,25 s, xuất bản kế tiếp (chỉ thị các tình trạng ở 2,0 s) được gửi ở 2,5 s, và xuất bản kế tiếp (bao gồm dữ liệu hợp lệ cho 3,0 s) không sẵn sàng cho đến 3,75 s. Xuất bản cuối cùng này cần được bỏ qua (bởi vì nó muộn hơn 0,6 s) và máy chủ và máy khách cần xem xét việc hủy bỏ các đăng ký ít quan trọng hơn. Ý định là để không gửi dữ liệu cũ và có các hệ thống xây dựng một danh sách không giới hạn các thông điệp để gửi trong khi hệ thống rõ ràng ở dung lượng cực đại. Phụ thuộc vào nội dung của thông điệp và thiết kế hệ thống, điều này có thể hoặc không thể là một vấn đề thực tế. Do đó, mục này có tính tạm thời và việc thực thi nên thực hiện bất kể các tác vụ phù hợp là cần thiết để giải quyết các vấn đề này.

6.5.3.4.2  Nếu chế độ là “phụ thuộc sự kiện” (“event-driven”), máy chủ sẽ cung cấp một xuất bản trong khoảng thời gian của datexRegistered_UpdateDelay qty sau khi máy chủ được thông báo một sự kiện. Do đó, trong trường hợp này, tham số datexRegistered_UpdateDelay-qty đóng vai trò là giá trị trễ cực đại cho báo cáo sự kiện. Thông điệp đăng ký sẽ định nghĩa thuật ngữ “sự kiện” trong định nghĩa và/hoặc phần chỉnh của thông điệp. Nếu trễ cực đại bị vượt quá, dữ liệu sẽ được xuất bản ngay khi có thể và datexPublish-LatePublicationFlag sẽ được thiết lập. Các máy chủ cần kết thúc các đăng ký ít quan trọng hơn (được phản ánh trong trường datexSubscription-Priotity) để cực tiểu hóa xác suất xảy ra điều này.

PHỤ LỤC A

(Quy định)

Các cấu trúc gói dữ liệu

A.1  Tổng quát

Các gói dữ liệu DATEX-ASN được định nghĩa trong ASN.1 như là các gói dữ liệu tầng ứng dụng và có thể được trao đổi sử dụng kết hợp tầng thấp hơn có khả năng tương thích bất kỳ. Tất cả các gói dữ liệu DATEX-ASN sẽ tuân thủ cấu trúc DatexDatapacket (và các cấu trúc phù hợp) được định nghĩa trong module ASN.1 sau đây. Mỗi trường được đặc tả trong module này được định nghĩa chính thức trong Phụ lục B của tiêu chuẩn này.

A.2  Đơn vị dữ liệu giao thức

Cấu trúc PDU cho phép nhiều loại gói dữ liệu được gửi ở cùng cấu trúc tổng thể như được định nghĩa ở trên. Các loại cấu trúc khác nhau có thể được bao gồm trong PDU được mô tả dưới đây.

- khởi đầu: cho phép máy chủ yêu cầu một phiên mới;

- đăng nhập: kiểm tra các mật khẩu,... và quản lý bên trực tuyến;

- FrED: Một “trao đổi thân thiện dữ liệu” được sử dụng để xác nhận việc thu được các gói dữ liệu và duy trì một phiên khi có các khoảng lặng;

- kết thúc: khi máy chủ phải ngừng phiên;

- đăng xuất: cho phép máy khách ngừng phiên;

- đăng ký: yêu cầu dữ liệu (có thể chỉ đúng thời điểm hoặc được đăng ký);

- xuất bản: cung cấp dữ liệu được yêu cầu;

- truyền tải-đã được thực hiện: cho phép máy khách thông báo cho máy chủ rằng một xuất bản đã nhận được;

- tiếp nhận: tiếp nhận một đăng nhập, đăng ký hoặc xuất bản;

- loại bỏ: loại bỏ một đăng nhập, đăng ký hoặc xuất bản.

A.3  Cấu trúc gói dữ liệu bắt đầu

A.4  Cấu trúc gói dữ liệu đăng nhập

A.5  Cấu trúc gói dữ liệu FrED

FrED ::= INTEGER (0..4294967295) -- datexFrED-ConfirmPacket-nbr

A.6  Cấu trúc gói dữ liệu kết thúc

A.7  Cấu trúc gói dữ liệu đăng xuất

A.8  Cấu trúc gói dữ liệu đăng ký

A.9  Cấu trúc gói dữ liệu xuất bản

A.10  Cấu trúc gói dữ liệu truyền tải đã được thực hiện

A.11  Cấu trúc gói dữ liệu tiếp nhận

A.12  Cấu trúc gói dữ liệu loại bỏ

PHỤ LỤC B

(Quy định)

Từ điển dữ liệu

Các phần tử dữ liệu được định nghĩa trong phần này được định nghĩa sử dụng đặc tả đối tượng thông tin ASN.1 sau đây:

Các trường dữ liệu được định nghĩa tuân thủ các trường được đặc tả trong IEEE P1489-1999. Một số trường được yêu cầu trong IEEE 1489-1999 không được bao gồm trong tiêu chuẩn này do dư thừa.

B.1  AMOUNT_Currency_code-datex1

B.2  AMOUNT_Factor_quantity

B.3  AMOUNT_Quantity_quantity

B.4  DATEX.ACCEPT_Login_id-oid

B.5  DATEX.ACCEPT_Packet_number-ulong

B.6  DATEX.ACCEPT_Registered_number-ulong

B.7  DATEX.FrED_ConfirmPacket_number-ulong

B.8  DATEX.LOGIN_DatagramSize_quantity-ushort

B.9  DATEX.LOGIN_EncodingRules_id-oids

B.10  DATEX.LOGIN_HeartbeatDurationMax_quantity-ushort

B.11  DATEX.LOGIN_lnitiator_code-datex2

B.12  DATEX.LOGIN_Password_text-general

B.13  DATEX.LOGIN_ResponseTimeOut_quantity-ubyte

DEFINITION “The time in seconds within which a system will expect to receive a response to the transmision of a data packet. This same timer will apply to both the Client and the Server and will apply to all data packets transmitted within the session where a response is required. The time is measured from the return from the system write () call. If a system has not received the appropriate response prior to this timer expiring, it will assume the transmitted data packet was notreceived by the other end and proceed as defined in Clause 6.1.4.”

B.14  DATEX.LOGIN_UserName_text-general

B.15  DATEX.LOGOUT_Reason_code-datex14

B.16  DATEX.MESSAGE_AuthenticationInformation_text-general255

B.17  DATEX.MESSAGE Crcid-crc16

B.18  DATEX.MESSAGE_Data_text-general

B.19  DATEX.MESSAGE_DataPacket_number-ulong

B.20  DATEX.MESSAGE_DataPacketPriority_code-datex11

B.21  DATEX.MESSAGE_DataPacketTime_frame

B.22  DATEX.MESSAGE_Destination_text-name

B.23  DATEX.MESSAGE_DestinationAddress_location-address

B.24  DATEX.MESSAGE_Origin_text-name

B.25  DATEX.MESSAGE_OriginAddress_location-address

B.26  DATEX.MESSAGE_Sender_text-name

B.27  DATEX.MESSAGESenderAddresslocation-address

B.28  DATEX.MESSAGE_Version_code-datex15

B.29  DATEX.PUBLISH_FileName_text-memo

B.30  DATEX.PUBLISH Guaranteed boolean

B.31  DATEX.PUBLISH_LatePublicationFlag_boolean

B.32  DATEX.PUBLISH_Management_code-datex3

B.33  DATEX.PUBLISH_Serial_number-ulong

B.34  DATEX.PUBLISH_SubscribeSerial_number-ulong

B.35  DATEX.REGISTERED_DaysOfWeek_code-DaysOfWeek

B.36  DATEX.REGISTERED_Duration_quantity-ushort

B.37  DATEX.REGISTERED_EndDate_frame

B.38  DATEX.REGISTERED_EndTime_frame

B.39  DATEX.REGISTERED_StartDate_frame

B.40  DATEX.REGlSTERED_StartTime_frame

B.41  DATEX.REGISTERED_UpdateDelay_quantity-ulong

B.42  DATEX.REJECT_Login_code-datex6

B.43  DATEX.REJECT_Packet_number-ulong

B.44  DATEX.REJECT_Publication_code-datex7

B.45  DATEX.REJECT_PublicationData_code-datex16

B.46  DATEX.REJECT_PublicationSerial_number-ulong

B.47  DATEX.REJECT_Subscription_code-datex8

B.48  DATEX.REJECT_SubscriptionSerial_number-ulong

B.49  DATEX.SUBSCRIBE_CancelReason_code-datex5

B.50  DATEX.SUBSCRIBE_Guarantee_boolean

B.51  DATEX.SUBSCRIBE_Persistent_boolean

B.52  DATEX.SUBSCRlBE_Priority_code-datex11

B.53  DATEX.SUBSCRIBE_PublishFormat_code-datex4

B.54  DATEX.SUBSCRIBE_Serial_number-ulong

B.55  DATEX.SUBSCRIBE_Status_code-datex12

B.56  DATEX.TERMINATE_Reason_code-datex14

B.57  DATEX.TRANSFER.DONE_FileName_text-memo

B.58  DATEX.TRANSFER.DONE_Success_boolean

B.59  END.APPUCATION_Message_id

B.60  END.APPLICATION_Message_msg

B.61  TIME_Centiseconds_quantity

B.62  TIME_Day_quantity

B.63  TIME_Deciseconds_quantity

B.64  TIME_Hour_quantity

B.65  TIME_Milliseconds_quantity

B.66  TIME_Minute_quantity

B.67  TIME_Month_quantity

B.68  TIME_Second_quantity

B.69  TIME_TimeZoneHour_quantity

B.70  TIME_TimeZoneMinute_quantity

B.71  TIME_Year_quantity

PHỤ LỤC C

(Quy định)

Các miền giá trị

Các miền giá trị định nghĩa trong Phụ lục này được định nghĩa sử dụng đặc tả đối tượng thông tin ASN.1 sau đây:

Các trường được định nghĩa tuân thủ các trường được đặc tả trong IEEE P1489-1999.

C.1  Boolean

C.2  Code-Currency

C.3  Code-DATEX initiator

C.4  Code-DATEX publication type

C.5  Code-DATEX publish format

C.6  Code-DATEX cancel subscription

C.7  Code-DATEX reject login

C.8  Code-DATEX reject publication

C.9  Code-DATEX reject publication data

C.10  Code-DATEX reject subscription

C.11  Code-DATEX priority

C.12  Code-DATEX status

C.13  Code-DATEX terminate

C.14  Code-DATEX version

C.15  Code-Days of week

C.16  Id-Crc16

C.17  Id-Object Identifier

C.18  Id-Object identifiers

C.19  Location-Address

C.20  Number-ULONG

C.21 Qty-UBYTE

C.22  Qty-ULONG

C.23  Qty-unlimited

C.24  Qty-USHORT

C.25  Text-Memo

C.26  Text-Name

C.27  Text-Octetstring 255

C.28  Text-Octetstring unlimited

PHỤ LỤC D

(Quy định)

DATEX-ASN qua các giao thức Internet

D.1  Các vấn đề thực hiện Internet

Các yêu cầu trong phụ lục này chỉ áp dụng cho các thực hiện sử dụng hoặc là UDP hoặc là TCP cho các dịch vụ truyền tải và sử dụng cổng 355. Kích cỡ gói dữ liệu cực đại mặc định là 576 byte, nhưng có thể được thay đổi qua yêu cầu đăng nhập. Các quy tắc mã hóa các gói dữ liệu được sử dụng để thiết lập một phiên (tất cả các gói dữ liệu được bao gồm trong thủ tục được mô tả bởi 6.3.1) là BER. Tất cả các gói dữ liệu được trao đổi sau khi thiết lập một phiên sẽ sử dụng các quy tắc mã hỏa được thỏa thuận trong thủ tục thiết lập phiên.

Tiêu chuẩn này trao đổi dữ liệu qua một phiên tầng ứng dụng. Phiên được duy trì hoặc qua một kết nối, trong trường hợp TCP, hoặc qua một kết nối giả, trong trường hợp UDP. Phương pháp sử dụng số cổng phổ biến để thiết lập các kết nối TCP được mô tả trong các tiêu chuẩn Internet và sẽ không được thảo luận ở đây. Phương pháp sử dụng số cổng phổ biến trong kết nối giả UDP được cung cấp như dưới đây.

Để tạo một kết nối giả qua UDP, trạm cố gắng bắt đầu một phiên (một máy chủ gửi một gói dữ liệu Khởi đầu hoặc một máy khách gửi một gói dữ liệu đăng nhập không được yêu cầu) sẽ chọn một số cổng (PN) ngẫu nhiên cho chính nó. Sau đó nó gửi gói dữ liệu khởi đầu tới cổng 355 đã biết từ cổng PN. Máy thu thông điệp này sau đó lựa chọn PN của chính nó và phát hành đáp ứng phù hợp; cổng đích của đáp ứng này sẽ chỉ thị PIN được lựa chọn bởi bên khởi đầu và cổng nguồn sẽ chỉ thị PIN được lựa chọn bởi bên đáp ứng. Cặp PN này sau đó sẽ được sử dụng cho khoảng thời gian còn lại của kết nối giả.

Ví dụ, sau đây mô tả các bước được sử dụng cho một máy chủ thiết lập một phiên UDP:

a) Máy chủ gửi máy khách một gói dữ liệu “khởi đầu” với cổng nguồn được thiết lập tới PN được lựa chọn-máy chủ và cổng đích được thiết lập tới cổng 355 đã biết.

b) Máy khách đáp ứng bằng một gói dữ liệu “đăng nhập” với cổng nguồn được thiết lập tới PN được lựa chọn-máy khách và cổng đích được thiết lập tới PN được lựa chọn-máy chủ.

c) Máy chủ đáp ứng bằng một gói dữ liệu “tiếp nhận” với cổng nguồn được thiết lập tới PN được lựa chọn-máy chủ và cổng đích được thiết lập tới PN được lựa chọn-máy khách.

PHỤ LỤC E

(Quy định)

Danh sách các yêu cầu giao thức

E.1  Các ký hiệu tổng quát

Phụ lục này cung cấp một Danh sách Các yêu cầu Giao thức (PRL) cho việc thực hiện tiêu chuẩn này. PRL sử dụng các ký hiệu sau đây để chì thị trạng thái của các tính năng khác nhau.

Ký hiệu o.<n> được sử dụng để mô tả một tập các tùy chọn có thể lựa chọn (một hoặc nhiều tập phải được thực hiện) với cùng định danh <n>.

Sự kết hợp hai ký tự có thể được sử dụng cho các yêu cầu tuân thủ thay đổi động. Trong trường hợp này, ký tự đầu tiên đề cập đến trạng thái tĩnh (thực hiện), và ký tự thứ hai đề cập đến trạng thái động (sử dụng); do đó “mo” có nghĩa là “bắt buộc phải thực hiện, tùy chọn được sử dụng.”

E.2  Ký hiệu trạng thái có điều kiện

Ký hiệu sau đây được sử dụng để chỉ thị các yêu cầu có điều kiện:

E.3  Các yêu cầu cơ bản

Bảng E.1 chỉ thị các yêu cầu cơ bản cần thiết tuân theo tiêu chuẩn này.

Bảng E.1 - Các yêu cầu cơ bản

E.3.1  Các yêu cầu máy chủ

Bảng E.2 mô tả trạng thái của các tính năng khác nhau cho các máy chủ.

Bảng E.2 - Các yêu cầu máy chủ

PHỤ LỤC F

(Tham khảo)

Hướng dẫn thực hiện

Giao thức DATEX-ASN được thiết kế là giao thức tầng ứng dụng. Phụ lục D mô tả một phương thức chung để thực hiện giao thức này trên kiến trúc giao thức Internet và mô tả số cổng được đăng ký cho thiết kế này, nhưng điều này không ngăn ngừa các thực hiện luân phiên. Giao thức DATEX-ASN có thể được thực hiện qua kiến trúc truyền thông bất kỳ và có thể sử dụng tập các quy tắc mã hóa bất kỳ. Yêu cầu đối với BER bị hạn chế với các thực hiện này sử dụng cổng 355 đã đăng ký.

PHỤ LỤC G

(Tham khảo)

Các ưu điểm của DATEX-ASN

Vào năm 1996, Hoa Kỳ đã thực hiện một nỗ lực để tiêu chuẩn hóa các giao thức được sử dụng cho các trao đổi dữ liệu từ Trung tâm-tới-Trung tâm. Nỗ lực này bắt đầu với một phân tích về các yêu cầu khác nhau của các liên kết Trung tâm-tới-Trung tâm. Ý định ban đầu là sử dụng các yêu cầu này để lựa chọn một giao thức hiện tại đề sử dụng như là tiêu chuẩn công nghiệp. Tuy nhiên, chỉ khi các yêu cầu được liệt kê, sớm trở nên rõ ràng rằng một giao thức sẽ không thể đáp ứng tất cả các yêu cầu được đưa ra.

Một tổng kết các yêu cầu được mô tả trong phân tích này được cung cấp dưới đây:

- Giao thức cần hỗ trợ các trao đổi dữ liệu một chiều và hai chiều.

- Giao thức cần hỗ trợ các đáp ứng phụ thuộc sự kiện, yêu cầu-phúc đáp, và định kỳ.

- Giao thức cần hỗ trợ cả các kết nối cố định và các kết nối quay số, thậm chí cho các yêu cầu với các đáp ứng phụ thuộc sự kiện.

- Một số thực hiện sẽ có băng thông hạn chế, do đó giao thức cần hiệu quả về băng thông.

- Một số thực hiện sẽ được kết nối tới một mạng các trung tâm bên ngoài, và cần có các công cụ khả dụng để thực hiện việc quản lý các kết nối này.

- Một số dữ liệu sẽ cần được bảo vệ thông qua các cơ chế bảo mật.

- Một số trung tâm có thể có một yêu cầu phát thường xuyên theo thời gian thực (ví dụ một lần mỗi giây) các trao đổi dữ liệu có kích cỡ có thể xem xét (ví dụ 100 Kb của 1 byte phần tử dữ liệu) trên các liên kết có băng thông tương đối thấp (ví dụ 28,8 kbps).

- Một số trung tâm sẽ có các tài nguyên hạn chế và giao thức cần đơn giản và có chi phí không cao đủ cho các trung tâm nhỏ trao đổi dữ liệu cực tiểu.

- Giao thức nên có khả năng mở rộng để cũng hỗ trợ các nhu cầu của các trung tâm lớn, phức tạp, nhiều hãng.

Chỉ khi các yêu cầu được xác định, nỗ lực tập trung vào những khả năng mà các giao thức hiện tại có thể thỏa mãn các yêu cầu này. Việc tìm kiếm dẫn đến kết quả đánh giá một số giao thức và ngôn ngữ. Tất cả các giao thức có các hạn chế; ví dụ các hạn chế này được giải thích dưới đây.

- SNMP: Cấu trúc MIB được sử dụng bởi các hệ thống SNMP không sẵn sàng mở rộng về quy mô; giao thức cũng tiêu tốn nhiều băng thông.

- CMIP: Tương tự như SNMP, nhưng thậm chí tiêu tốn nhiều bằng thông hơn.

- Các Socket thô: Đây là một giao diện được định nghĩa rất rõ ràng, nhưng không cung cấp bất kỳ dịch vụ thực nào trên tầng truyền tải. Tuy nhiên, nó được lựa chọn sử dụng như là cơ chế cơ bản của cả CORBA và DATEX-ASN.

- SQL: Ngôn ngữ này có lượng lớn phần mềm hỗ trợ trong công nghiệp, nhưng sử dụng nhiều công cụ này sẽ yêu cầu một xem xét chặt chẽ các thiết kế hệ thống; hơn nữa, nó không cung cấp một số tính năng quay số được yêu cầu bởi các hệ thống khác.

- FTP: Giao thức này cung cấp việc truyền tải các tệp, nhưng không cung cấp các quy tắc khi nào các tệp nên được trao đổi hoặc nội dung chúng cần bao gồm.

- TFTP: Tương tự như FTP, giao thức này cung cấp một cơ chế truyền tải tệp phù hợp, nhưng không định nghĩa các quy tắc khi nào trao đổi dữ liệu hoặc phương thức dữ liệu cần được định dạng.

- HTTP/HTML: Trong khi giao thức/ngôn ngữ này cung cấp một giải pháp lý tường cho các hệ thống phụ thuộc con người ad hoc, nó không cung cấp các tính năng cần thiết cho các hệ thống tự động như một định dạng dữ liệu tiêu chuẩn và các quy tắc về cách thức gửi hoặc thời điểm gửi dữ liệu.

- Dữ liệu tự mô tả: Sơ đồ này cũng được xác định là quá tiêu tốn băng thông, với chức năng cực tiểu.

- CORBA: Giao thức này yêu cầu các tài nguyên thực hiện đáng kể, bao gồm kiến thức người lập trình, bộ nhớ, băng thông và công suất xử lý. Trong khi giao thức là sự phù hợp tốt cho các hệ thống cấp cao, nó khó thực hiện trên các hệ thống nhỏ hơn.

- D-COM: Giao thức này có nhiều hạn chế tương tự như giải pháp CORBA.

- DATEX-Net: Giao thức này được xem có nhiều ưu điểm, nhưng cấu trúc của giao thức không được phân tầng đủ tốt để sẵn sàng mở rộng sự thực hiện của nó tới các trao đổi dữ liệu mới.

Từ kết quả của kiểm tra này, cộng đồng đã quyết định rằng không có giao thức đơn nào tự nó có thể đáp ứng tất cả các yêu cầu. Thay vào đó, cần nhu cầu cho một giao thức cấp cao (CORBA) và một giao thức cấp thấp. Để đáp ứng số cực đại các nhu cầu, quyết định rằng phương pháp tốt nhất để đáp ứng các nhu cầu cấp thấp là phát triển một giao thức đơn giản dựa trên giao thức DATEX-Net được sử dụng ở Châu Âu, là cơ sở hình thành tiêu chuẩn này. Giao thức này sau đó được phát triển trong tiêu chuẩn này để cung cấp một thiết kể nhiều tầng hơn và đảm bảo rằng tất cả các yêu cầu cơ bản được đáp ứng.

Các nỗ lực tương lai có thể định nghĩa phương thức sử dụng CORBA trong môi trường giao thông vận tải.

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

[1]. ISO 14827-1:2005, Transport information and control systems - Data interfaces between centres for transport information and control systems - Part 1: Message definition requirements (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).

[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 xem xét thực hiện

6  Các thủ tục trao đổi dữ liệu

6.1  Các thủ tục gói dữ liệu tổng quát

6.1.1  Các phiên

6.1.2  Các yêu cầu truyền tải

6.1.3  Quá hạn đáp ứng

6.1.4  Truyền dẫn lại

6.1.5  Lặp đúp các gói dữ liệu

6.2  Các thủ tục tệp tổng quát

6.3  Các phiên

6.3.1 T hiết lập một phiên

6.3.2  Duy trì một phiên

6.3.3  Kết thúc một phiên

6.4  Yêu cầu thông tin

6.4.1  Các đăng ký không trực tuyến

6.4.2  Các đăng ký trực tuyến

6.5  Xuất bản thông tin

6.5.1  Các thủ tục tổng quát

6.5.2  Các đăng ký đơn

6.5.3  Các đăng ký được đăng ký

Phụ lục A (Quy định) - Các cấu trúc gói dữ liệu

Phụ lục B (Quy định) - Từ điển dữ liệu

Phụ lục c (Quy định) - Các miền giá trị

Phụ lục D (Quy định) - DATEX-ASN qua các giao thức Internet

Phụ lục E (Quy định) - Danh sách các yêu cầu giao thức

Phụ lục F (Tham khảo) - Hướng dẫn thực hiện

Phụ lục G (Tham khảo) - Các ưu điểm của DATEX-ASN

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