Tiêu chuẩn Quốc gia TCVN 12345:2019 Tiêu chuẩn về dịch vụ thông tin EPC

TIÊU CHUẨN QUỐC GIA

TCVN 12345:2019

TIÊU CHUẨN VỀ DỊCH VỤ THÔNG TIN EPC

EPC information Services (EPCIS) Standard

Lời nói đầu

TCVN 12345:2019 tương đương có sửa đổi với ISO/IEC 19987:2017.

TCVN 12345:2019 do Tiểu Ban kĩ thuật tiêu chuẩn quốc gia TCVN/JTC1/SC31 Thu thập dữ liệu tự động biên soạn, Tổng cục Tiêu chuẩn Đo lường Chất lượng đề nghị, Bộ Khoa học và Công nghệ công bố.

Lời giới thiệu

Mục đích của EPCIS là nhằm cho phép các ứng dụng khác nhau thiết lập và chia sẻ dữ liệu về sự kiện có khả năng hiển thị cả bên trong doanh nghiệp cũng như thông qua các doanh nghiệp. Tóm lại, sự chia sẻ này nhằm cho phép người sử dụng đạt được sự thấu hiểu về đối tượng vật lý hoặc đối tượng số hóa trong điều kiện kinh doanh thích hợp

“Đối tượng” trong khuôn khổ của EPCIS bao gồm các đối tượng vật lý, các đối tượng này được xác định bởi loại hay cấp độ cá thể và chúng được xử lý trong các công đoạn xử lý của toàn bộ quá trình kinh doanh liên quan đến một hay nhiều tổ chức. Ví dụ về đối tượng vật lý gồm các thương phẩm (sản phẩm), đơn vị hậu cần (logistic), tài sản lưu động và tài sản cố định, tài liệu dạng cứng, v.v... “Đối tượng” cũng có thể là đối tượng số hóa và cũng được xác định bởi loại và cấp độ cá thể mà chúng tham gia vào các công đoạn của quá trình kinh doanh có thể so sánh được. Ví dụ về đối tượng số hóa gồm các thương phẩm số hóa (nhạc phẩm tải về, sách điện tử, v. v...), các tài liệu số hóa (phiếu điện tử, v.v...) và tương tự. Trong toàn bộ tiêu chuẩn này, từ “đối tượng” được sử dụng để chứng tỏ một đối tượng vật lý hay đối tượng số hóa được xác định bởi loại hay cấp độ cá thể là đối tượng công đoạn của quá trình kinh doanh. Dữ liệu EPCIS bao gồm “các sự kiện rõ ràng” trong đó mỗi sự kiện là một hồ sơ hoàn thành một công đoạn của quá trình kinh doanh cụ thể diễn ra trước một hay nhiều đối tượng.

Tiêu chuẩn EPCIS này nhằm tăng cường sự hợp tác giữa các đối tác thương mại thông qua sự chia sẻ các thông tin cụ thể về các đối tượng vật lý hay đối tượng số hóa. Tên của EPCIS phản ánh nguồn gốc về sự nỗ lực phát triển mã điện tử sản phẩm (EPC). Tuy nhiên, cần lưu ý rằng EPCIS không yêu cầu việc sử dụng mã điện tử sản phẩm cũng như nhà cung cấp dữ liệu mã tần số radio (FRID), và giống như EPCIS phiên bản 1.2 thậm chí không yêu cầu việc xác định cấp độ cá thể (mà mã điện tử sản phẩm đã được thiết kế ban đầu). Tiêu chuẩn EPCIS này áp dụng cho tất cả các tình huống mà dữ liệu về các sự kiện rõ ràng được truy cập và chia sẻ, và sự hiện diện của “EPC” với cái tên này chỉ có ý nghĩa về mặt lịch sử

EPCIS cung cấp các giao diện mở, được tiêu chuẩn hóa cho phép tích hợp liên tục các dịch vụ được thiết kế tốt trong các môi trường liên công ty cũng như trong nội bộ các công ty. Các giao diện chuẩn được xác định trong tiêu chuẩn EPCIS này cho phép truy cập và phân tích các dữ liệu về sự kiện rõ ràng nhờ sử dụng bộ tiêu chuẩn về hoạt động dịch vụ và các dữ liệu tập hợp được, tất cả được kết hợp với bộ máy an ninh thích hợp mà nó thỏa mãn nhu cầu sử dụng của các công ty. Trong nhiều trường hợp hay hầu hết các trường hợp điều này liên quan đến việc sử dụng một hay nhiều cơ sở dữ liệu vững chắc có dữ liệu về sự kiện rõ ràng, mặc dù các thành phần tiếp cận dịch vụ có thể được sử dụng để chia sẻ trực tiếp ứng dụng lẫn nhau mà không có cơ sở dữ liệu vững chắc

Dù có hay không có cơ sở dữ liệu vững chắc, EPCIS chỉ quy định một giao diện dữ liệu tiêu chuẩn chung giữa các ứng dụng truy cập dữ liệu về sự kiện rõ ràng và các dữ liệu cần tiếp cận đến. EPCIS không quy định cách thức mà các hoạt động dịch vụ hay chính bản thân các cơ sở dữ liệu sẽ được thực hiện. Điều này bao gồm việc không xác định cách thức dịch vụ EPCIS này có được và/hoặc tính toán được các dữ liệu mà các dịch vụ cần, ngoại trừ việc mở rộng dữ liệu truy cập có sử dụng các hoạt động truy cập EPCIS tiêu chuẩn. Giao diện này cần thiết cho khả năng tương tác, còn việc thực hiện là để cho phép cạnh tranh giữa các nhà cung cấp công nghệ và người thực hiện tiêu chuẩn.

EPCIS dự kiến sử dụng kết hợp với tiêu chuẩn từ vựng trong lĩnh vực kinh doanh chính (CBV) của GS1 (CVB1.2). Tiêu chuẩn từ vựng trong lĩnh vực kinh doanh chính cung cấp các định nghĩa về giá trị các dữ liệu mà chúng có thể dùng để phổ biến cấu trúc dữ liệu được xác định trong tiêu chuẩn EPCIS. Việc sử dụng từ vựng tiêu chuẩn cho trong tiêu chuẩn từ vựng trong lĩnh vực kinh doanh chính là quan trọng cho khả năng tương tác và quan trọng cho việc phân tích/truy vấn dữ liệu để giảm thiểu sự khác biệt mà các tổ chức kinh doanh khác nhau thể hiện cùng một ý định. Chính vì vậy các ứng dụng cần sử dụng tiêu chuẩn CBV tối đa đến mức có thể khi xây dựng dữ liệu EPCIS.

Phần hướng dẫn thực hiện đồng thời EPCIS và CBV cung cấp hướng dẫn bổ sung cho việc xây dựng các hệ thống rõ ràng/ xác thực khi sử dụng EPCIS và CBV, kể cả việc thảo luận kỹ lưỡng cách mô hình hóa các tình huống kinh doanh cụ thể khi sử dụng dữ liệu EPCIS / CBV và phương pháp chia sẻ dữ liệu giữa các đối tác thương mại.

Về khái niệm và các quy ước về chữ in: Toàn bộ các phần của tiêu chuẩn này cùng với ngoại lệ của phần 3, 4, 4.5 đều là bắt buộc trừ khi có ghi không bắt buộc.

Các kí hiệu quy ước in được sử dụng xuyên suốt tiêu chuẩn này:

- Toàn bộ chữ IN HOA được sử dụng cho các thuật ngữ đặc thù trong (ISODir2) được liệt kê ở trên.

- Kiểu đơn cách được sử dụng để chỉ rõ ngôn ngữ lập trình, mã phân định UML, và XML cũng như đối với phần nội dung của tài liệu XML.

Các phần giữ chỗ để thay đổi mà cần được thực hiện cho tiêu chuẩn này trước giai đoạn tiêu chuẩn GS1 được thông qua được bắt đầu bằng mũi tên hướng về phía trước như ở đoạn này.

TIÊU CHUẨN VỀ DỊCH VỤ THÔNG TIN EPC

EPC information Services (EPCIS) Standard

1  Phạm vi áp dụng

Tiêu chuẩn này là nhằm cho phép các ứng dụng khác nhau thiết lập và chia sẻ dữ liệu về sự kiện có khả năng hiển thị cả bên trong doanh nghiệp cũng như thông qua các doanh nghiệp. Sự chia sẻ này nhằm cho phép người sử dụng đạt được sự thấu hiểu về đối tượng vật lý hoặc đối tượng số hóa trong điều kiện kinh doanh thích hợp.

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 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 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 8656 Công nghệ thông tin - Kĩ thuật phân định và thu nhận dữ liệu tự động (AIDC) - Thuật ngữ hài hòa;

TCVN 9086 Mã số mã vạch GS1 - Thuật ngữ và định nghĩa;

EPC Global Architecture Framework (EPCAF) (Khung kiến trúc toàn cầu EPC);

GS1 Architecture (Kiến trúc GS1);

GS1 General Specification (Quy định kĩ thuật chung của GS1).

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

Trong tiêu chuẩn này sử dụng các thuật ngữ và định nghĩa quy định trong TCVN 8656 và TCVN 9086.

4  Mối quan hệ với cấu trúc hệ thống GS1 và nguyên tắc về các quy định của EPCIS

Tiêu chuẩn này phần lớn được trích dẫn từ (EPCAF) và (GS1Arch) và cho thấy mối quan hệ của EPCIS với các tiêu chuẩn GS1 khác.

4.1  Tổng quan về tiêu chuẩn GS1

Tiêu chuẩn GS1 hỗ trợ những thông tin cần thiết cho những người sử dụng cuối cùng có tương tác với nhau trong chuỗi cung cấp, đặc biệt những thông tin được yêu cầu hỗ trợ trong quá trình kinh doanh mà thông qua các thông tin này các bên tham gia trong chuỗi cung cấp tương tác. Các đối tượng thông tin này bao gồm các thực thể là một phần của các quá trình kinh doanh. Các thực thể gồm những thứ được mua bán giữa các công ty như sản phẩm, bán sản phẩm, vật liệu thô, bao gói, v.v... Các thực thể khác phù hợp với các đối tác thương mại gồm các thiết bị, phương tiện vận chuyển, máy móc; thực thể tương ứng với địa điểm có thực mà ở đó các quá trình kinh doanh được thực hiện; các pháp nhân như các công ty, phòng ban; bộ phận quan hệ dịch vụ; các bộ phận giao dịch và tài liệu kinh doanh; và những thực thể khác. Các thực thể có thể tồn tại trong thế giới hữu hình, hoặc dạng số hóa hoặc dạng khái niệm. Ví dụ 8 về các đối tượng vật lý gồm sản phẩm điện tử dân dụng, công-ten-nơ vận chuyển và mặt bằng sản xuất. Ví dụ về các đối tượng dạng số hóa gồm phần mềm âm nhạc điện tử, sách điện tử và phiếu điện tử. Ví dụ về các thực thể dạng khái niệm gồm loại thương phẩm, loại sản phẩm và pháp nhân.

Các tiêu chuẩn GS1 có thể chia theo các nhóm dưới đây căn cứ vào vai trò của chúng trong việc hỗ trợ nhu cầu về thông tin liên quan đến các thực thể trong chuỗi cung cấp của các quá trình kinh doanh:

- Các tiêu chuẩn cung cấp công cụ để phân định các thực thể theo cách mà chúng có thể trở thành đối tượng thông tin điện tử được người sử dụng cuối cùng lưu trữ và/hoặc truyền đạt, trao đổi. Các tiêu chuẩn về phân định của GS1 gồm các tiêu chuẩn để xác định mã phân định đơn nhất (còn gọi là các chìa khóa phân định GS1).

- Các tiêu chuẩn cung cấp công cụ để truy cập tự động dữ liệu được thực hiện trực tiếp tại đối tượng vật lý, nó kết nối thế giới vật chất với thế giới thông tin điện tử. Các tiêu chuẩn truy cập dữ liệu của GS1 gồm các định nghĩa về mã vạch và nhà cung cấp dữ liệu phân định bằng tần số radio (FRID), điều này cho phép dán mã phân định trực tiếp lên đối tượng vật lý, và các tiêu chuẩn quy định các giao diện thích hợp cho máy đọc, máy in, và các phần cứng và phần mềm khác mà chúng kết nối nhà cung cấp dữ liệu với các ứng dụng kinh doanh.

- Các tiêu chuẩn cung cấp công cụ để chia sẻ thông tin trong nội bộ các đối tác thương mại và giữa các đối tác thương mại đồng thời cung cấp nền tảng cho các giao dịch kinh doanh điện tử, khả năng hiển thị điện tử của thế giới vật lý/vật chất hoặc thế giới số hóa, và các ứng dụng thông tin khác. Các tiêu chuẩn của GS1 để chia sẻ thông tin bao gồm tiêu chuẩn EPCIS này, nó là tiêu chuẩn về dữ liệu sự kiện rõ ràng. Các tiêu chuẩn khác trong nhóm “chia sẻ” này là các tiêu chuẩn về dữ liệu chủ và tiêu chuẩn về dữ liệu giao dịch kinh doanh, cũng như tiêu chuẩn có tính khám phá giúp cho việc xác định nơi các dữ liệu có liên quan trong suốt chuỗi cung ứng và các tiêu chuẩn về độ tin cậy giúp thiết lập các điều kiện để chia sẻ dữ liệu với độ an toàn cao.

Tiêu chuẩn EPCIS này phù hợp với nhóm “chia sẻ”, nó cung cấp tiêu chuẩn dữ liệu đối với các dữ liệu về sự kiện rõ ràng và các tiêu chuẩn giao diện nhằm truy cập thông tin từ cơ sở dữ liệu truy cập (sử dụng các tiêu chuẩn từ nhóm “truy cập”) và để chia sẻ chính những thông tin này với các ứng dụng kinh doanh và các đối tác thương mại.

4.2  EPCIS trong mối quan hệ với các tầng “Truy cập” và “Chia sẻ”

Sơ đồ dưới đây chỉ ra mối quan hệ giữa EPCIS và các tiêu chuẩn GS1 khác trong các nhóm “Truy cập” và “Chia sẻ”, (nhóm tiêu chuẩn về “Phân định” có rất nhiều dữ liệu ở các cấp độ của cấu trúc này, và vì vậy không thể thể hiện hết ra được).

Hình 1 - Mối quan hệ giữa EPCIS và các tiêu chuẩn GS1 khác

Như mô tả ở hình trên, giao diện truy vấn EPCIS tồn tại như một cầu nối giữa các tiêu chuẩn về “truy cập” và “chia sẻ”. Giao diện truy vấn/phân tích của tiêu chuẩn này cung cấp các dữ liệu rõ ràng cho các ứng dụng nội bộ và để chia sẻ với các đối tác thương mại.

Tại trung tâm của ứng dụng truy cập dữ liệu là lưu đồ hoạt động truy cập dữ liệu, nó giám sát quá trình kinh doanh mà việc truy cập dữ liệu diễn ra. Đây là lôgic mang tính tập quán/tùy chỉnh điển hình dành riêng cho ứng dụng này. Phía dưới lưu đồ hoạt động truy cập dữ liệu trong sơ đồ là đường truyền dữ liệu giữa lưu đồ hoạt động và nhà cung cấp dữ liệu GS1: mã vạch và RFID. Các vạch màu xanh trên sơ đồ có nghĩa là các tiêu chuẩn GS1 có thể sử dụng làm giao diện cho nhà cung cấp dữ liệu. Phía trên lưu đồ hoạt động truy cập dữ liệu là giao diện giữa lưu đồ hoạt động truy cập dữ liệu và các ứng dụng có quy mô lớn của các doanh nghiệp. Nhiều những giao diện này là ứng dụng hoặc đặc thù của doanh nghiệp, mặc dù sử dụng dữ liệu GS1 như là building blocks (làm nền tảng), tuy nhiên, giao diện EPCIS là tiêu chuẩn GS1. Lưu ý rằng giao diện phía trên của sơ đồ, kể cả EPCIS là độc lập với nhà cung cấp dữ liệu sử dụng ở phía dưới của sơ đồ.

Mục đích của các giao diện và lý do vì sao cấu trúc truy cập dữ liệu có nhiều tầng là để tạo sự khác biệt giữa các mức trừu tượng khác nhau. Nhìn từ quan điểm của một doanh nghiệp (cụ thể từ hộp màu xanh trên cùng trong hình), toàn bộ ứng dụng truy cập dữ liệu bảo vệ các ứng dụng của doanh nghiệp tránh những chi tiết/tiểu tiết một cách chính xác cách thức truy cập dữ liệu đã diễn ra. Thông qua giao diện mức ứng dụng (các thanh màu xanh lá cây phía trên cùng) một ứng dụng của doanh nghiệp tương tác với lưu đồ hoạt động truy cập dữ liệu thông qua dữ liệu độc lập với nhà cung cấp dữ liệu và trong đó tất cả các tương tác giữa các thành phần truy cập dữ liệu đã được hợp nhất vào dữ liệu đó. ở một mức thấp hơn, lưu đồ hoạt động truy cập dữ liệu là để phát hiện/nhận biết xem nó có tương tác với máy quét mã vạch, bộ dò tín hiệu, đầu vào của con người, v.v. hay không, còn các giao diện truyền này (các vạch màu xanh lá cây ở giữa) bảo vệ quy trình hoạt động truy cập dữ liệu tránh những chi tiết/tiểu tiết của phần cứng có mức thấp một cách chính xác cách thức các nhà cung cấp dữ liệu làm việc. Các giao diện có mức thấp nhất (vạch màu xanh lá cây ở phía dưới cùng) thể hiện những chi tiết của nhà cung cấp dữ liệu nội bộ đó. EPCIS và tầng “chia sẻ” này nhìn chung khác với các phần tử trong tầng truy cập ở ba khía cạnh chính:

1. EPCIS đề cập một cách rõ ràng những dữ liệu có tính lịch sử (bổ sung cho dữ liệu hiện tại). Tầng truy cập này, ngược lại được định hướng riêng cho việc xử lý theo thời gian thực của dữ liệu truy cập.

2. EPCIS thường đề cập không chỉ dữ liệu thô truy cập từ nhà cung cấp dữ liệu như mã vạch và thẻ FRID, mà còn trong các tình huống thấy rõ những phát hiện có ý nghĩa liên quan đến thế giới thực hoặc thế giới số hóa và các bước cụ thể trong quá trình hoạt động hoặc phân tích các quá trình kinh doanh. Các tầng truy cập thường phát hiện thấy thuần túy / purely hơn về bản chất. Một sự kiện EPCIS chứa nhiều dữ liệu “phân định” như nhau như sự kiện sàng lọc và thu thập hoặc quét mã vạch ở mức cao hơn bởi vì nó kết hợp sự thông hiểu về bối cảnh kinh doanh mà trong bối cảnh đó các dữ liệu mã phân định đã nhận được. Hơn nữa không có yêu cầu nêu rằng một sự kiện EPCIS là liên quan trực tiếp đến phát hiện của nhà cung cấp dữ liệu vật lý cụ thể. Ví dụ một sự kiện EPCIS có thẻ chỉ ra rằng một thương phẩm dễ bị hư hỏng chỉ sau ngày hết hạn: một sự kiện như vậy có thể phát sinh thuần túy bởi phần mềm.

3. EPCIS hoạt động trong môi trường IT của doanh nghiệp ở mức độ dạng hơn nhiều và đa mục đích hơn so với nó tồn tại trong tầng truy cập, ở đây hệ thống điển hình là độc lập và tồn tại để phục vụ mục đích kinh doanh. Một phần và cũng là điều quan trọng nhất đó là do mong muốn chia sẻ các dữ liệu EPCIS giữa các doanh nghiệp mà họ có thể có các giải pháp khác nhau để thực hiện nhiệm vụ tương tự. Một phần, cũng là do bản chất kiên định/ổn định / persistent của dữ liệu EPCIS. Và cuối cùng là do EPCIS tồn tại ở mức cao nhất trong cấu trúc tổng thể, và vì vậy điểm tự nhiên xâm nhập vào hệ thống doanh nghiệp khác sẽ khác xa giữa một doanh nghiệp với doanh nghiệp tiếp theo (hoặc thậm chí trong các bộ phận của cùng doanh nghiệp).

4.3  EPCIS trong mối quan hệ với các đối tác thương mại

Tiêu chuẩn GS1 trong tầng “Chia sẻ” liên quan đến ba loại dữ liệu mà nó được chia sẻ giữa những người sử dụng cuối cùng:

Bảng 1 - Các loại dữ liệu được chia sẻ giữa những người sử dụng cuối cùng

Dữ liệu giao dịch và dữ liệu về sự kiện rõ ràng có đặc tính là các tài liệu mới của loại này liên tục được tạo ra khi nhiều doanh nghiệp được giao dịch trong chuỗi cung cấp một cách ổn định, thậm chí khi không có thực thể của thế giới thực được tạo ra. Dữ liệu chủ, ngược lại thường tĩnh hơn: Dữ liệu chủ đối với một thực thể đã cho/nhất định thay đổi rất chậm (nếu ở tất cả), và lượng dữ liệu chủ chỉ tăng khi các thực thể mới được tạo ra, không chỉ đơn thuần vì các thực thể đang tồn tại tham gia vào quá trình kinh doanh. Ví dụ khi một ý đồ của thương phẩm nhất định xuyên suốt chuỗi cung cấp, thì dữ liệu giao dịch mới và dữ liệu về sự kiện rõ ràng được tạo ra khi cá thể đó trải qua các giao dịch kinh doanh (như mua và bán) và các quá trình vận chuyển vật lý/vật chất (đóng gói, bốc, dỡ v. v...). Thế nhưng dữ liệu chủ mới chỉ được tạo ra khi thương phẩm mới hoặc vị trí được bổ sung vào chuỗi cung cấp

Hình dưới đây minh họa luồng dữ liệu giữa các đối tác thương mại nhấn mạnh vào các phần của tiêu chuẩn EPCIS có liên quan đến luồng dữ liệu về sự kiện rõ ràng

Hình 2 - Giao diện truy vấn/phân tích

Ngoài việc sử dụng giao diện truy vấn/phân tích minh họa ở trên, các đối tác thương mại thông qua các thỏa thuận lẫn nhau có thể sử dụng cấu trúc tài liệu EPCIS được xác định ở phần 9.3 làm phương tiện để truyền tải một tập hợp sự kiện EPCIS tùy chọn kèm theo dữ liệu chủ có liên quan dưới dạng một tài liệu điện tử duy nhất.

4.4  EPCIS trong mối quan hệ với các thành phần cấu trúc của hệ thống GS1 khác

Sau đây là các nét chính về trách nhiệm đối với từng phần tử của cấu trúc hệ thống GS1 như đã minh họa trên hình trong phần trước.

- Máy đọc RFID và mã vạch phát hiện thẻ RFID khi nó ở vùng đọc và phát hiện mã vạch khi máy đọc kích hoạt.

- Giao diện theo chương trình của máy đọc (RFID) mức thấp (LLRP) xác định việc kiểm soát và phân phối nội dung đọc thô của thẻ FRID từ máy đọc đến bộ phận chức năng lọc và tập hợp. Sự kiện tại giao diện này nêu “Máy đọc A đã thấy EPC X vào thời điểm T”

- Lọc & thu thập. Vai trò này lọc và thu thập nội dung đọc thô của thẻ RFID, sau những khoảng thời gian được giới hạn bởi các sự kiện được xác định bởi ứng dụng truy cập EPCIS (ví dụ kích hoạt một máy dò chuyển động). Không có vai trò so sánh nào tồn tại cho việc đọc mã vạch, bởi vì máy đọc mã vạch thường chỉ đọc một mã vạch duy nhất khi nó được kích hoạt

- Giao diện lọc & thu thập (ALC) xác định việc kiểm soát và phân phối dữ liệu đọc đã được lọc và thu thập của thẻ FRID từ bộ phận chức năng lọc và tập hợp đến bộ phận chức năng trong lưu đồ hoạt động truy cập dữ liệu. Sự kiện tại giao diện nêu “Tại máy đọc logic L, giữa thời điểm T1 và T2, các EPC sau đây đã được phát hiện”, ở đây danh sách các EPC không có bản sao và đã từng được lọc theo tiêu chí được xác định bởi ứng dụng truy cập EPCIS. Trong trường hợp mã vạch, dữ liệu so sánh được phân phối trực tiếp đến bộ phận chức năng trong lưu đồ truy cập dữ liệu từ máy đọc mã vạch dưới dạng chuỗi phần tử GS1.

- Lưu đồ hoạt động truy cập dữ liệu giám sát hoạt động của các phần tử cấu trúc mức thấp hơn và cung cấp bối cảnh kinh doanh bằng cách kết hợp với các nguồn thông tin khác liên quan đến việc thực hiện một bước cụ thể của quá trình kinh doanh. Lưu đồ hoạt động truy cập dữ liệu có thể, ví dụ kết hợp hệ thống băng tải với sự kiện lọc & thu thập và đọc mã vạch, có thể kiểm tra đối với trường hợp ngoại lệ và thực hiện các hành động khắc phục (ví dụ: chuyển đối tượng xấu vào khu vực làm lại), có thể trình bày thông tin với người phụ trách nhân sự v.v... Lưu đồ hoạt động truy cập dữ liệu làm rõ bước của quá trình kinh doanh hoặc các bước mà việc truy cập dữ liệu về sự kiện EPCIS diễn ra. Vai trò này có thể phức tạp liên quan đến sự kết hợp của nhiều sự kiện lọc và thu thập và/ hoặc đọc mã vạch với một hay nhiều sự kiện kinh doanh như khi bốc xếp một lô hàng. Hoặc nó có thể được chuyển thẳng như trong quá trình kinh doanh hàng tồn kho mà ở đây có thể có máy đọc được triển khai để phát hiện về các đối tượng xâm nhập hoặc di dời khỏi giá để hàng. Tại đây, sự kiện lọc, sự kiện mức thu thập hoặc dọc mã vạch và sự kiện mức EPCIS có thể quá giống nhau dẫn đến rất ít quá trình xử lý thực tế ở mức quy trình hoạt động truy cập dữ liệu là cần thiết, và quy trình hoạt động truy cập dữ liệu này đơn thuần là định cấu hình, định tuyến các sự kiện từ giao diện lọc và thu thập và/ hoặc các máy đọc mã vạch trực tiếp thông qua giao diện truy vấn EPCIS đến một kho lưu trữ EPCIS hoặc một ứng dụng kinh doanh nào đó. Một lưu đồ hoạt động truy cập dữ liệu có đầu ra ban đầu gồm các sự kiện EPCIS được gọi là một “ứng dụng truy cập EPCIS” trong tiêu chuẩn này.

- Giao dịch EPCIS. Giao dịch thông qua chúng dữ liệu EPCIS được phân phối đến các cấp của doanh nghiệp theo vai trò (phòng ban chức năng của doanh nghiệp), gồm kho lưu trữ EPCIS, ứng dụng truy cập EPCIS, and trao đổi dữ liệu với các đối tác. Các sự kiện giao diện này nêu, ví dụ, “Tại địa điểm X, vào thời điểm T, các đối tượng chứa sau đây (thùng) đã được kiểm tra xác nhận là được tập hợp đến đối tượng để chứa sau đây (pallet)”. Trên thực tế có ba giao diện EPCIS. Giao diện truy vấn EPCIS xác định sự phân bố các sự kiện EPCIS từ ứng dụng truy cập EPCIS đến các vai trò khác sử dụng trong thời gian thực, gồm kho lưu trữ EPCIS và thời gian thực “thúc đẩy” ứng dụng truy cập EPCIS và các đối tác thương mại. Giao diện kiểm soát truy vấn EPCIS xác định cách thức ứng dụng truy cập EPCIS và các đối tác thương mại để nhận dữ liệu EPCIS phụ thuộc vào truy cập, thường bởi giao dịch với kho lưu trữ EPCIS. Giao diện kiểm soát truy vấn EPCIS xác định hai phương thức giao dịch. Trong phương thức “đúng nhu cầu” hoặc “đồng bộ”, một khách hàng đưa ra một yêu cầu thông qua Giao diện kiểm soát truy vấn EPCIS và ngay lập tức nhận được đáp ứng. Trong phương thức “yêu cầu đứng” hay “không đồng bộ” một khách hàng lập một đăng kí truy vấn/tư vấn định kì. Mỗi lần truy vấn định kì được thực hiện, kết quả được phân bổ một cách không đồng bộ (hoặc “thúc đẩy”) đến người nhận thông qua giao diện gọi lại truy vấn EPCIS. giao diện gọi lại truy vấn EPCIS có thể được sử dụng để phân bổ thông tin ngay khi truy cập; điều này tương ứng với mũi tên “có thể bỏ qua để đẩy thời gian thực” trong sơ đồ. Tất cả ba giao diện EPCIS này thường được quy định trong tiêu chuẩn này.

- Ứng dụng truy cập EPCIS: Trách nhiệm thực hiện các quá trình kinh doanh tổng thể của doanh nghiệp, như quản lý kho, giao nhận, phân tích các nguồn thông tin có tính lịch sử, nhờ vậy mà được hỗ trợ bởi các dữ liệu EPC-liên quan.

- Kho lưu trữ EPCIS-kích hoạt: Ghi lại những sự kiện EPCIS-mức được tạo ra bởi một hay nhiều ứng dụng truy cập EPCIS, và sẵn có cho truy vấn về sau nhờ các ứng dụng truy cập EPCIS.

- Ứng dụng đối tác: Hệ thống đối tác thương mại thực hiện cùng một vai trò như ứng dụng truy cập EPCIS, mặc dù từ bên ngoài mạng phản hồi của các bên. Ứng dụng đối tác có thể cho truy cập vào một tập hợp thông tin con có sẵn trong ứng dụng truy cập EPCIS hoặc trong kho lưu trữ EPCIS.

Giao diện trong ngăn xếp này được thiết kế để cách ly những tầng cao hơn của cấu trúc với những chi tiết không cần thiết sao cho các tầng thấp hơn được thực hiện. Có một cách để hiểu điều này đó là xem điều gì sẽ xảy ra nếu thực hiện một vài thay đổi nhất định:

- Giao thức đọc (LLRP) tầng thấp (RFID) và chuỗi các phần tử GS1 cách ly các tầng cao hơn khỏi việc nhận biết giao thức RF nào hoặc Kí hiệu mã vạch nào đang được sử dụng, và những gì máy đọc làm/mô hình đã được chọn. Nếu một máy đọc khác được thay thế thì thông tin gửi qua giao diện này vẫn giữ nguyên.

- Trong trường hợp sử dụng RFID, giao diện lọc & thu thập cách ly tầng cao hơn với các lựa chọn thiết kế về mặt vật lý được thực hiện liên quan đến cách thẻ FRID cảm nhận và tích hợp và cách ranh giới thời gian của sự kiện được kích hoạt. Nếu máy đọc FRID một anten-bốn hướng được thay thế bằng một tổ hợp năm máy đọc anten-đơn hướng "anten thông minh", thì các sự kiện tại tầng lọc & thu thập vẫn dữ nguyên, ngược lại, nếu một cơ chế kích hoạt khác được sử dụng để đánh dấu khoảng thời gian bắt đầu và kết thúc mà các lần đọc được ghi lại, thì sự kiện lọc và thu thập vẫn dữ nguyên.

- EPCIS cách ly ứng dụng của doanh nghiệp với những nhận thức chi tiết về cách các bước cụ thể riêng biệt trong quá trình kinh doanh được thực hiện ở mức chi tiết. Ví dụ, sự kiện EPCIS điển hình “tại khu vực X, vào thời điểm T, các đối tượng chứa sau đây (thùng) đã được kiểm tra xác nhận đang có mặt trên pallet sau đây. Trong khi triển khai kinh doanh theo băng chuyền, điều này có thể tương ứng với một sự kiện lọc & thu thập mà các lần đọc được ghi lại trong khoảng thời gian bắt đầu và kết thúc được kích hoạt bởi tình huống đi ngang qua mắt điện tử ở xung quanh máy đọc được lắp đặt trên băng chuyền. Nhưng một triển khai khác có thể liên quan đến ba người khỏe mạnh đi lại xung quanh và sử dụng máy đọc cầm tay để đọc thẻ. Tại tầng lọc & thu thập, điều này trông rất khác (mỗi kích hoạt máy đọc cầm tay giống như một sự kiện lọc & thu thập riêng biệt), và việc xử lý bởi ứng dụng truy cập EPCIS là hoàn toàn khác (có lẽ liên quan đến bàn điều khiển tương tác mà người ta sử dụng để kiểm tra công việc của họ), Thế nhưng các sự kiện EPCIS vẫn như vậy đối với tất cả các triển khai.

Tóm lại, dữ liệu EPCIS-tầng khác với dữ liệu sử dụng tại tầng truy cập trong cấu trúc hệ thống của GS1 bởi sự kết hợp thông tin về quá trình kinh doanh mà ở đó dữ liệu được thu thập, và cung cấp các phát hiện có tính lịch sử. Trong cách làm như vậy, EPCIS cách ly các ứng dụng có sử dụng thông tin này tránh việc biết những chi tiết tầng thấp một cách chính xác cách một bước quá trình kinh doanh nhất định được thực hiện.

4.5  Nguyên tắc về các quy định của EPCIS

Việc xem xét ở trên các yêu cầu đối với tiêu chuẩn tại tầng EPCIS phức tạp hơn nhiều tại tầng truy cập của cấu trúc hệ thống GS1. Bản chất có tính lịch sử của dữ liệu EPCIS hàm ý rằng giao diện EPCIS cần một bộ/tệp kĩ thuật truy cập phong phú hơn ALE hoặc RFID và giao diện máy đọc mã vạch. Sự kết hợp bối cảnh của quá trình hoạt động hay kinh doanh vào EPCIS ngụ ý rằng các giao dịch EPCIS trong tệp dữ liệu phong phú hơn, và hơn nữa cần mở rộng hơn nhằm quy tụ sự đa dạng của quá trình kinh doanh trên thế giới. Cuối cùng, môi trường đa dạng mà EPCIS hoạt động ngụ ý rằng tiêu chuẩn EPCIS được xếp tầng cẩn thận để ngay cả khi EPCIS được sử dụng giữa các hệ thống bên ngoài khác biệt nhiều về, các chi tiết hoạt động, có tính thống nhất và tính tương tác ở mức độ cấu trúc trừu tượng của dữ liệu như thế nào và dữ liệu đó có nghĩa gì.

Đáp lại các yêu cầu này, EPCIS được mô tả bởi một quy định khung và những quy định hẹp hơn, chi tiết hơn mà ở trong quy định khung đó. Khung này được thiết kế để:

- Được phân tầng: Cụ thể, cấu trúc và nghĩa của dữ liệu được quy định một cách trừu tượng riêng biệt với các chi tiết cụ thể của dịch vụ truy cập dữ liệu và các ràng buộc với các giao thức của giao diện cụ thể. Điều này cho phép thay đổi những chi tiết cụ thể theo thời gian và giữa các doanh nghiệp trong khi vẫn giữ được ý nghĩa chung của chính dữ liệu này. Nó cũng cho phép những quy định về dữ liệu EPCIS được tái sử dụng trong các phương pháp tiếp cận ngoài phương pháp tiếp cận theo định hướng dịch vụ của quy định hiện hành. Ví dụ, định nghĩa dữ liệu có thể được tái sử dụng trong khuôn khổ EDI.

- Khả năng mở rộng: Các quy định cốt lõi cung cấp tệp cốt lõi của các loại dữ liệu và các hoạt động nhưng cũng cung cấp một vài phương tiện nhờ vậy mà tệp cốt lõi có thể được mở rộng cho các mục đích đặc thù đối với ngành công nghiệp nhất định hoặc khu vực ứng dụng. Sự mở rộng không những cung cấp các yêu cầu về quyền sở hữu được giải quyết theo cách thúc đẩy càng nhiều khung tiêu chuẩn càng tốt, mà còn cung cấp cách thức để phát triển các tiêu chuẩn theo thời gian.

- Môđun hóa: Cơ cấu phân tầng và mở rộng cho phép các phần khác nhau của khung EPCIS hoàn chỉnh được quy định bởi các tài liệu khác nhau, đồng thời thúc đẩy sự gắn kết trên toàn khung. Điều này cho phép quá trình tiêu chuẩn hóa (cũng như thực hiện) mở rộng.

Phần còn lại của tiêu chuẩn này quy định khung EPCIS. Nó cũng gắn kết khung đó cùng với một tệp các loại dữ liệu và giao diện dữ liệu. Tiêu chuẩn cùng với từ vựng kinh doanh cốt lõi của GS1, cung cấp các định nghĩa dữ liệu bổ sung mà tầng trên cùng của nó được cung cấp bởi tiêu chuẩn EPCIS.

5  Khung quy định kĩ thuật EPCIS

Quy định kĩ thuật EPCIS này được thiết kế để phân tầng, mở rộng và môđun hóa

5.1  Tầng

Hình 3 - Khung quy định kĩ thuật EPCIS

Các tầng này được mô tả dưới đây:

- Tầng môđun dữ liệu trừu tượng: Tầng môđun dữ liệu trừu tượng này quy định cấu trúc tổng thể của dữ liệu EPCIS. Đây chỉ là tầng mà không thể mở rộng bởi cơ cấu nếu không soát xét lại chính dữ liệu EPCIS. Tầng môđun dữ liệu trừu tượng này quy định các yêu cầu để tạo ra các định nghĩa về dữ liệu trong tầng định nghĩa dữ liệu.

- Tầng xác định /định nghĩa dữ liệu: Tầng xác định /định nghĩa dữ liệu này quy định dữ liệu nào được trao đổi thông qua EPCIS, cấu trúc trừu tượng của nó là gì, và nó có ý nghĩa gì. Một môđun xác định dữ liệu được xác định trong quy định hiện hành được gọi là môđun kiểu sự kiện chủ chốt /cốt lõi. Các định nghĩa dữ liệu trong tầng định nghĩa dữ liệu được quy định một cách trừu tượng theo quy tắc được xác định bởi tầng môđun dữ liệu trừu tượng.

- Tầng dịch vụ: Tầng dịch vụ xác định giao diện dịch vụ trong đó các khách hàng của EPCIS thực hiện giao dịch. Trong quy định hiện hành có hai môđun tầng dịch vụ được xác định. Môđun hoạt động truy cập cốt lõi xác định giao diện dịch vụ (giao diện truy vấn EPCIS) thông qua nó các ứng dụng truy cập EPCIS sử dụng để phân phối các kiểu sự kiện cốt lõi đến các bên quan tâm. Môđun hoạt động truy vấn cốt lõi xác định hai giao diện dịch vụ (giao diện kiểm soát truy vấn EPCIS và giao diện gọi lại truy vấn EPCIS) mà các ứng dụng truy cập EPCIS sử dụng để nhận dữ liệu được truy cập trước đó. Các định nghĩa giao diện trong tầng dịch vụ được quy định một cách trừu tượng với việc sử dụng UML.

- Các ràng buộc: Các ràng buộc quy định việc hiện thực hóa cụ thể tầng xác định dữ liệu và tầng dịch vụ. Có thể có nhiều ràng buộc được xác định cho định nghĩa dữ liệu đã cho và môđun dịch vụ. Trong quy định này, tổng cộng có chín ràng buộc được quy định cho ba môđun được xác định trong định nghĩa dữ liệu và các tầng dịch vụ. Các định nghĩa dữ liệu trong môđun xác định dữ liệu kiểu sự kiện cốt lõi được đưa ra một ràng buộc cho một lược đồ XML. Giao diện truy vấn EPCIS trong môđun hoạt động truy cập cốt lõi đưa ra những ràng buộc đối với hàng/thứ tự thông điệp và HTTP. Giao diện kiểm soát truy vấn EPCIS trong môđun hoạt động truy vấn cốt lõi đưa ra một ràng buộc đối với SOAP trên HTTP thông qua một mô tả dịch vụ mạng WSDL, và một ràng buộc thứ hai đối với AS2. Giao diện gọi lại truy vấn EPCIS trong môđun hoạt động truy vấn cốt lõi đưa ra các ràng buộc đối với HTTP, HTTPS và AS2.

- Tiêu chuẩn từ vựng về kinh doanh cốt lõi của GS1: Tiêu chuẩn từ vựng về kinh doanh cốt lõi của GS1 (CB1.2) luôn đồng hành với tiêu chuẩn EPCIS. Nó xác định các thành phần từ vựng đặc thù có thể được sử dụng để gắn kết với các định nghĩa dữ liệu được quy định trong tầng xác định dữ liệu của tiêu chuẩn EPCIS. Trong khi EPCIS có thể sử dụng mà không có CBV do sử dụng giá trị dữ liệu tư nhân hoặc độc quyền, điều này rất có lợi đối với ứng dụng EPCIS để sử dụng tiêu chuẩn CBV càng nhiều càng tốt.

5.2  Khả năng mở rộng

Kĩ thuật phân tầng đối với quy định kĩ thuật thúc đẩy khả năng mở rộng, vì một tầng có thể tái sử dụng bởi nhiều hơn một lần thực hiện ở tầng khác. Ví dụ, trong khi tiêu chuẩn này bao gồm một ràng buộc XML của môđun xác định dữ liệu kiểu sự kiện cốt lõi thì quy định kĩ thuật khác có thể định nghĩa một ràng buộc của cùng một môđun với một cú pháp khác nhau, ví dụ tệp CSV.

Ngoài khả năng mở rộng vốn có trong việc phân tầng, quy định kĩ thuật EPCIS bao gồm một vài cơ cấu đặc thù đối với khả năng mở rộng:

- Sự phân tầng: Các định nghĩa dữ liệu trong tầng xác định dữ liệu có sử dụng UML, cho phép giới thiệu một định nghĩa dữ liệu mới bằng cách tạo ra một phân tầng của một tầng đang có sẵn. Một phân tầng là một loại mới, loại này gồm toàn bộ lĩnh vực của loại đang tồn tại đồng thời được mở rộng sang lĩnh vực mới. Một thể hiện về một phân tầng có thể được sử dụng trong bất kì ngữ cảnh nào mà ở đó một thể hiện tầng bố được kì vọng.

- Điểm mở rộng: Các định nghĩa về dữ liệu và các quy định kĩ thuật về dịch vụ cũng bao gồm những điểm mở rộng mà các nhà cung cấp có thể sử dụng để cung cấp chức năng mở rộng mà không phải lập các phân tầng

5.3  Khả năng môđun hóa

Khung quy định kĩ thuật EPCIS được thiết kế để trở thành môđun. Điều đó có nghĩa là nó không chỉ gồm một quy định kĩ thuật duy nhất mà còn là một bộ sưu tập các quy định kĩ thuật cụ thể có liên quan với nhau. Điều này cho phép EPCIS phát triển và cải tiến trong hệ thống phân phối. Cấu trúc phân tầng và cơ chế mở rộng cung cấp các hợp phần quan trọng để đạt được khả năng mở rộng, như gộp nhóm vào những môđun.

Khi quy định kĩ thuật EPCIS là môđun, không có quy định giới hạn môđun của các quy định kĩ thuật phải chi tiết hay rõ ràng trong quá trình thực hiện EPCIS. Ví dụ, có thể có sản phẩm phần mềm cụ thể mà nó thực hiện trên nền tảng SOAP/HTTP một dịch vụ của liên kết thùng- pallet và một dịch vụ catalo sản phẩm mà lưu lượng dữ liệu được xác định trong các môđun xác định dữ liệu liên quan, sản phẩm này có thể phù hợp với sáu môđun khác nhau của tiêu chuẩn dữ liệu liên quan; môđun xác định dữ liệu mô tả dữ liệu catalo sản phẩm, môđun xác định dữ liệu xác định liên kết thùng - pallet, các quy định kĩ thuật đối với các dịch vụ tương ứng, và các ràng buộc SOAP/HTTP tương ứng. Tuy nhiên mã nguồn sản phẩm không có dấu vết về danh giới và dĩ nhiên lược đồ cơ sở dữ liệu cụ thể sử dụng cho sản phẩm có thể làm sai lệch dữ liệu sao cho catalo sản phẩm và dữ liệu về liên kết thùng - pallet trở lên gắn bó chặt chẽ. Tuy nhiên chỉ cần kết quả thực phù hợp với các quy định kĩ thuật thì việc thực hiện này là cho phép.

6  Tầng mô hình dữ liệu trừu tượng

Phần này đưa ra các mô tả có tính bắt buộc về mô hình dữ liệu trừu tượng mà nó nhấn mạnh EPCIS.

6.1  Dữ liệu về sự kiện và dữ liệu chủ

Nhìn chung, EPCIS đề cập hai loại dữ liệu: dữ liệu về sự kiện và dữ liệu chủ. Dữ liệu về sự kiện phát sinh trong trường hợp thực hiện các quá trình kinh doanh, và được truy cập thông qua giao dịch truy cập EPCIS và sẵn có cho truy vấn thông qua giao diện truy vấn EPCIS. Dữ liệu chủ là dữ liệu bổ sung nó cung cấp điều kiện cần thiết để diễn giải dữ liệu về sự kiện. Nó có ích cho việc truy vấn xuyên suốt giao diện kiểm soát truy vấn EPCIS, nhưng các phương tiện mà dữ liệu chủ nhập vào hệ thống không được quy định trong tiêu chuẩn EPCIS này.

Tầng mô hình dữ liệu trừu tượng không nhằm xác định nghĩa của các thuật ngữ “dữ liệu về sự kiện” hay “dữ liệu chủ” ngoài việc cung cấp các định nghĩa chính xác về cấu trúc dữ liệu như được sử dụng bởi quy định kĩ thuật EPCIS. Việc mô hình thông tin kinh doanh của thế giới thực như dữ liệu về sự kiện và dữ liệu chủ là trách nhiệm của tầng xác định dữ liệu, của ngành công nghiệp và các thỏa thuận của người sử dụng cuối cùng được xây dựng ở phần đầu của tiêu chuẩn này.

Không bắt buộc/ không quy định: Giải thích: Trong khi với mục đích của tiêu chuẩn này thì thuật ngữ “dữ liệu về sự kiện” và “dữ liệu chủ” chẳng có nghĩa gì ngoài “dữ liệu thích hợp với cấu trúc được cho ở đây,” cấu trúc này được xác định trong tầng mô hình dữ liệu trừu tượng và được thiết kế để mô tả thích hợp đối với dữ liệu thông thường được giao dịch thông qua EPCIS. Một cách không chính thức thì hai loại dữ liệu này có thể hiểu như sau. Dữ liệu về sự kiện phát triển về số lượng khi công việc kinh doanh được giao dịch nhiều hơn, và đề cập đến những gì xảy ra tại những thời điểm cụ thể về thời gian. Một ví dụ cho dữ liệu về sự kiện là “Vào lúc 1h 23min ngày 15 tháng 3 năm 2004, EPC X được phát hiện tại khu vực L”. Dữ liệu chủ, nhìn chung không phát triển chỉ là vì nhiều công việc kinh doanh được giao dịch (mặc dù dữ liệu chủ không có xu hướng phát triển khi các tổ chức phát triển về cỡ), không bị trói buộc vào những thời điểm cụ thể về thời gian (mặc dù dữ liệu chủ có thể thay đổi chậm theo thời gian), và diễn giải các phần tử dữ liệu về sự kiện. Một ví dụ cho dữ liệu chủ là “khu vực L liên quan đến trung tâm phân phối ở 123 phố Elm, thị trấn Any, US,”. Toàn bộ dữ liệu trong tập các trường hợp sử dụng được xem xét trong quá trình tạo ra tiêu chuẩn EPCIS có thể mô hình hóa như một tổ hợp các dữ liệu về sự kiện và dữ liệu chủ của loại này.

Cấu trúc dữ liệu về sự kiện và dữ liệu chủ trong EPCIS được minh họa dưới đây. (lưu ý rằng đây chỉ là một minh họa; các phần tử từ vựng đặc thù và tên thuộc tính của dữ liệu chủ trên hình này không được xác định trong tiêu chuẩn này.)

Hình 4 - Cấu trúc dữ liệu về sự kiện và dữ liệu chủ trong EPCIS

Các thành phần của mô hình dữ liệu trừu tượng EPCIS được xác định dưới đây:

- Dữ liệu về sự kiện: Một tập hợp các sự kiện.

- Sự kiện: Một cấu trúc gồm một loại sự kiện và một hoặc nhiều trường sự kiện được đặt tên.

- Loại sự kiện: Một miền tên - tên đầy đủ (qname), nó cho biết sự kiện đã cho phù hợp với cấu trúc nào trong một vài cấu trúc sự kiện có thể (như được định nghĩa bởi tầng xác định dữ liệu).

- Trường sự kiện: Một trường được đặt tên trong phạm vi của một sự kiện. Tên trường này được cho bởi (qname), liên quan đến tên của trường được quy định bởi tầng xác định dữ liệu hoặc tên trường được xác định là một phần mở rộng thêm của tiêu chuẩn này. Giá trị của trường có thể là một kiểu nguyên thủy (như chữ số nguyên hoặc dấu hiệu về thời gian), phần tử từ vựng, hoặc danh mục các kiểu nguyên thủy hoặc phần tử từ vựng.

- Dữ liệu chủ: Một tập hợp từ vựng, cùng với thộc tính của dữ liệu chủ liên kết với các thành phần của từ vựng đó.

- Từ vựng: Một tập hợp được đặt tên cho các mã phân định. Tên của từ vựng là một qname mà có thể sử dụng làm tên cho kiểu trường sự kiện. Mã phân định thuộc phạm vi từ vựng được gọi là các thành phần từ vựng. Từ vựng đại diện cho một tập hợp các giá trị lựa chọn, nó có thể xuất hiện dưới dạng các giá trị của trường sự kiện đặc thù. Từ vựng trong EPCIS được sử dụng làm các tập hợp mô hình như tập hợp tên các khu vực có sẵn, tập hợp tên các bước của quá trình kinh doanh có sẵn v.v...

- Thành phần từ vựng: Mã phân định mà nó đặt tên cho sự lựa chọn được mô hình bởi từ vựng. Giá trị của trường sự kiện có thể là một thành phần từ vựng. Các thành phần của từ vựng được đại diện cho mã phân định nguồn đồng dạng (URIs). Mỗi thành phần từ vựng có thể có các thuộc tính dữ liệu chủ liên kết.

- Thuộc tính của dữ liệu chủ: Một tập hợp các cặp tên/ giá trị không có thứ tự liên kết với thành phần từ vựng riêng biệt. Phần tên của một cặp là qname. Phần giá trị của một cặp có thể là giá trị kiểu tùy ý. Thuộc tính đặc thù (có thể trống) là danh mục trẻ em, mỗi em là thành phần từ vựng khác của cùng từ vựng. Xem phần 6.5.

Các sự kiện EPCIS mới tạo ra ở rìa và được phân phối đến hạ tầng EPCIS thông qua giao diện truy vấn EPCIS, sau đó chúng có thể được phân phối đến các ứng dụng được quan tâm thông qua giao diện truy vấn EPCIS. Không có một cơ chế nào được cung cấp trong cả hai giao diện mà ứng dụng có thể xóa hoặc làm thay đổi sự kiện EPCIS. Chỉ có một cách “rút lại/đính chính” hoặc “làm chính xác” sự kiện EPCIS là tạo ra sự kiện tiếp theo có ý nghĩa kinh doanh để hủy bỏ hoặc sửa đổi sự ảnh hưởng của sự kiện trước (phần 7.4.1.3 thảo luận về cách thức có thể thực hiện).

Trong khi giao diện truy vấn EPCIS và giao diện truy vấn EPCIS không cung cấp phương tiện cho ứng dụng để yêu cầu xóa một sự kiện một cách rõ ràng thì các kho lưu trữ EPCIS có thể thực hiện chính sách giữ lại tài liệu làm cho sự kiện EPCIS cũ trở lên không tiếp cận được sau một khoảng thời gian.

Dữ liệu chủ, ngược lại có thể thay đổi theo thời gian, mặc dù các thay đổi này được yêu cầu là không thường xuyên liên quan đến tốc độ mà ở đó dữ liệu về sự kiện mới được tạo ra. Phiên bản hiện hành của tiêu chuẩn này không quy định cách dữ liệu chủ thay đổi (như nêu ở trên (cũng không quy định cách dữ liệu chủ nhập vào nơi đầu tiên).

6.1.1  Truyền dữ liệu chủ trong EPCIS

Truy cập EPCIS và giao diện truy vấn EPCIS chủ yếu quan tâm đến việc truyền sự kiện EPCIS. Phương tiện nhờ nó mà dữ liệu chủ nhập vào hệ thống để thực hiện giao diện này không được quy định trong tiêu chuẩn EPCIS này. Tuy nhiên tiêu chuẩn EPCIS không cung cấp cơ chế đề truyền dữ liệu chủ mà việc thực hiện có thể sử dụng nó để đảm bảo rằng người nhận dữ liệu về sự kiện EPCIS có quyền truy cập vào dữ liệu chủ cần thiết để giải thích dữ liệu về sự kiện đó. Nói một cách khác là dữ liệu chủ có thể truyền bằng phương tiện hoàn toàn nằm ngoài tiêu chuẩn EPCIS. Tiêu chuẩn EPCIS không áp đặt bất kì yêu cầu nào về việc liệu dữ liệu về sự kiện EPCIS có kèm theo dữ liệu chủ hay không ngoài việc yêu cầu dữ liệu chủ kèm theo dữ liệu về sự kiện phải nhất quán với tất cả dữ liệu chủ trong phần ILMD của các sự kiện đó.

Tiêu chuẩn EPCIS cung cấp bốn cơ chế để truyền dữ liệu chủ, được tóm tắt trong bảng dưới đây:

Bảng 2 - Các cơ chế truyền dữ liệu chủ

6.2  Loại từ vựng

Từ vựng được sử dụng sâu rộng trong EPCIS cho mô hình vật lý, số hóa, và các thực thể mang tính khái niệm mà nó tồn tại trong thế giới thực. Ví dụ về từ vựng được định nghĩa trong tầng xác định dữ liệu EPCIS cốt lõi là tên các tên vị trí, tên loại đối tượng (tên loại đối tượng là những thứ gì đó như “Acme Deluxe Widget” trái lại EPC có tên là một ví dụ cụ thể của Acme Deluxe Widget), và tên các bước kinh doanh. Trong mỗi trường hợp một từ vựng đại diện cho một tập hợp các lựa chọn hữu hạn (mặc dù mở) mà nó có thể xuất hiện trong các trường đặc thù của sự kiện.

Cần phân biệt hai loại từ vựng, theo các mẫu khác nhau theo cách chúng được định nghĩa và mở rộng theo thời gian:

- Từ vựng tiêu chuẩn: Từ vựng tiêu chuẩn diễn tả một tập hợp các phần tử của từ vựng mà định nghĩa và ý nghĩa của chúng phải được đồng thuận trước đó bởi các đối tác thương mại, họ là những người sẽ trao đổi sự kiện có sử dụng từ vựng. Ví dụ, tầng xác định dữ liệu cốt lõi EPCIS định nghĩa từ vựng được gọi là “bước kinh doanh,“ có các phần tử của nó là mã phân định dùng để chỉ những thứ như “giao hàng”, “nhận hàng” và v.v. Một đối tác thương mại có thể tạo ra sự kiện có bước kinh doanh “giao hàng”, còn đối tác khác nhận sự kiện đó thông qua truy vấn có thể giải thích điều này bởi vì thỏa thuận trước đó “giao hàng” có nghĩ là gì.

- Các phần tử của từ vựng tiêu chuẩn được định nghĩa bởi các tổ chức có nhiều người sử dụng cuối cùng, như GS1, ngành công nghiệp hiệp hội nằm ngoài GS1, các tập đoàn đối tác thương mại tư nhân v.v... Dữ liệu chủ kết hợp với các phần tử của từ vựng tiêu chuẩn được định nghĩa bởi chính các tổ chức đó, và mong muốn được chia sẻ với người sử dụng như một phần của quy định kĩ thuật hoặc bằng một số phương tiện tương tự. Các phần tử của từ vựng mới trong từ vựng tiêu chuẩn đã cho mong muốn được sử dụng vào quá trình một cách thận trọng và không thường xuyên, như khi phê chuẩn một phiên bản tiêu chuẩn mới hay thông qua bỏ phiếu của tập đoàn công nghiệp. Khi một tổ chức của người sử dụng cuối cùng riêng biệt hoạt động độc lập, họ có thể đưa vào sử dụng phần tử từ vựng mới, nhất là phần tử ít được sử dụng khi thiết lập trao đổi dữ liệu và hầu như chỉ sử dụng trong phạm vi bốn bức tường của tổ chức.

- Từ vựng của người sử dụng: Từ vựng của người sử dụng diễn tả một tập hợp các thành phần của từ vựng mà định nghĩa và ý nghĩa của chúng chịu sự kiểm soát của một tổ chức duy nhất. Ví dụ, tầng xác định dữ liệu cốt lõi EPCIS định nghĩa từ vựng được gọi là “địa điểm kinh doanh" có các phần tử của nó là mã phân định dùng để chỉ những thứ như “Acme Corp, Trung tâm phân phối 3,“ Acme Corp có thể tạo ra sự kiện có địa điểm kinh doanh “Acme Corp, Trung tâm phân phối 3,” còn đối tác khác nhận sự kiện đó thông qua truy vấn có thể giải thích điều này bởi vì hoặc là nó tương quan với các sự kiện khác mang tên cho cùng địa điểm, hoặc nhìn vào thuộc tịnh của dữ liệu chủ kết hợp với địa điểm, hoặc cả hai.

- Các phần tử từ vựng của người sử dụng ban đầu được định nghĩa bởi tổ chức sử dụng cuối cùng riêng biệt hoạt động độc lập. Dữ liệu chủ liên kết với Các phần tử từ vựng của người sử dụng được định nghĩa bởi chính các tổ chức đó, và thường được chia sẻ với các đối tác thương mại thông qua giao diện kiểm soát truy vấn EPCIS hoặc cơ cấu trao đổi dữ liệu/cơ cấu đồng bộ dữ liệu. Phần tử từ vựng mới trong từ vựng của người sử dụng đã cho được đưa vào sử dụng theo quyết định riêng của người sử dụng cuối cùng, và các đối tác thương mại phải sẵn sàng đáp ứng một cách phù hợp. Tuy nhiên thông thường các quy tắc để xây dựng các phần tử từ vựng của người sử dụng mới được thiết lập bởi các tổ chức của nhiều người sử dụng cuối cùng và trong mọi trường hợp phải theo các quy tắc được xác định trong 6.4 dưới đây.

Các dòng giữa hai loại từ vựng này có phần chủ quan. Tuy nhiên cơ cấu xác định trong quy định kĩ thuật EPCIS hoàn toàn không gây ra sự phân biệt giữa hai loại từ vựng, và vì vậy hoàn toàn không cần thiết phải định nghĩa từ vựng cụ thể khi nó thuộc loại này hay loại kia. Thuật ngữ “từ vực tiêu chuẩn” và “từ vựng của người sử dụng” được nêu ra chỉ vì chúng có lợi như gợi ý về cách thức từ vựng nhất định kì vọng được định nghĩa và mở rộng.

Tiêu chuẩn từ vựng kinh doanh cốt lõi của GS1 (CBV) [CBV1.2] cung cấp các thành phần từ vựng tiêu chuẩn cho nhiều loại từ vựng sử dụng trong các loại sự kiện EPCIS. Đặc biệt CBV định nghĩa thành phần từ vựng cho các loại từ vựng tiêu chuẩn EPCIS sau đây: Bước kinh doanh, cách bố trí, loại giao dịch kinh doanh và nguồn/loại điểm đến. CBV cũng định nghĩa bản mẫu để xây dựng các thành phần từ vựng đối với các loại từ vựng của người sử dụng EPCIS sau đây: Đối tượng (EPC, cấp đối tượng (EPCclass), địa điểm (điểm đọc và địa điểm kinh doanh), ID giao dịch kinh doanh, ID nguồn/ID điểm đến và ID biến đổi.

6.3  Cơ chế mở rộng

Đặc tính chính của EPCIS là khả năng mở rộng bởi các tổ chức khác nhau nhằm thích ứng với các tình huống kinh doanh cụ thể. Tóm lại, tầng mô hình dữ liệu trừu tượng cung cấp năm phương pháp nhờ đó mà dữ liệu được xử lý bởi EPCIS có thể được mở rộng (ngoài ra tầng dịch vụ còn cung cấp cơ chế thêm các dịch vụ bổ sung) được liệt kê ở đây từ các loại xâm nhập/xâm lấn nhiều nhất đến loại ít xâm nhập/ xâm lấn nhất:

- Loại sự kiện mới: Loại sự kiện mới có thể được bổ sung vào tầng xác định dữ liệu. Việc bổ sung loại sự kiện mới đòi hỏi mỗi ràng buộc định nghĩa dữ liệu được mở rộng và có thể cũng đòi hỏi việc mở rộng giao diện truy cập và truy vấn cùng các ràng buộc của chúng.

- Trường sự kiện mới: Trường sự kiện mới có thể được bổ sung vào loại sự kiện hiện hành trong tầng định nghĩa dữ liệu. Các ràng buộc, giao diện truy cập, và giao diện truy vấn được định nghĩa trong tiêu chuẩn này được thiết kế để cho phép loại mở rộng này mà không yêu cầu phải thay đổi quy định kĩ thuật (điều tương tự có thể không đúng với các ràng buộc khác hoặc ngôn ngữ truy vấn được định nghĩa ở ngoài tiêu chuẩn này).

- Loại từ vựng mới: Loại từ vựng mới có thể bổ sung vào các điều khoản của loại từ vựng đang có sẵn. Không yêu cầu phải thay đổi các ràng buộc hoặc giao diện

- Thuộc tính dữ liệu chủ mới: Tên thuộc tính mới có thể được định nghĩa cho từ vựng hiện hành. Không yêu cầu phải thay đổi các ràng buộc hoặc giao diện

- Thực thể mới/Thuộc tính dữ liệu chủ của lô hàng (ILMD): Tên thuộc tính mới có thể được định nghĩa để sử dụng trong thể/dữ liệu chủ của lô hàng (ILMD); xem 7.3.6.

- Thành phần từ vựng mới: Thành phần mới được bổ sung vào từ vựng hiện hành. Không yêu cầu phải thay đổi các ràng buộc hoặc giao diện.

Tầng mô hình dữ liệu trừu tượng đã từng được thiết kế sao cho hầu hết các mở rộng/tiện ích phát sinh từ việc áp dụng bởi các ngành công nghiệp khác nhau hoặc do sự gia tăng hiểu biết trong ngành công nghiệp nhất định có thể được cung cấp bởi các phương pháp ở cuối danh sách nêu trên, mà không yêu cầu phải soát xét lại chính tiêu chuẩn này. Các phương pháp xâm nhập/ xâm lấn nhiều hơn ở phía đầu của danh sách cho sẵn, tuy nhiên, trong trường hợp có tình huống phát sinh mà không thể được cung cấp bởi các phương pháp ở cuối danh sách.

Một số cách khác nhau để mở rộng quy định kĩ thuật EPCIS như được tóm tắt dưới đây:

Bảng 3 - Các cách mở rộng quy định kĩ thuật EPCIS

6.4  Mô tả mã phân định

Tầng mô hình dữ liệu trừu tượng giới thiệu một số loại mã phân định, bao gồm tên loại sự kiện, tên trường sự kiện, tên từ vựng, thành phần từ vựng và tên thuộc tính dữ liệu chủ. Vì tất cả miền tên này được tự do mở rộng, tiêu chuẩn này áp đặt một vài quy tắc khi đặt tên sao cho các tổ chức độc lập có thể kiến tạo các mở rộng mà không sợ bị trùng tên.

Thành phần từ vựng phải tuân thủ các quy tắc sau đây. Trong trường hợp thành phần từ vựng được biểu thị dưới dạng mã phân định tài nguyên/nguồn thống nhất (URI) với cú pháp chung được định nghĩa trong (RFC2396). Các loại URIs có thể chấp nhận là thành phần từ vựng là những URIs có chủ sở hữu. Điều này bao gồm:

- Các biểu thị URI đối với mã EPC (TDS1.9, điều 6). Chủ sở hữu đối với EPC URI cụ thể là tổ chức có mã doanh nghiệp GS1 được thừa nhận (hoặc cơ quan có thẩm quyền phát hành theo quy trình EPC).

- Định vị nguồn thống nhất tuyệt đối (URLs) (RFC1738). Chủ sở hữu đối với URI cụ thể là tổ chức sở hữu tên miền internet trong phần quyền hạn URL.

- Tên nguồn thống nhất (URNs) (RFC2141) trong miền tên oid bắt đầu bằng mã số doanh nghiệp (PEN). Chủ sở hữu đối với OID-URN là tổ chức mà PEN được ban hành.

- Tên nguồn thống nhất (URNs) (RFC2141) trong miền tên epc hoặc epc toàn cầu không kể URIs được sử dụng để biểu thị EPCs (TDS1.9). Chủ sở hữu đối với URNs là GS1.

Tên loại sự kiện và tên trường sự kiện được biểu thị dưới dạng miền tên- tên đầy đủ (qname), bao gồm một miền tên URI và một cái tên. Điều này được biểu thị đơn giản trong ràng buộc XML và thuận lợi cho việc mở rộng.

6.5  Từ vựng phân cấp

Một số từ vựng có phân cấp hoặc cấu trúc đa cấp. Ví dụ, từ vựng tên của của vị trí có thể có thành phần có nghĩa “Acme corp. cửa hàng bán lẻ # 3 cũng như thành phần khác có nghĩa “Acme corp. cửa hàng bán lẻ # 3 phòng cuối” và “Acme corp. cửa hàng bán lẻ # 3 tầng giảm giá”. Trong ví dụ này có mối quan hệ phân cấp tự nhiên, trong đó mã phân định đầu là bố và hai mã phân định tiếp theo là con.

Mối quan hệ phân cấp giữa các thành phần từ vựng được biểu thị qua dữ liệu chủ. Đặc biệt, ngoài các thuộc tính dữ liệu chủ, mã phân định bố chứa danh sách các mã phân định con. Mỗi mã phân định con PHẢI thuộc về cùng từ vựng như bố. Ở ví dụ trên thành phần mang nghĩa “Acme corp. trung tâm phân phối # 3” sẽ có danh sách các con bao gồm thành phần mang nghĩa “Acme corp. trung tâm phân phối # 3 cửa # 5.”

Ở phần khác trong tiêu chuẩn này, thuật ngữ “thế hệ con cháu trực tiếp hay gián tiếp” được sử dụng để ám chỉ tập hợp các thành phần từ vựng bao gồm con của thành phần từ vựng đã cho, con của những đứa con đó v.v. Điều đó có nghĩa là “thế hệ con cháu trực tiếp hay gián tiếp” của thành phần từ vựng là tập hợp các thành phần từ vựng nhận được bằng cách đóng mối quan hệ “con cái” bắt đầu với thành phần từ vựng đã cho.

Thành phần từ vựng đã cho CÓ THỂ là con của nhiều bố. Điều này cho phép có nhiều cách nhóm các thành phần từ vựng; ví dụ các vị trí có thể nhóm theo đặc điểm địa lý và chức năng. Tuy nhiên, một thành phần PHẢI KHÔNG là con của chính nó kể cả trực tiếp hay gián tiếp.

Không bắt buộc: Giải thích: Trong phiên bản hiện hành của tiêu chuẩn này chỉ có một mối quan hệ phân cấp được cung cấp, lấy tên mối quan hệ mã hóa trong danh sách “con” đặc thù. Các phiên bản trong tương lai của tiêu chuẩn này có thể phát sinh điều này nhằm cho phép nhiều hơn mối quan hệ, dĩ nhiên việc lập mã cho mỗi mối quan hệ thông qua thuộc tính dữ liệu chủ khác nhau.

Mối quan hệ phân cấp được nghiên cứu đặc biệt khi truy vấn (8.2) và có thể có vai trò khi thực hiện các chính sách ủy quyền (8.2.2) nhưng không được tạo thêm bất kì sự phức tạp hay cơ chế nào cho tầng mô hình dữ liệu trừu tượng.

7  Tầng định nghĩa dữ liệu

7.1  Quy tắc chung đối với quy định mô đun tầng định nghĩa dữ liệu

Quy tắc chung đối với quy định mô đun trong tầng định nghĩa dữ liệu được cho tại đây. Các quy tắc này sau đây được áp dụng ở 7.2 nhằm xác định mô dun loại sự kiện cốt lõi. Quy định này cũng được áp dụng cho các tổ chức mong muốn tạo tầng cho quy định kĩ thuật phía trên cùng của tiêu chuẩn này.

7.1.1  Nội dung

Nhìn chung, quy tắc đối với quy định mô đun trong tầng định nghĩa dữ liệu có các thành phần này, nó gắn kết với khung mô hình dữ liệu trừu tượng được quy định ở điều 6:

- Loại giá trị: Các định nghĩa về loại dữ liệu được sử dụng để mô tả các giá trị của trường sự kiện và các thuộc tính dữ liệu chủ. Mô đun loại sự kiện cốt lõi định nghĩ loại nguyên thủy có ích cho tất cả các mô đun định nghĩa dữ liệu sử dụng. Mỗi từ vựng được định nghĩa cũng ngầm hiểu là loại giá trị.

- Loại sự kiện: Các định nghĩa loại sự kiện, mỗi định nghĩa cho một cái tên loại sự kiện (nó phải duy nhất cho toàn bộ các loại sự kiện) và danh sách các trường sự kiện tiêu chuẩn cho loại đó. Một loại sự kiện có thể được định nghĩa như là một phân tầng của loại sự kiện hiện hành, có nghĩa là loại sự kiện mới bao gồm tất cả các trường sự kiện của sự kiện hiện hành cộng với bất kì trường sự kiện bổ sung nào với điều kiện là một phần của tiêu chuẩn này.

- Trường sự kiện: Định nghĩa trường sự kiện cùng với loại sự kiện. Mỗi định nghĩa trường sự kiện quy định một cái tên cho trường này (nó phải duy nhất cho tất cả các trường loại sự kiện đóng) và loại dữ liệu về giá trị trong trường đó. Các định nghĩa trường dữ liệu cùng với mô đun định nghĩa dữ liệu có thể là bộ phận của loại sự kiện mới được đưa vào bởi mô đun đó, hoặc có thể mở rộng loại sự kiện được định nghĩa ở mô đun khác.

- Loại từ vựng: Định nghĩa loại từ vựng, mỗi định nghĩa cho một cái tên từ vựng (nó phải duy nhất cho toàn bộ các từ vựng), danh sách các thuộc tính dữ liệu chủ tiêu chuẩn đối với các thành phần từ vựng và các quy tắc kiến tạo thành phần từ vựng mới cho từ vựng. (Bất kì quy tắc nào được quy định để kiến tạo thành phần từ vựng trong loại từ vựng phải thích hợp với quy tắc chung cho ở 6.1).

- Thuộc tính dữ liệu chủ: Định nghĩa thuộc tính dữ liệu chủ đối với loại từ vựng. Mỗi định nghĩa thuộc tính dữ liệu chủ quy định một cái tên cho thuộc tính (nó phải duy nhất cho tất cả các thuộc tính loại từ vựng đóng) và loại dữ liệu giá trị của thuộc tính đó. Định nghĩa dữ liệu chủ cùng với mô đun định nghĩa dữ liệu có thể thuộc về loại từ vựng mới được đưa vào bởi mô đun đó, hoặc có thể mở rộng loại từ vựng được định nghĩa ở mô đun khác.

- Thành phần từ vựng: Định nghĩa thành phần từ vựng, mỗi định nghĩa quy định một cái tên (nó phải duy nhất cho tất cả các thành phần trong từ vựng và phù hợp với quy tắc chung đối với các thành phần từ vựng cho ở 6.4 cũng như các quy tắc đặc thù được quy định trong định nghĩa loại từ vựng), và quy định có tính lựa chọn dữ liệu chủ (giá trị thuộc tính đặc thù) đối với thành phần đó.

Không bắt buộc: Sự mở rộng: Như đã giải thích ở 6.3, mô đun định nghĩa dữ liệu được định nghĩa trong tiêu chuẩn này và các quy định kĩ thuật đồng hành được xây dựng bởi nhóm công tác EPCIS dự kiến sẽ gồm các định nghĩa về loại giá trị, loại sự kiện, trường sự kiện, và loại từ vựng, trong khi đó các mô đun được định nghĩa bởi các nhóm công tác khác dự kiến sẽ gồm các định nghĩa về trường sự kiện mà nó mở rộng cho các loại sự kiện hiện tại, thuộc tính dữ liệu chủ mà nó mở rộng cho các loại từ vựng hiện tại và các thành phần từ vựng mà nó đưa vào từ vựng hiện tại. Các nhóm khác đôi khi cũng có thể định nghĩa các loại từ vựng.

Từ “từ vựng” được sử dụng không chính thức nhằm ám chỉ loại từ vựng và tập hợp toàn bộ các thành phần từ vựng mà chúng có.

7.1.2  Kí hiệu

Trong các phần dưới đây, các loại sự kiện và trường sự kiện được quy định có sử dụng mẫu Kí hiệu sơ đồ cấp/loại UML. Sơ đồ cấp/loại UML sử dụng cho mục đích này có thể chứa các cấp/loại có các thuộc tính (trường) và sự liên kết, nhưng không hoạt động. Đây là một ví dụ:

Hình 5 - Sơ đồ cấp/loại UML cho các loại sự kiện

Sơ đồ này diễn tả định nghĩa dữ liệu cho hai loại sự kiện, EventType1 và EventType2. Các loại sự kiện này tận dụng bốn loại giá trị: Type1, Type2, DataClass3 và DataClass4. Typel và Type2 là các loại gốc/nguyên thủy, còn DataClass3 và DataClass4 là loại phức hợp, cấu trúc của chúng cũng được quy định tại UML.

Loại sự kiện EventType1 ở ví dụ này có bốn trường, Field1 và Field2 là loại gốc Type1, và Type2 theo trình tự. EventType1 có Fields của trường khác, loại của nó là DataClass3. Cuối cùng, EventType1 có Field4 của trường khác, nó chứa danh sách gồm zero hoặc nhiều hơn các trường hợp của loại DataClass4 (“0..*” kí hiệu cho “zero hoặc nhiều hơn”).

Sơ đồ này cũng diễn tả định nghĩ: dữ liệu cho EventType2. Mũi tên có đầu hình tam giác mở biểu thị rằng EventType2 là phân cấp của EventType1. Điều này có nghĩa là EventType2 thực chất có năm trường: bốn trường được thừa hưởng từ EventType1 cộng với Field5 thứ năm của loại Type1.

Trong mô tả UML, kí hiệu <<điểm mở rộng>> (<<extension point>>) định nghĩa là nơi việc thực hiện PHẢI cung cấp khả năng mở rộng thông qua việc bổ sung các thành viên dữ liệu mới. (Khi một loại có điểm mở rộng, và loại khác được định nghĩa là phân cấp của loại thứ nhất và cũng có điểm mở rộng, nó không có nghĩa là loại thứ hai có hai điểm mở rộng, ngược lại nó đơn thuần chỉ nhấn mạnh rằng loại thứ hai cũng được mở để mở rộng.) Cơ chế mở rộng PHẢI cung cấp cả việc mở rộng quyền sở hữu bởi nhà cung cấp sản phẩm phù hợp EPCIS, và mở rộng được định nghĩa bởi GS1 thông qua các phiên bản trong tương lai của tiêu chuẩn này hoặc thông qua quy định kĩ thuật mới.

Trong trường hợp xây dựng tiêu chuẩn XML, các điểm mở rộng được thực hiện theo sơ đồ XML và theo phương pháp mô tả ở 9.1.

Tất cả các định nghĩa về loại sự kiện PHẢI bao gồm điểm mở rộng để cung cấp khả năng mở rộng được định nghĩa ở 6.3 (“trường sự kiện mới”). Các loại giá trị CÓ THỂ bao gồm một điểm mở rộng.

7.1.3  Ngữ nghĩa

Mỗi sự kiện (ví dụ về loại sự kiện) mã hóa cho một số xác nhận, nó định nghĩa đúng ngữ nghĩa của sự kiện. Một vài xác nhận nêu đâu là sự thật tại thời điểm sự kiện được truy cập. Các xác nhận khác nêu điều gì được mong đợi sẽ là sự thật tiếp theo sự kiện này trước khi bị vô hiệu bởi sự kiện đến sau. Điều này được gọi là ngữ nghĩa trong quá khứ và ngữ nghĩa trong tương lai của sự kiện, theo trình tự. Ví dụ; nếu tiện ích # 23 vào tòa nhà # 5 qua cửa # 6 lúc 11:23 tối sau đó một xác nhận trong quá khứ là “tiện ích # 23 đã được phát hiện thấy tại cửa # 6 lúc 11:23 tối”, trong khi đó một xác nhận trong tương lai lại là “tiện ích # 23 ở trong tòa nhà # 5.” Sự khác biệt mấu chốt ở đây là xác nhận trong quá khứ ám chỉ thời điểm cụ thể trong quá khứ (“tiện ích # 23 đã phát hiện thấy ...”) trong khi đó một xác nhận trong tương lai lại công bố về điều kiện hiện tại của đối tượng (“ ’’tiện ích # 23 ở...” ) Sự xác nhận trong tương lai lại phỏng đoán rằng nếu tiện ích # 23 chưa bao giờ rời khỏi tòa nhà # 5, sự kiện truy cập EPCIS khác sẽ được ghi lại để thay thế sự kiện trước.

Nhìn chung, ngữ nghĩa hồi tưởng/ trong quá khứ là những gì không thể đảo ngược, được hiểu là sự thật tại thời điểm truy cập sự kiện và thông thường có thể tin cậy dựa vào các ứng dụng truy cập EPCIS như là những công bố chính xác về thực tế lịch sử. Ngữ nghĩa trong tương lai, vì chúng cố gắng nêu đâu là sự thực sau sự kiện đã từng xảy ra, phải được coi là tốt nhất để được công bố “điều gì nên” hơn là “điều gì là”. Một xác nhận trong tương lai có thể không đúng nếu thiết bị truy cập thực hiện chức năng không hoàn hảo, hoặc nếu mô hình/kiến trúc hệ thống hoặc quá trình kinh doanh không được thiết kế để truy cập các sự kiện EPCIS trong tất cả các tình huống. Hơn nữa để tận dụng sự xác nhận trong tương lai tiềm ẩn trong sự kiện, ứng dụng truy cập EPCIS phải chắc chắn rằng nó có quyền truy cập vào bất kì sự kiện tiếp theo mà nó có thể thay thế cho sự kiện đang đề cập đến.

Việc phân đôi quá khứ/tương lai đóng vai trò quan trọng cho việc định nghĩa về vị trí EPCIS ở 7.3.4.

Trong các tình huống nhất định, một sự kiện trước đó được phát hiện sau đó có lỗi (các xác nhận ngữ nghĩa của nó phát hiện thấy không đúng), và lỗi đó không thể sửa được bằng cách ghi lại một sự kiện mới mà nó bổ sung thêm những xác nhận thông qua chính ngữ nghĩa của nó. Đối với những trường hợp này cơ chế được cung cấp để ghi lại sự kiện mà ngữ nghĩa của nó xác nhận rằng các xác nhận được thực hiện trước đó bởi sự kiện mắc lỗi là có lỗi. Xem 7.4.1.2.

7.2  Mô đun loại sự kiện cốt lõi - Tổng quan

Mô đun định nghĩa dữ liệu Loại Sự kiện Cốt lõi quy định Loại Sự kiện để biểu thị sự kiện truy cập dữ liệu EPCIS. Các sự kiện này thông thường được tạo ra bởi ứng dụng Truy cập EPCIS và cung cấp cho hạ tầng EPCIS có sử dụng các hoạt động truy cập dữ liệu được định nghĩa ở 8.1. Các sự kiện này cũng được đáp ứng để truy vấn các hoạt động truy xuất các sự kiện theo tiêu chí truy vấn.

Các thành phần của mô đun này, theo nội dung ở 7.1.1 như sau:

- Loại Giá trị: Thành phần gốc được định nghĩa ở 2.3.1 và 2.3.2.

- Loại Sự kiện: Loại sự kiện được chỉ ra trong sơ đồ UML dưới đây và được định nghĩa ở 7.4.1 đến 7.4.5.

- Trường Sự kiện: Bao gồm một phần các định nghĩa về Loại Sự kiện.

- Loại Từ vựng: Các Loại được định nghĩa ở 7.3.2 đến 7.3.5 và tổng hợp ở 7.2.

- Thuộc tính dữ liệu chủ: Bao gồm một phần các định nghĩa về Loại từ vựng. Điều mong đợi là các nhóm công tác của ngành dọc công nghiệp sẽ định nghĩa thêm các thuộc tính dữ liệu chủ cho các từ vựng được định nghĩa tại đây.

- Thành phần Từ vựng: Không được cung cấp như là một phần của tiêu chuẩn này. Điều mong đợi là các nhóm công tác của ngành dọc về công nghiệp sẽ định nghĩa các thành phần từ vựng cho từ vựng của các Bước Kinh doanh.

(7.3.5), từ vựng Bố trí (7.3.5.2), và từ vựng Loại Giao dịch Kinh doanh (7.3.5.3.1)

Mô đun này định nghĩa sáu loại sự kiện, trong đó một sự kiện rất chung và năm phân tầng (một trong số đó không được chấp nhận của EPCIS 1.1) mà nó có thể diễn tả các sự kiện phát sinh từ hoạt động của chuỗi cung cấp của nhiều ngành công nghiệp khác nhau:

- Sự kiện EPCIS (7.4.1) là tầng nền tảng chung cho tất cả các loại sự kiện trong mô đun này cũng như mô đun khác.

- Sự kiện Đối tượng (7.4.1.2) diễn tả một sự kiện xảy ra đối với một hay nhiều đối tượng vật lý hoặc đối tượng số hóa.

- Sự kiện Tổ hợp (7.4.3) diễn tả một sự kiện xảy ra đối với một hay nhiều đối tượng tổ hợp cùng nhau về mặt vật lý (bị hạn chế về mặt vật lý tại cùng một nơi, cùng thời điểm như khi các thùng hàng được tập hợp đến palet).

- Sự kiện Số lượng (7.4.4) diễn tả một sự kiện liên quan đến số lượng các đối tượng đặc thù cùng chia sẻ một tầng EPC chung nhưng tại đây các danh tính cá nhân của các thực thể không quy định. Xét đến EPCIS 1,1 thì sự kiện này không được chấp nhận; Sự kiện Đối tượng (7.4.1.2) cùng với một hoặc nhiều Phần tử số lượng (7.3.3.3) phải được sử dụng thay thế.

- Sự kiện Giao dịch (7.4.5) diễn tả một sự kiện trong đó một hay nhiều đối tượng sẽ liên kết hoặc tách ra khỏi một hay nhiều giao dịch kinh doanh đã được định nghĩa.

- Sự kiện chuyển giao (7.4.6) diễn tả một sự kiện trong đó đối tượng đầu vào được tiêu thụ toàn bộ hoặc một phần và đối tượng đầu ra được sản xuất sao cho bất kì đối tượng đầu vào nào có thể góp phần với tất cả đối tượng đầu ra.

Sơ đồ UML chỉ ra các Loại Sự liện này như ở dưới đây:

CHÚ THÍCH Trong sơ đồ này, những cái tên nhất nào đó được viết tắt do không gian hạn chế ví dụ Bizlocation ID được sử dụng trên sơ đồ khi đó loại thực sự được gọi là BusinessLocation ID. Xem nội dung của quy định kĩ thuật đối với các tên quy định của các trường sự kiện và các loại của chúng.

Hình 6 - Sơ đồ UML cho các loại sự kiện

Mỗi loại sự kiện cốt lõi (không tính Sự kiện EPCIS chung) có trường diễn tả bốn kích thước chính cho mỗi sự kiện EPCIS. Bốn kích thước này là: (1) các đối tượng hoặc thực thể là đối tượng của sự kiện; (2) ngày và tháng; (3) địa điểm sự kiện hiện diện; (4) bối cảnh kinh doanh. Bốn kích thước này có thể dễ nhớ như, “cái gì, khi nào, ở đâu và vì sao” (một cách lần lượt) Kích thước, “cái gì” đa dạng phụ thuộc vào loại sự kiện (ví dụ, đối với một sự kiện đối tượng kích thước, “cái gì” gồm một hay nhiều EPCs; đối với Sự kiện Tổ hợp kích thước, “cái gì” gồm ID của thế hệ bố và banh sách các EPCs thế hệ con). Các kích thước, “ở đâu” và, “tại sao”có cả khía cạnh trong quá khứ và trong tương lai (xem 7.1.3) được diễn tả bởi các trường khác nhau.

Bảng dưới đây tổng hợp các trường loại sự kiện liên quan đến bốn kích thước chính

Bảng 4 - Các trường loại sự kiện liên quan đến bốn kích thước chính

Ngoài trường thuộc bốn kích thước chính này các sự kiện có thể mang thông tin mô tả ở các trường khác. Hy vọng rằng phần lớn các trường thông tin mô tả được định nghĩa bởi các quy định kĩ thuật của ngành công nghiệp đặc thù được bố trí phía trên.

Bảng dưới đây tổng hợp các loại từ vựng được định nghĩa ở mô đun này. Cột URI đưa ra tên chính thức đối với từ vựng được dùng khi từ vựng phải tham chiếu đến nhờ tên qua giao diện EPCIS.

Bảng 5 - Các loại từ vựng

Loại ID vị trí là siêu loại của ID Điểm Đọc, ID Bước Kinh doanh, ID Nguồn Đến. Trong tài liệu dữ liệu chủ EPCIS (hoặc tiêu đề dữ liệu chủ cùng với tài liệu EPCIS hoặc tài liệu truy vấn EPCIS), urn: epcis toàn cầu: loại v: URI khu vực có thể sử dụng để quy định một từ vựng duy nhất có chứa mã phân định mà có thể xuất hiện tại điểm đọc, bước kinh doanh, nguồn hoặc trường nơi đến của các sự kiện EPCIS liên kết.

7.3  Mô đun loại sự kiện cốt lõi - khối cấu trúc

Điều này quy định khối cấu trúc cho các loại sự kiện được định nghĩa ở 7.3.5.4.

7.3.1  Loại nguyên thủy

Các loại nguyên thủy sau đây được sử dụng cùng với mô đun Loại sự kiện cốt lõi

Bảng 6 - Các môđun loại nguyên thủy

Loại EPC được định nghĩa là loại nguyên thủy để sử dụng trong các sự kiện khi tham chiếu đến EPCs mà chúng không là một phần của loại từ vựng, ví dụ: một SGTIN EPC được sử dụng để thể hiện một trường hợp của một thương phẩm trong trường danh mục epc của một sự kiện đối tượng là sự thể hiện của loại EPC nguyên thủy. Tuy nhiên một SGLN EPC được sử dụng như là mã phân định điểm đọc (7.3.4) trong trường điểm đọc của một sự kiện đối tượng là một thành phần từ vựng chứ không là sự thể hiện loại EPC nguyên thủy.

Không bắt buộc: Giải thích: Điều này phản ánh một quyết định về thiết kế mà không xét đến các trường hợp thương phẩm cá thể như các thành phần từ vựng có dữ liệu chủ, do thực tế là các trường hợp thương phẩm liên tục được tạo ra và vì vậy các EPCs mới đại diện cho các thương phẩm liên tục được đặt mua. Một phần, quyết định về thiết kế này phần ánh việc xử lý nhất quán dữ liệu chủ như loại trừ dữ liệu phát triển khi hoạt động kinh doanh có nhiều giao dịch hơn (xem bình luận ở 6.1), và một phần phản ánh thực tế hữu dụng là dữ liệu thể hiện thương phẩm có khả năng được quản lý như dữ liệu sự kiện hơn là dữ liệu chủ khi nói đến lão hóa, thiết kế cơ sở dữ liệu, v. v.

7.3.2  Loại hành động

Loại hành động nêu cách một sự kiện liên quan đến chu trình sống của thực thể đang được mô tả như thế nào. Ví dụ Sự kiện Tổ hợp (7.4.3) được sử dụng để truy cập sự kiện liên quan đến sự tập hợp các đối tượng lại, như các thùng hàng được tập hợp đến một palet. Trong suốt vòng đời của mình palet tham gia vào nhiều bước của quá trình kinh doanh, mỗi bước đó có thể phát sinh một sự kiện EPC. Trường hành động của mỗi sự kiện nêu tổ hợp bản thân tự thay đổi trong suốt sự kiện như thế nào: liệu các đối tượng đã được bổ sung vào tổ hợp này chưa, liệu các đối tượng đã được loại ra khỏi tổ hợp này chưa, hoặc tổ hợp này đơn giản đã từng được phát hiện mà không làm thay đổi thành viên của nó? Hành động độc lập với bước kinh doanh (ID loại Bước Kinh doanh), nó phân định bước của quá trình kinh doanh đặc thù mà hành động xảy ra

Loại hành động là loại được đánh số có ba giá trị có thể:

Bảng 7 - Giá trị hành động

Mô tả dưới đây đối với từng loại sự kiện bao gồm cả giá trị hành động nêu một cách chính xác hơn là hành động nào có ý nghĩa trong bối cảnh của sự kiện đó

Lưu ý là ba giá trị ở trên chỉ là ba giá trị có thể đối với hành động. Không như các loại khác được định nghĩa dưới đây, Hành động không là loại từ vựng, và KHÔNG ĐƯỢC mở rộng bởi các nhóm công nghiệp.

7.3.3  Kích thước “Cái gì”

Phần này định nghĩa các loại dữ liệu được sử dụng trong kích thước “Cái gì” đối với các loại sự kiện quy định ở 7.3.5.4.

7.3.3.1  Cấp độ - cá thể với Nhận dạng cấp độ - tầng

Kích thước “Cái gì” đối với sự kiện EPC quy định các đối tượng vật lý hay số hóa nào tham gia vào sự kiện. EPCIS cung cấp các đối tượng để nhận dạng theo hai cách:

- Cấp độ - cá thể: Mã phân định được nêu đến là mã phân định cấp độ - cá thể nếu mã phân định như vậy được cấp sao cho nó là đơn nhất cho một đối tượng duy nhất. Điều đó có nghĩa là không có hai đối tượng nào được mang cùng một mã phân định cấp độ - cá thể.

- Cấp độ - tầng: Mã phân định được nêu đến là mã phân định cấp độ - tầng nếu nhiều đối tượng có thể mang cùng một mã phân định

- Nhìn chung, mã phân định cấp độ - cá thể cho phép các sự kiện EPCIS chuyền tải nhiều thông tin hơn vì có thể tương quan nhiều sự kiện EPCIS có kích thước “cái gì” có cùng mã phân định cấp độ - cá thể. Ví dụ, nếu sự kiện EPCIS chứa mã phân định cấp độ - cá thể đã cho, và sự kiện EPCIS tiếp theo chứa cùng mã phân định thì đó chắc chắn là cùng một đối tượng đã tham gia vào cả hai sự kiện. Ngược lại, nếu cả hai sự kiện chứa các mã phân định cấp độ - tầng thì nó không chắc chắn rằng cùng một đối tượng đã tham gia vào cả hai sự kiện bởi vì sự kiện thứ hai không thể là trường hợp khác cùng tầng (có nghĩa là một đối tượng khác mang cùng mã phân định cấp độ - tầng như đối tượng ban đầu ). Mã phân định cấp độ - tầng thường chỉ sử dụng khi việc cấp mã phân định cấp độ - cá thể đơn nhất cho từng đối tượng là không thực tế

Không bắt buộc: Ví dụ: Trong hệ thống GS1, ví dụ về mã phân định cấp độ - cá thể gồm GTIN + xê-ri, SSCC, GRAI kể cả xê-ri, GIAI, GSRN, và GDTI kể cả xê-ri. Ví dụ mã phân định cấp độ-tầng gồm GTIN, GTIN + lot, GRAI không có xê-ri, và GDTI không có xê-ri

7.3.3.2  EPC

Mã điện tử sản phẩm (EPC) là một cấu trúc của mã phân định cấp độ - cá thể được định nghĩa trong tiêu chuẩn dữ liệu thẻ EPC [TDS1.9], Trong kích thước “Cái gì” của sự kiện EPCIS, giá trị của thành phần epc PHẢI là URI [RFC2396] biểu thị danh tính đơn nhất của cấp độ - cá thể cho đối tượng. Khi danh tính đơn nhất là mã điện tử sản phẩm thì thành phần của danh mục PHẢI là URI “danh tính thuần khiết” đối với EPC như quy định ở [TDS1.9], điều 6. Việc triển khai có thể chấp nhận mã định dạng URI khác với EPCs làm giá trị thành phần epc.

7.3.3.3  Thành phần số lượng

Thành phần số lượng là cấu trúc định dạng các đối tượng được phân định bởi mã phân định cấp độ - tầng riêng biệt, cũng như số lượng riêng biệt hoặc số lượng không xác định. Nó có cấu trúc như sau:

Bảng 8 - Cấu trúc định dạng của đối tượng

Tầng EPC là một từ vựng mà các thành phần của nó biểu thị các tầng đối tượng. Tầng EPC là từ vựng của người sử dụng như định nghĩa ở 6.2. Bất kì EPC nào có cấu trúc kết hợp với khái niệm tầng đối tượng có thể tham chiếu như một tầng EPC. Tiêu chuẩn cho GTIN EPCs được nghiên cứu dưới đây.

Một tầng EPC có thể nhằm vào một tầng có số đo cố định hoặc số đo biến thiên. Tầng số đo cố định có các trường hợp có thể đếm được; ví dụ GTIN nhằm vào hộp cát tông có kích cỡ cố định của sản phẩm. Tầng số đo biến thiên có các trường hợp không thể tính được và vì vậy số lượng được quy định như là thước đo vật lý; GTIN nhằm vào dây đồng được bán theo độ dài, còn thảm thì bán theo diện tích của tấm, dầu số lượng lớn lại bán theo dung tích, hoặc sản phẩm tươi sống được bán theo trọng lượng. Bảng sau đây tóm tắt cách các trường số lượng và uom được sử dụng trong mỗi trường hợp:

Bảng 9 - Cách sử dụng các trường số lượng và uom

Các thuộc tính dữ liệu chủ đối với từ vựng tầng EPC chứa bất kì dữ liệu chủ nào được định nghĩa cho các đối tượng được tham chiếu độc lập với EPCIS (ví dụ, dữ liệu danh mục sản phẩm); các định nghĩa của chúng nằm ngoài phạm vi của tiêu chuẩn này.

7.3.3.3.1  UOM

Như quy định ở trên, trường uom của thành phần số lượng có mặt khi nó sử dụng số đo vật lý để xác định số lượng của tầng EPC được quy định. Khi có trường uom, giá trị của nó PHẢI là mã 2 hoặc 3 kí tự cho một đơn vị vật lý được quy định trong cột "Mã chung" của Khuyến nghị UN / CEFACT 20 [CEFACT20], Hơn nữa, mã này PHẢI là mã chứa trong một hàng [CEFACT20] đáp ứng tất cả các tiêu chí sau:

- Cột “Số lượng” chứa một trong các đại lượng sau: chiều dài, diện tích, thể tích hoặc khối lượng.

- Cột “Tình trạng” không chứa “X” (đã hủy) hoặc “D” (không được chấp nhận).

Đối với mục đích của tiêu chí đầu tiên, số lượng phải xuất hiện dưới dạng cụm từ hoàn chỉnh. Ví dụ: "Mét" (MTR) được cho phép, bởi vì số lượng bao gồm chiều dài (trong số các đại lượng khác như chiều rộng, chiều cao, vv). Nhưng không được phép “pound-force per foot” (F17), bởi vì số lượng là lực chia cho chiều dài, không chỉ là chiều dài.

7.3.3.3.2  Giá trị của tầng EPC đối với GTIN

Khi một phần tử từ vựng trong EPCCIass đại diện cho tầng SGTIN EPC được biểu thị bằng một GTIN cụ thể, nó PHẢI là một URI theo dạng sau, như được định nghĩa trong Phiên bản 1.3 và sau này của các tiêu chuẩn dữ liệu thẻ EPC:

urn: epc: idpat: sgtin: CompanyPrefix.ltemRefAndlndicator. *

Khi CompanyPrefix là tiền tố doanh nghiệp GS1 của GTIN (bao gồm cả số 0 đứng đầu) và ItemRefAndlndicator bao gồm chữ số chỉ thị của GTIN theo sau là các chữ số tham chiếu vật phẩm của GTIN.

Phần tử từ vựng EPCCIass trong biểu mẫu này biểu thị tầng đối tượng có EPC là SGTIN (urn: epc: id: sgtin:...) có cùng trường CompanyPrefix và temRefAndIndicator và có bất kì số sê-ri nào (hoặc không có số sê-ri nào).

7.3.3.3.3  Giá trị của tầng EPC đối với GTIN + lô hàng

Khi một phần tử từ vựng trong EPCCIass đại diện cho tầng SGTIN EPC được biểu thị bằng một GTIN cụ thể và lô / đợt, nó PHẢI là một URI ở dạng sau, như được định nghĩa trong [TDS1.9, Phần 6]:

urn: epc: class: Igtin: CompanyPrefix.ltemRefAndlndicator.Lot

Khi CompanyPrefix là tiền tố doanh nghiệp GS1 của GTIN (kể cả số 0 đứng đầu), ItemRefAndlndicator bao gồm chữ số của chỉ số GTIN theo sau là các chữ số tham chiếu vật phẩm của GTIN và Lot là số lô / đợt của lô/đợt cụ thể.

Phần tử từ vựng EPCCIass trong biểu mẫu này biểu thị tầng đối tượng có EPC là SGTIN (urn: epc: id: sgtin:...) có cùng trường CompanyPrefix và ItemRefAndlndicator và thuộc về lô / đợt quy định, bất kể số sê-ri (nếu có).

7.3.3.3.4  Tóm tắt các loại mã phân định (không bắt buộc)

Phần này tóm tắt các mã phân định có thể được sử dụng trong kích thước thứ nguyên "cái gì" của các sự kiện EPCIS. Các quy định kĩ thuật tiêu chuẩn của các mã phân định nằm trong Tiêu chuẩn dữ liệu thẻ EPC [TDS1.9] và từ vựng doanh nghiệp cốt lõi EPC [CBV1.2].

Bảng 10 - Tóm tắt các mã phân định

7.3.4  Kích thước “ở đâu” - điểm đọc và vị trí kinh doanh

Phần này định nghĩa bốn loại liên quan đến khái niệm về thông tin vị trí như được sử dụng trong EPCIS. Hai trong số các loại này là cách đề cập đến "máy đọc" hoặc các thiết bị cảm nhận sự hiện diện của các đối tượng được gắn thẻ EPC bằng cách sử dụng RFID hoặc các phương tiện khác. Điều này thực sự hoàn toàn không được coi là loại "vị trí" đối với mục đích của EPCIS. Chúng được đưa vào tiêu chuẩn này chủ yếu để đối chiếu chúng với các loại vị trí thực (mặc dù một số ứng dụng có thể muốn sử dụng chúng như các trường mở rộng về mặt quan sát, cho mục đích đánh giá/kiểm toán). Hai loại khác là các loại vị trí thực, và được định nghĩa là các loại từ vựng EPCIS.

Các loại máy đọc / vị trí như sau:

Bảng 11 - Các loại máy đọc và vị trí thực

ID điểm đọc và ID điểm kinh doanh là các từ vựng người dùng như được định nghĩa trong Phần 6.2. Một số ngành công nghiệp có thể muốn sử dụng EPC như là các thành phần từ vựng, trong trường hợp này danh tính thuần túy URI như được định nghĩa trong [TDS1.9] PHẢI được sử dụng.”

Không quy định: Minh họa: Ví dụ: trong các ngành công nghiệp được điều hành bởi các quy định kĩ thuật chung của GS1, ID điểm đọc và ID vị trí kinh doanh có thể là SGLN-URI [TDS1.9, Phần 6.3.3] và ID máy đọc vật lý có thể là SGTIN-URI [TDS1.9, Mục 6.3.1].

Nhưng trong mọi trường hợp, các thành phần từ vựng vị trí không yêu cầu phải là EPC.

Không quy định: Giải thích: Cho phép URI không phải EPC đối với các vị trí cho phép các tổ chức tự do sử dụng lại cách đặt tên vị trí hiện tại.

Đối với tất cả các loại sự kiện EPCIS được định nghĩa trong phần 7.2 này, các sự kiện truy cập bao gồm các trường riêng biệt cho Điểm đọc và Vị trí kinh doanh . Trong hầu hết các trường hợp, cả hai trường hợp đều là tùy chọn, do đó vẫn có thể để một ứng dụng truy cập EPCIS chứa một phần thông tin nếu cả hai đều không được biết.

Không quy định: Giải thích: Máy đọc logic và máy đọc vật lý được bỏ qua ở các định nghĩa về các sự kiện EPCIS trong tiêu chuẩn này. Máy đọc vật lý thường không phải là thông tin hữu ích để trao đổi giữa các đối tác. Ví dụ: nếu máy đọc bị trục trặc và được thay thế bằng một máy đọc khác được sản xuất và kiểu giống hệt nhau, thì ID máy đọc vật lý đã thay đổi. Thông tin này ít được các đối tác thương mại quan tâm. Tương tự như vậy, ID máy đọc logic có thể thay đổi nếu tổ chức truy cập thay đổi cách thức thực hiện quy trình kinh doanh cụ thể; một lần nữa, không thường xuyên quan tâm đến một đối tác.

Sự khác biệt giữa Điểm đọc và vị trí kinh doanh có liên quan rất nhiều đến sự phân đôi giữa ngữ nghĩa hồi cứu/hồi tưởng/quá khứ và ngữ nghĩa tiềm năng/viễn cảnh/ tương lai được thảo luận ở trên. Nói chung, Điểm đọc đóng một vai trò trong ngữ nghĩa hồi cứu, trong khi Địa điểm kinh doanh có liên quan đến các báo cáo về tiềm năng. Điều này được thực hiện rõ ràng theo cách mỗi loại vị trí nhập vào các mô tả ngữ nghĩa được cho ở cuối mỗi phần bên dưới xác định một sự kiện truy cập EPCIS.

7.3.4.1  Ví dụ về sự khác biệt giữa điểm đọc và vị trí kinh doanh (Không quy định)

CHÚ DẪN

Hình 7 - Ví dụ về điểm đọc và vị trí kinh doanh

Hình trên cho thấy một trường hợp sử dụng điển hình bao gồm các phòng có cửa cố định ở ranh giới của các phòng. Trong trường hợp này, các điểm Đọc tương ứng với các cửa ra vào (với thiết bị đo lường RFID) và Vị trí kinh doanh tương ứng với các phòng. Lưu ý rằng các Điểm Đọc và Vị trí kinh doanh không tương ứng một - một; tình huống duy nhất mà Điểm Đọc và Vị trí kinh doanh có thể có mối quan hệ 1: 1 là trường hợp bất thường của một căn phòng có một cánh cửa duy nhất, như một buồng kho nhỏ.

Tiếp tục xem xét ví dụ về phòng và cửa, Vị trí kinh doanh thường là loại vị trí quan tâm nhất đối với một ứng dụng kinh doanh, vì nó cho biết căn phòng nào là đối tượng đang ở. Vì vậy, nó có ý nghĩa để yêu cầu kiểm kê một địa điểm kinh doanh như kho phụ Ngược lại, Điểm đọc chỉ ra cửa mà qua đó đối tượng đi vào phòng. Nó không có ý nghĩa để yêu cầu kiểm kê một ô cửa. Mặc dù đôi khi không liên quan đến ứng dụng kinh doanh nhưng Điểm đọc vẫn quan tâm đến phần mềm cấp cao hơn để hiểu quy trình kinh doanh và trạng thái cuối cùng của đối tượng, đặc biệt với tỷ lệ đọc dưới 100%. Lưu ý rằng việc chỉ định đúng vị trí kinh doanh đòi hỏi cả đối tượng được gắn thẻ phải được quan sát tại điểm đọc và hướng chuyển động được xác định chính xác - một lần nữa báo cáo Điểm đọc trong sự kiện sẽ rất có giá trị đối với phần mềm cấp cao hơn.

Một chuỗi cung ứng giống như ví dụ phòng và cửa có thể được biểu diễn bằng biểu đồ trong đó mỗi nút trong biểu đồ biểu diễn một căn phòng có thể tìm thấy đối tượng và mỗi cung đại diện cho một cửa nối hai phòng. Do đó, vị trí kinh doanh tương ứng với các nút của biểu đồ này và các điểm Đọc tương ứng với các cung tròn. Nếu biểu đồ là một chuỗi thẳng, đơn hướng, các vòng cung đi qua bởi một đối tượng nhất định có thể được xây dựng lại từ việc biết các nút; nghĩa là thông tin về Điểm Đọc sẽ không cần thiết cho thông tin Vị trí kinh doanh. Tuy nhiên, trong các tình huống của thế giới thực, các đối tượng có thể theo nhiều đường và di chuyển “ngược” trong chuỗi cung ứng. Trong những tình huống thực tế này, việc cung cấp thông tin Điểm đọc ngoài thông tin Địa điểm kinh doanh có giá trị đối với phần mềm cấp cao hơn.

7.3.4.2  Giải thích các loại máy đọc so với loại vị trí (Không quy định)

Trong bối cảnh EPC, vị trí thuật ngữ đã được sử dụng để biểu thị nhiều điều khác nhau và điều này đã dẫn đến sự nhầm lẫn về ý nghĩa và cách sử dụng thuật ngữ, đặc biệt khi được xem từ góc độ kinh doanh. Sự nhầm lẫn này xuất phát từ một số nguyên nhân:

1. Trong những tình huống mà máy đọc EPC là dạng thiết bị văn phòng, có khuynh hướng tự nhiên để đánh giá máy đọc vị trí, mặc dù điều đó có thể không phải lúc nào cũng hợp lệ nếu có nhiều máy đọc ở một vị trí;

2. Có những tình huống mà máy đọc là dạng thiết bị văn phòng được đặt giữa những gì người kinh doanh sẽ xem xét là các địa điểm khác nhau (chẳng hạn như ở cửa giữa phòng sau và tầng bán hàng của cửa hàng bán lẻ) và do đó không xác định vị trí mà không có chỉ dẫn hướng mà đối tượng được gắn thẻ đang di chuyển;

3. Một máy đọc vật lý đơn có nhiều ăng-ten độc lập, có khả năng định vị địa chỉ có thể được sử dụng để phát hiện các đối tượng được gắn thẻ ở nhiều vị trí được người kinh doanh xem xét;

4. Ngược lại, nhiều hơn một máy đọc có thể được sử dụng để phát hiện các đối tượng được gắn thẻ trong những gì người kinh doanh sẽ xem xét một vị trí duy nhất;

5. Với máy đọc di động, một máy đọc đã cho có thể đọc các đối tượng được gắn thẻ ở nhiều vị trí, có thể sử dụng thẻ “vị trí” hoặc các phương tiện khác để xác định vị trí cụ thể được liên kết với một sự kiện đọc đã cho ;

6. Và cuối cùng, các vị trí mà một bên quan tâm (đối tác thương mại hoặc ứng dụng) có thể không được quan tâm hoặc ủy quyền để xem xét bởi một bên khác, thúc đẩy sự quan tâm bằng cách phân biệt các vị trí.

Chìa khóa để cân bằng các yêu cầu dường như xung đột này là xác định và liên kết các loại vị trí khác nhau, sau đó dựa vào ứng dụng truy cập Chụp EPCIS để ghi lại chúng đúng cách cho một sự kiện truy cập đã cho. Đây là lý do tại sao các sự kiện EPCIS chứa cả một ID điểm đọc và một ID vị trí kinh doanh (hai kiểu vị trí nguyên thủy).

Ngoài ra, trong lịch sử đã có nhiều nhầm lẫn xung quanh sự khác biệt giữa "vị trí" khi cần thiết bởi các ứng dụng cấp độ-EPCIS và nhận dạng của máy đọc. Quy định kĩ thuật EPCIS này xác định vị trí như một cái gì đó khá khác biệt với nhận dạng của máy đọc. Để giúp làm rõ điều này, các loại nhận dạng của máy đọc được xác định ở trên để cung cấp sự tương phản với các định nghĩa về các loại vị trí EPCIS thực. Ngoài ra, các loại nhận dạng của máy đọc có thể tham gia vào EPCIS như “các thuộc tính quan sát” khi một ứng dụng mong muốn giữ lại một bản ghi về những gì máy đọc đóng vai trò quan sát; ví dụ: cho mục đích kiểm toán, (truy cập và chia sẻ “các thuộc tính quan sát” sẽ yêu cầu việc sử dụng các trường mở rộng không được định nghĩa trong tiêu chuẩn này).

7.3.5  Tham số “Tại sao”

Phần này định nghĩa các loại dữ liệu được sử dụng trong tham số "Tại sao" của các loại sự kiện được quy định trong Phần 7.3.5.4.

7.3.5.1  Bước kinh doanh

ID bước kinh doanh là một từ vựng có các thành phần biểu thị các bước trong quy trình kinh doanh. Ví dụ là một mã phân định biểu thị “gửi hàng”. Trường bước kinh doanh của một sự kiện xác định bối cảnh kinh doanh của một sự kiện: bước nào trong quá trình kinh doanh đang diễn ra khiến cho sự kiện đó phải truy cập? ID bước kinh doanh là một ví dụ về từ vựng chuẩn như được định nghĩa trong 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định bước kinh doanh cho phép các tiêu chuẩn GS1 (bao gồm và đặc biệt là Từ vựng kinh doanh cốt lõi GS1) để xác định một số thuật ngữ phổ biến như “gửi hàng” hoặc “nhận hàng”, trong khi đó cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ riêng của họ. Dữ liệu chủ cung cấp thêm thông tin.

Tiêu chuẩn này không định nghĩa các thuộc tính dữ liệu chủ cho mã phân định bước kinh doanh.

7.3.5.2  Bố trí

ID bố trí là một từ vựng có các thành phần biểu thị trạng thái kinh doanh của một đối tượng. Ví dụ là mã phân định biểu thị “thu hồi”. Trường bố trí sự kiện quy định điều kiện kinh doanh của các đối tượng sự kiện, tiếp sau sự kiện. Việc bố trí được giả định là đúng cho đến khi một sự kiện khác biểu thị sự thay đổi của bố trí. Các sự kiện can thiệp không quy định trường bố trí không làm ảnh hưởng đến bố trí của đối tượng. ID bố trí là một ví dụ về từ vựng chuẩn như được định nghĩa trong 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định bố trí cho phép các tiêu chuẩn GS1 (bao gồm và đặc biệt là Từ vựng kinh doanh cốt lõi GS1) đề định nghĩa một số thuật ngữ phổ biến như “thu hồi” hoặc “quá cảnh”. ”, trong khi đó cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ riêng của họ. Dữ liệu chủ có thể cung cấp thêm thông tin.

Tiêu chuẩn này không định nghĩa các thuộc tính dữ liệu chủ cho mã phân định việc bố trí.

7.3.5.3  Giao dịch kinh doanh

Giao dịch kinh doanh xác định một giao dịch kinh doanh cụ thể. Ví dụ về giao dịch kinh doanh là một đơn đặt hàng cụ thể. Thông tin giao dịch kinh doanh có thể được đưa vào trong sự kiện EPCIS để lưu lại sự tham gia của sự kiện trong các giao dịch kinh doanh cụ thể.

Giao dịch kinh doanh được mô tả trong EPCIS theo loại có cấu trúc bao gồm một cặp mã phân định như sau.

Bảng 12 - Giao dịch kinh doanh trong EPCIS theo cấu trúc bao gồm một cập mã phân định

Hai loại từ vựng ID loại giao dịch kinh doanh và ID giao dịch kinh doanh được định nghĩa trong các phần bên dưới

7.3.5.3.1  Loại giao dịch kinh doanh

ID Loại giao dịch kinh doanh là một từ vựng có các thành phần biểu thị một loại giao dịch kinh doanh cụ thể. Ví dụ là mã phân định biểu thị “đơn đặt hàng”. ID Loại giao dịch kinh doanh là ví dụ về Từ vựng chuẩn như được định nghĩa trong 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định loại giao dịch kinh doanh cho phép các tiêu chuẩn GS1 định nghĩa một số thuật ngữ phổ biến như “đơn đặt hàng” trong khi cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ của riêng họ. Dữ liệu chủ có thể cung cấp thêm thông tin.

Tiêu chuẩn này không định nghĩa các thuộc tính dữ liệu chủ cho mã phân định giao dịch kinh doanh.

7.3.5.3.2  ID giao dịch kinh doanh

ID giao dịch kinh doanh là một từ vựng có các thành phần biểu thị các giao dịch kinh doanh cụ thể. Ví dụ là mã phân định biểu thị “Số đơn đặt hàng của Acme Corp 12345678.” ID giao dịch kinh doanh là Từ vựng người sử dụng như được định nghĩa trong 6.2.

Không quy định: Giải thích: URI được sử dụng để cung cấp khả năng mở rộng và cách thức thuận tiện để các tổ chức phân biệt một loại mã phân định giao dịch với một loại khác. Ví dụ: nếu Công ty Acme có đơn đặt hàng (một loại giao dịch kinh doanh) được xác định bằng số gồm 8 chữ số cũng như lô hàng (một loại giao dịch kinh doanh khác) được phân định bằng chuỗi 6 kí tự và hơn nữa. Công ty PostHaste Shipping sử dụng 12 ID theo dõi số, sau đó các ID giao dịch kinh doanh sau đây có thể được liên kết với một EPC cụ thể theo thời gian:

http://transaction.acme. com/po/12345678

http://transaction.acme.com/shipment/34ABC8

urn:posthaste:tracking: 123456789012

(Trong ví dụ này, giả định rằng PostHaste Shipping đã đăng kí tên miền "posthaste" của URN với IANA.) Ứng dụngTruy cập EPCIS có thể truy vấn EPCIS và khám phá cả ba ID giao dịch; sử dụng các URI cung cấp cho ứng dụng một cách để hiểu ID nào quan tâm đến nó.

7.3.5.4  Nguồn và đích

Nguồn hoặc Đích được sử dụng để cung cấp bối cảnh kinh doanh bổ sung khi sự kiện EPCIS là một phần của việc chuyển giao kinh doanh; có nghĩa là, một quá trình trong đó có sự chuyển giao quyền sở hữu, trách nhiệm và / hoặc quyền nuôi đối tượng vật lý hoặc đối tượng số hóa.

Trong nhiều trường hợp việc chuyển giao kinh doanh đòi hỏi một số bước kinh doanh riêng lẻ (và vì vậy một số sự kiện EPCIS) để thực thi; ví dụ, vận chuyển tiếp theo là nhận hoặc một chuỗi phức tạp hơn như xếp tải → khởi hành → vận chuyển → đến nơi → dỡ tải → nhận hàng. Điểm đọc (ReadPoint) và vị trí kinh doanh (BusinessLocation) trong tham số "ở đâu" của các sự kiện EPCIS này chỉ ra vị trí vật lý đã biết tại mỗi bước của quá trình. Ngược lại, nguồn và đích có thể được sử dụng để chỉ ra các bên và / hoặc vị trí là điểm cuối dự định của việc chuyển giao kinh doanh. Trong chuyển giao kinh doanh đa bước, một số hoặc tất cả các sự kiện EPCIS có thể mang Nguồn và Đích, và thông tin sẽ giống nhau đối với tất cả các sự kiện trong một lần chuyển nhất định.

Nguồn và Đích cung cấp cách thức được tiêu chuẩn hóa để cho biết các bên và / hoặc vị trí thực tế có liên quan đến việc chuyển giao, bổ sung thông tin giao dịch kinh doanh (ví dụ: đơn đặt hàng, hóa đơn, v.v.) có thể được giới thiệu bởi các thành phần giao dịch kinh doanh.

Nguồn hoặc đích được mô tả trong EPCIS theo loại có cấu trúc bao gồm một cặp mã phân định, như sau.

Bảng 13 - Nguồn hoặc đích trong EPCIS theo loại có cấu trúc bao gồm một cặp mã phân định

Hai loại từ vựng ID loại nguồn đích và ID nguồn đích được định nghĩa trong các phần bên dưới.

7.3.5.4.1  ID loại nguồn / đích

ID loại nguồn đích là một từ vựng có các thành phần biểu thị một loại nguồn hoặc đích chuyển giao kinh doanh cụ thể. Ví dụ là một mã phân định biểu thị “bên sở hữu”. Id loại nguồn đích là một ví dụ về Từ vựng tiêu chuẩn như được định nghĩa trong Phần 6.2.

Không quy định: Giải thích: Sử dụng từ vựng mở rộng cho mã phân định loại nguồn / đích cho phép các tiêu chuẩn GS1 định nghĩa một số thuật ngữ phổ biến như “bên sở hữu” trong khi cho phép các tập đoàn công nghiệp và người sử dụng cuối cùng riêng lẻ định nghĩa các thuật ngữ của riêng họ. Dữ liệu chủ có thể cung cấp thêm thông tin.

Tiêu chuẩn này không quy định các thuộc tính dữ liệu chủ cho các mã phân định loại nguồn / đích.

7.3.5.4.2  ID nguồn / đích

ID nguồn đích là một từ vựng có các yếu tố biểu thị các nguồn và đích cụ thể. Một ví dụ là mã phân định biểu thị "công ty Acme (một bên sở hữu)" ID nguồn đích là một từ vựng người sử dụng như được định nghĩa trong phần 6.2.

Không quy định: Giải thích: URI được sử dụng để cung cấp khả năng mở rộng và cách thức thuận tiện cho các tổ chức phân biệt một loại mã phân định nguồn hoặc đích với một loại khác.

7.3.6  Dữ liệu thực thể / Lô chủ (ILMD)

Dữ liệu thực thể / Lô chủ (ILMD) là dữ liệu mô tả một thực thể cụ thể của đối tượng vật lý hoặc số hóa hoặc một lô / lô cụ thể của đối tượng được sản xuất trong theo mẻ / lô. ILMD bao gồm một tệp các thuộc tính được mô tả nhằm cung cấp thông tin về một hoặc nhiều đối tượng hoặc lô cụ thể. Nó tương tự như dữ liệu chủ thông thường, cũng bao gồm một tệp các thuộc tính được mô tả nhằm cung cấp thông tin về các đối tượng. Nhưng trong khi các thuộc tính dữ liệu chủ có cùng giá trị cho một tầng đối tượng lớn (ví dụ, đối với tất cả các đối tượng có GTIN), giá trị của các thuộc tính ILMD có thể khác nhau đối với nhiều nhóm đối tượng nhỏ hơn (ví dụ: một mẻ duy nhất hoặc lô), và có thể khác nhau cho mỗi đối tượng (ví dụ, khác nhau cho từng trường hợp).

Ví dụ về thuộc tính dữ liệu chủ là trọng lượng và kích thước vật lý của các thương phẩm được phân định bằng GTIN cụ thể. Các giá trị này giống nhau đối với tất cả các vật phẩm dùng chung GTIN đó. Một ví dụ về ILMD là ngày hết hạn của một thương phẩm dễ hư hỏng. Không giống như dữ liệu chủ, ngày hết hạn không giống nhau đối với tất cả các thương phẩm có cùng GTIN; về nguyên tắc, mỗi vật phẩm có thể có ngày hết hạn khác nhau tùy thuộc vào thời điểm sản xuất. Các ví dụ khác về ILMD bao gồm ngày sản xuất, nơi sản xuất, trọng lượng và các kích thước vật lý khác của thương phẩm có số đo thay đổi, thông tin thu hoạch cho các sản phẩm nông nghiệp, v.v.

ILMD, giống như dữ liệu chủ thông thường, được dự định là tĩnh tại trong suốt vòng đời của đối tượng. Ví dụ, ngày hết hạn của một mặt hàng dễ hư hỏng hoặc trọng lượng của một mặt hàng có số đo biến đổi không thay đổi trong suốt vòng đời của thương phẩm, mặc dù các thương phẩm khác nhau có cùng GTIN có thể có giá trị khác nhau về ngày hết hạn và trọng lượng. HMD không được sử dụng để biểu diễn thông tin thay đổi trong vòng đời của một đối tượng, ví dụ, nhiệt độ hiện tại của một vật thể khi nó di chuyển qua chuỗi cung ứng.

Mặc dù có các tiêu chuẩn (như GDSN) cho việc đăng kí và phổ biến dữ liệu chủ thông thường thông qua chuỗi cung ứng, nhưng các tiêu chuẩn và các hệ thống phổ biến ILMD chưa có. Vì lý do này, EPCIS cho phép ILMD được thực hiện trực tiếp trong một số sự kiện EPCIS nhất định. Tính năng này chỉ nên được sử dụng khi không có hệ thống riêng biệt để phổ biến ILMD.

ILMD cho một đối tượng cụ thể được xác định khi đối tượng đó tồn tại. Do đó, HMD chỉ có thể được đưa vào trong ObjectEvents với ADD hành động (Mục 7.4.1.2) và trong TranstormationEvents (Mục 7.4.6). Trong trường hợp TransformationEvent, ILMD áp dụng cho các đầu ra biến đổi, không áp dụng cho các đầu vào.

Cấu trúc của ILMD được định nghĩa trong tiêu chuẩn EPCIS này bao gồm một tập các thuộc tính được đặt tên, có các giá trị thuộc bất kì loại nào. Trong liên kết XML (Phần 9.5), lược đồ XML cung cấp một danh sách các phần tử XML không giới hạn có tên và nội dung của bất kì phần tử nào. Các tài liệu khác được xếp chồng lên trên EPCIS có thể xác định các phần từ dữ liệu ILMD cụ thể; xem Phần 6.3. Theo cách này, ILMD tương tự như các phần mở rộng EPCIS cấp độ- sự kiện, nhưng tách biệt để nhấn mạnh rằng ILMD áp dụng cho toàn bộ vòng đời của các đối tượng, trong khi phần mở rộng EPCIS cấp độ - sự kiện chỉ áp dụng cho sự kiện cụ thể đó.

7.4  Mô-đun loại sự kiện cốt lõi - sự kiện

7.4.1  EPCISEvent

EPCISEvent là một loại cơ sở chung cho tất cả các sự kiện EPCIS. Tất cả các loại sự kiện cụ thể hơn trong các phần sau là các tầng con của EPCISEvent. Loại cơ sở chung này chỉ có các trường sau đây.

Bảng 14 - Các trường cho loại cơ sở chung

7.4.1.1  Giải thích về eventTimeZoneOffset (không quy định)

Trường eventTimeZoneOffset không cần thiết để hiểu tại thời điểm nào một sự kiện xảy ra. Điều này là do trường eventTime là loại Time, được định nghĩa trong Mục 7.3 là “ngày và thời gian theo cách không phụ thuộc múi giờ”. Ví dụ, trong liên kết XML (Phần 9.5) trường eventTime được biểu diễn như một thành phần của loại xsd: dateTime và phần 9.5 hơn nữa quy định rằng XML phải bao gồm một bộ định thời gian vùng. Vì vậy, XML cho eventTime rõ ràng phân định một cách rõ ràng thời điểm theo thời gian tuyệt đối, và nó không cần thiết phải tham khảo eventTimeZoneOffset để hiểu những gì thời điểm đó là.

Mục đích của eventTimeZoneOffset là cung cấp bối cảnh kinh doanh bổ sung về sự kiện, cụ thể là để xác định chênh lệch múi giờ nào có hiệu lực vào thời điểm đó và địa điểm đã truy cập. Ví dụ: thông tin này có thể hữu ích để xác định xem một sự kiện có diễn ra trong giờ làm việc hay không, để trình bày sự kiện cho một người theo định dạng phù hợp với giờ địa phương, v.v. Thông tin bù giờ múi giờ địa phương không nhất thiết có sẵn từ eventTime, bởi vì không có yêu cầu rằng người quy định múi giờ trong trình diễn XML của eventTime là bù trừ múi giờ địa phương nơi sự kiện được truy cập. Ví dụ: sự kiện diễn ra lúc 8 giờ sáng theo Giờ chuẩn miền Đông Hoa Kì có thể có trường XML eventTime được viết 08: 00-05: 00 (sử dụng Giờ chuẩn miền Đông Hoa Kỳ) hoặc 13: 00Z (sử dụng UTC) hoặc thậm chí 07: 00-06: 00 (sử dụng Giờ chuẩn Trung tâm Hoa Kỳ). Hơn nữa, các bộ xử lý XML không được yêu cầu bởi [XSD2] để giữ lại và trình bày cho các ứng dụng bộ định thời gian múi giờ là một phần của trường xsd: dateTime, và do đó, người quy định múi giờ trong trường eventTime có thể không có sẵn cho các ứng dụng. Các cân nhắc tương tự sẽ áp dụng cho các ràng buộc khác (không phải XML) của mô-đun Các loại sự kiện cốt lõi. Ví dụ, một liên kết nhị phân giả định có thể đại diện cho các giá trị Thời gian dưới dạng mili giây tương đối so với nửa đêm UTC vào ngày 1 tháng 1 năm 1970 - một lần nữa, xác định rõ ràng một khoảnh khắc trong thời gian tuyệt đối, nhưng không cung cấp bất kì thông tin nào về múi giờ địa phương. Vì những lý do này, eventTimeZoneOffset được cung cấp dưới dạng trường sự kiện bổ sung.

7.4.1.2  ErrorDeclaration

Khi một sự kiện có chứa một phần tử ErrorDeclaration, nó chỉ ra rằng sự kiện này có ngữ nghĩa đặc biệt: thay vì các ngữ nghĩa thông thường, khẳng định rằng nhiều thứ khác nhau đã xảy ra và những điều khác nhau là đúng theo sau sự kiện này, ngữ nghĩa của sự kiện này khẳng định rằng những xác nhận trước đó là lỗi. Một sự kiện có chứa thành phần ErrorDeclaration PHẢI không giống với một sự kiện nào trước đó, “không giống hệt” nghĩa là tất cả các trường của sự kiện khác với thành phần ErrorDeclaration và giá trị của recordTime chính xác bằng với sự kiện trước đó. (Lưu ý rằng nó bao gồm trường eventID: eventID khai báo lỗi sẽ bằng với eventID của sự kiện trước hoặc null nếu eventID của sự kiện trước là null. Đây là trường hợp duy nhất mà cùng một eventID non-null có thể xuất hiện trong hai sự kiện.) Ngữ nghĩa của một sự kiện chứa phần tử ErrorDeclaration là tất cả các xác nhận được ngụ ý bởi sự kiện trước được coi là sai, như khai báo được quy định. Sự kiện trước đó không được sửa đổi bằng bất kì cách nào và các truy vấn tiếp theo sẽ trả lại cả sự kiện trước và khai báo lỗi.

Một phần tử ErrorDeclaration chứa các trường sau:

Bảng 15 - Các trường trong phần tử ErrorDeclaration

Một phần tử ErrorDeclaration KHÔNG được sử dụng nếu có một cách để mô hình hóa tình huống thực tế như một sự kiện bình thường (có nghĩa là, sử dụng một sự kiện không chứa một phần tử ErrorDeclaration).

7.4.1.3  Sử dụng các khai báo lỗi (Không bắt buộc)

Sự kiện EPCIS ghi lại việc hoàn thành một bước của quá trình kinh doanh. Một quá trình kinh doanh được mô hình hóa bằng cách chia nhỏ nó thành một loạt các bước, và mô hình hóa từng bước như một sự kiện EPCIS. Hiệu ứng ròng là tập hợp tất cả các sự kiện liên quan đến một đối tượng cụ thể (thường được gọi là "dấu vết") phải chỉ rõ lịch sử và trạng thái hiện tại của đối tượng đó, bằng cách diễn giải các sự kiện theo ngữ nghĩa được quy định trong tiêu chuẩn này và các tiêu chuẩn từ vựng có liên quan.

Đôi khi, nó được phát hiện ra rằng một sự kiện được ghi lại trước đó không phản ánh chính xác những gì đã xảy ra trong thế giới thực. Trong các trường hợp như vậy, như đã nêu trong 6.1, các sự kiện trước đó sẽ không bao giờ bị xóa hoặc sửa đổi. Thay vào đó, các sự kiện bổ sung được ghi lại có hiệu lực là dấu vết hoàn chỉnh (bao gồm các sự kiện mới và tất cả các sự kiện trước đó kể cả sự kiện không chính xác) phản ánh chính xác lịch sử và trạng thái hiện tại, như đã nêu trong nguyên tắc trên.

Ưu tiên đến với các sự kiện bổ sung là công nhận rằng việc phát hiện ra một sự kiện sai và sửa chữa nó chính là một quá trình kinh doanh có thể được mô hình hoá bằng cách tạo ra các sự kiện EPCIS phù hợp. Trong hầu hết các trường hợp, điều này được thực hiện bằng cách sử dụng các sự kiện EPCIS từ Mô-đun các loại sự kiện cốt lõi như được quy định từ 7.4.1 đến 7.4.6, sử dụng từ vựng phù hợp.

Ví dụ 1: Công ty X ghi lại sự kiện EPCIS khẳng định rằng số sê-ri 101, 102 và 103 của một số sản phẩm đã được chuyển đến Công ty Y. Công ty Y nhận lô hàng và tìm số sê-ri 104 cùng với số sê-ri 101, 102, 103. khi thảo luận với Công ty X, đã được sự đồng ý là nối tiếp 104 đã thực sự được vận chuyển và sự kiện vận chuyển bị lỗi. Xử lý: Công ty X ghi lại một sự kiện EPCIS mới khẳng định rằng số sê-ri 104 đã được chuyển đi, với thông tin theo ngữ cảnh tương tự như sự kiện ban đầu.

Ví dụ 2: Công ty X ghi lại sự kiện EPCIS khẳng định rằng số sê-ri 101, 102 và 103 của một số sản phẩm đã được chuyển đến Công ty Y. Công ty Y nhận lỗ hàng và chỉ tìm thấy số sê-ri 101, 102. Khi thảo luận với Công ty X, đã được sự đồng ý là 103 nối tiếp đã không được giao mà vẫn nằm trong kho hàng tồn của Công ty X. Họ đồng ý trả lại tiền thanh toán cho sản phẩm thứ ba.

Xử lý: Công ty X ghi lại một sự kiện EPCIS mới khẳng định rằng lô hàng nối tiếp 103 bị hủy.

Trong ví dụ đầu tiên, sự kiện bổ sung sử dụng cùng một từ vựng kinh doanh như là từ đầu tiên. Trong ví dụ thứ hai, từ vựng đặc biệt liên kết với quá trình làm mất hiệu lực một lô hàng được sử dụng, nhưng nó vẫn là ngữ nghĩa EPCIS “bình thường” theo nghĩa là nó mô hình sự hoàn thành một bước của quá trình kinh doanh được xác định rõ. Điều này phản ánh thực tế rằng hành động khắc phục hậu quả chính nó là một quá trình kinh doanh, và do đó có thể được mô hình hóa như một sự kiện EPCIS.

Trong một số trường hợp, hoặc là không thể (hoặc là không mong muốn) để khắc phục lịch sử của một đối tượng bằng cách tạo ra một sự kiện EPCIS mới với ngữ nghĩa thông thường (nghĩa là, với ngữ nghĩa được quy định trong 7.4.1 đến 7.4.6).

Ví dụ 3: Công ty X ghi lại một sự kiện EPCIS để khẳng định rằng số sê-ri 101 của sản phẩm X đã bị hủy. Sự kiện này là một sự kiện đối tượng như được quy định trong phần 7.4.2 với hành động = HỦY/DELETE. Sau đó nó được phát hiện ra rằng nối tiếp 101 vẫn còn trong kho, không bị phá hủy. Một sự kiện bình thường không thể được sử dụng để sửa đổi lịch sử, bởi vì ngữ nghĩa của hành động HỦY/DELETE cho một sự kiện đối tượng xác định rằng "các đối tượng ... không nên xuất hiện trong các sự kiện tiếp theo."

Ví dụ 4: Công ty X ghi lại sự kiện EPCIS khẳng định rằng một số sản phẩm đã được giao, cho biết Đơn đặt hàng 123 là giao dịch kinh doanh theo tham số "tại sao". Công ty Y nhận được sản phẩm và ghi lại một sự kiện tiếp nhận. Ngay sau đó, người ta phát hiện ra rằng tham chiếu đơn đặt hàng trong sự kiện vận chuyển là sai: PO 456 thay vì 123. Điều này có thể được khắc phục bằng sự kiện EPCIS thông thường bởi Công ty X ghi lại sự kiện “hủy lô hàng” và sau đó là sự kiện “giao hàng”, với PO # chính xác. Nhưng điều này là không mong muốn từ quan điểm của dấu vết tổng thể, đặc biệt là cho rằng đã có một sự kiện tiếp nhận.

Để phù hợp với các tình huống như vậy, Mô-đun các loại sự kiện cốt lõi cung cấp một cơ chế để khẳng định rằng các xác nhận được thực hiện bởi một sự kiện trước là do lỗi. Các ngữ nghĩa này chỉ có thể được sử dụng khi một sự kiện quy định chính xác các điều kiện giống như một sự kiện thông thường trước đó, để xác nhận lỗi có thể liên quan đến sự kiện trước đó. Sự kiện như vậy được gọi là "sự kiện khai báo lỗi".

Trong Ví dụ 3 ở trên, sự kiện khai báo lỗi có nghĩa là số sê-ri 101 của sản phẩm X không bị hủy. Trong Ví dụ 4 ở trên, sự kiện khai báo lỗi có nghĩa là một lô hàng có PO 123 là bối cảnh không xảy ra và một sự kiện bổ sung (“sự kiện khắc phục”) sẽ cho biết rằng lô hàng có PO 456 đã xảy ra. Điều này khá giống với mô hình Ví dụ 4 sử dụng một sự kiện “hủy bỏ”, ngoại trừ việc xác nhận một lô hàng được thực hiện theo PO 123 sau đó bị hủy bỏ, sự kiện khai báo lỗi chỉ xác nhận rằng xác nhận PO 123 là sai.

Một sự kiện khai báo lỗi được cấu tạo bằng cách gộp một phần ErrorDeclaration. Cụ thể, với sự kiện E1, một sự kiện khai báo lỗi E2 có hiệu lực là khai báo các xác nhận của E1 có lỗi là một cấu trúc sự kiện có nội dung giống với E1, nhưng với thành phần ErrorDeclaration được gộp vào. Ví dụ, khai báo lỗi cho sự kiện "hủy bỏ" trong Ví dụ 3 cũng là một sự kiện đối tượng với hành động = HỦY/DELETE, nhưng với thành phần ErrorDeclaration được gộp vào. Nói chung, để khai báo sự kiện E bị lỗi, một sự kiện mới được ghi lại giống với sự kiện E ngoại trừ thành phần ErrorDeclaration cũng được gộp vào (và thời gian ghi sẽ khác nhau).

Có ba lý do tại sao các sự kiện khai báo lỗi trong EPCIS được biểu diễn theo cách này. Thứ nhất, một ID sự kiện không được yêu cầu để biểu thị sự kiện sai lỗi, điều này có nghĩa là không cần phải có một ID sự kiện cho mọi sự kiện để cung cấp cho việc khai báo lỗi có thể xảy ra trong tương lai. ID sự kiện có sẵn để liên kết sự kiện khai báo lỗi với một sự kiện khắc phục, nhưng không bao giờ cần thiết để sử dụng ID sự kiện. Thứ hai, bất kì truy vấn EPCIS nào khớp với một sự kiện cũng sẽ khớp với khai báo lỗi cho sự kiện đó, nếu nó tồn tại. Điều này có nghĩa là các ứng dụng truy cập EPCIS không yêu cầu logic đặc biệt để nhận biết các khai báo lỗi, nếu chúng tồn tại. Thứ ba, nếu một ứng dụng truy cập EPCIS nhận được một sự kiện khai báo lỗi và vì một lý do nào đó không có một bản sao của sự kiện ban đầu (sai), thì không cần phải lấy lại sự kiện ban đầu vì mọi thông tin trong sự kiện đó cũng có mặt trong sự kiện khai báo lỗi.

7.4.1.4  Khớp khai báo lỗi với sự kiện ban đầu (không bắt buộc)

Như đã thảo luận trong 7.4.1.2, một sự kiện khai báo lỗi có nội dung giống hệt với sự kiện ban đầu (sai), ngoại trừ chính thành phần ErrorDeclaration và thời gian ghi. Một trong những lợi ích của phương pháp này là khi một ứng dụng truy cập EPCIS gặp phải một khai báo lỗi, không cần thiết phải truy xuất sự kiện ban đầu (sai), vì tất cả thông tin trong sự kiện đó cũng có mặt trong sự kiện khai báo lỗi ứng dụng Truy cập EPCIS đã có.

Tuy nhiên, có thể có các tình huống trong đó một ứng dụng Truy cập EPCIS hoặc ứng dụng truy cập EPCIS mong muốn xác nhận sự tồn tại của sự kiện ban đầu (sai) bằng cách truy vấn nó. Cách duy nhất để nhận ra rằng một sự kiện là sự kiện ban đầu phù hợp với một khai báo lỗi là xác nhận rằng tất cả các phần tử dữ liệu trong các sự kiện (lưu thành phần ErrorDeclaration và thời gian ghi) phù hợp. Xem [EPCISGuideline] để biết các phương pháp được đề xuất để truy vấn trong trường hợp này.

7.4.2  ObjectEvent (phân tầng của EPCISEvent)

Một ObjectEvent truy cập thông tin về một sự kiện liên quan đến một hoặc nhiều đối tượng vật lý hoặc số hóa được xác định bởi các mã phân định cấp độ cá thể (EPC) hoặc cấp độ - tầng (tầng EPC). Hầu hết các ObjectEvents được hình dung để đại diện cho các quan sát thực tế của các đối tượng, nhưng nó có thể được sử dụng cho bất kì sự kiện nào mà ứng dụng truy cập muốn xác nhận về các đối tượng, bao gồm, ví dụ truy cập thực tế rằng một quan sát dự kiến không xảy ra.

Mặc dù có nhiều hơn một EPC và / hoặc EPC Class có thể xuất hiện trong một ObjectEvent, không có mối quan hệ hay liên kết nào giữa các đối tượng đó được ngụ ý ngoài sự trùng hợp ngẫu nhiên khi có các sự kiện giống nhau trong thế giới thực.

Trường hành động của ObjectEvent mô tả mối quan hệ của sự kiện với vòng đời của các đối tượng và mã phân định của chúng được đặt tên trong sự kiện. Đặc biệt:

Bảng 16 - Ý nghĩa của giá trị hành động của ObjectEvent

Bảng 17 - Mô tả trường

Lưu ý rằng trong liên kết XML (9.3), quantityList, sourceList, destinationList và ilmd xuất hiện trong vùng mở rộng tiêu chuẩn, để duy trì tính tương thích về trong tương lai với EPCIS 1.0.

Ngữ nghĩa trong quá khứ

- Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra đối với các đối tượng được xác định bởi epcList và quantityList tại eventTime tại vị trí readPoint.

- (Nếu hành động là BỔ SUNG) Các EPC trong epcList được ủy nhiệm (ban hành lần đầu tiên).

- (Nếu hành động là BỔ SUNG) Số lượng quy định của các trường hợp EPC Class trong quantityList được tạo ra (hoặc một số lượng chưa biết, cho mỗi QuantityElement trong đó bỏ qua giá trị đại lượng được).

- (Nếu hành động là HỦY BỎ) Các EPC trong epcList đã được ngừng hoạt động (đã ngừng hoạt động sau này).

- (Nếu hành động là HỦY BỎ) Số lượng quy định của các trường hợp EPC Class trong quantityList không còn tồn tại (hoặc một số lượng chưa biết, cho mỗi QuantityElement trong đó giá trị số lượng bị bỏ qua).

- (Nếu hành động là BỔ SUNG và một bizTransactionList không trống được chỉ định) Một hiệp hội tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList và các đối tượng được xác định trong epcList và quantityList.

- (Nếu hành động là QUAN SÁT và một bizTransactionList không trống được chỉ định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu hành động là HỦY BỎ và một bizTransactionList không trống được chỉ định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

- (Nếu danh sách đích không trống) Sự kiện này diễn ra trong ngữ cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa kì vọng:

- (Nếu hành động là BỔ SUNG) Các đối tượng được phân định bởi các mã phân định mức - cá thể trong epcList có thể xuất hiện trong các sự kiện tiếp theo.

- (Nếu hành động là BỔ SUNG) Các đối tượng được phân định bởi các mã phân định cấp độ - tầng trong quantityList có thể xuất hiện trong các sự kiện tiếp theo.

- (Nếu hành động là HỦY BỎ) Các đối tượng được phân định bởi các mã phân định mức - cá thể trong epcList sẽ không xuất hiện trong các sự kiện tiếp theo.

- (Nếu hành động là HỦY BỎ) Tổng số các đối tượng được phân định bởi các mã phân định mức - tầng trong quantityList có thể xuất hiện trong các sự kiện tiếp theo đã được giảm theo số lượng được quy định trong quantityList (hoặc bởi một đại lượng chưa biết, cho mỗi QuantityElement giá trị bị bỏ qua).

- (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng được phản định bởi epcList và quantityList được mô tả bằng cách sắp xếp.

- (Nếu bố trí bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết được phân định bởi epcList và quantity List không thay đổi.

- (Nếu bizLocation được quy định) Các đối tượng được phân định bởi epcList và quantityList đang ở vị trí kinh doanh bizLocation.

- (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng được phân định bởi epcList và quantityList không xác định.

- (Nếu hành động là BỔ SUNG và ilmd không trống) Các đối tượng được phân định bởi epcList và quantityList được mô tả bởi các thuộc tính trong ilmd.

- (Nếu hành động là BỔ SUNG và một bizTransactionList không trống được quy định) Một sự kết hợp tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList và các đối tượng được phân định trong epListListand quantity List.

Không bắt buộc: Giải thích: Trong trường hợp hành động là BỔ SUNG và một bizTransactionList không trống được quy định, hiệu ứng ngữ nghĩa tương đương với việc có một ObjectEvent không có bizTransactionList cùng với một ransactionEvent có bizTransactionList và tất cả các giá trị trường giống như ObjectEvenf. Tuy nhiên, lưu ý rằng một ObjectEvent với một bizTransactionList không trống không gây ra một TransactionEvent được trả về từ một truy vấn.

7.4.3  AggregationEvent (tầng con của EPCISEvent)

Loại sự kiện AggregationEvent mô tả các sự kiện áp dụng cho các đối tượng đã được tổ hợp với nhau. Trong một sự kiện như vậy, có một tập hợp các đối tượng "chứa" đã được tổ hợp trong thực thể "chứa" có nghĩa là để phân định tổ hợp chính nó.

Loại sự kiện này được dự định sẽ sử dụng để "tổ hợp", nghĩa là một liên kết có mối quan hệ vật lý mạnh mẽ giữa các đối tượng chứa và thực thể chứa các đối tượng đó, tất cả chúng sẽ chiếm cùng một vị trí, cùng một lúc, cho đến khi chúng phân tách. Một ví dụ về một tổ hợp là nơi các trường hợp được nạp vào một pallet và được thực hiện như một đơn vị. Loại AggregationEvent không dành cho các liên kết yếu hơn như hai pallet là một phần của cùng một lô hàng, nhưng các pallet có thể không luôn ở đúng vị trí giống nhau tại cùng một thời điểm. (TransactionEvent có thể thích hợp cho các trường hợp như vậy.) Ngữ nghĩa cụ thể hơn có thể được quy định tùy thuộc vào Bước kinh doanh.

Trường hành động của một AggregationEvent mô tả mối quan hệ của sự kiện với vòng đời của tổ hợp.

Bảng 18 - Ý nghĩa của giá trị hành động của AggregationEvent

Kiểu AggregationEventEvent bao gồm các trường tham chiếu đến một "cha mẹ" đơn (thường là thực thể "chứa") và một hoặc nhiều "đứa con" (thường là các đối tượng "chứa"). Yêu cầu mã phân định cha mẹ khi hành động là BỔ SUNG hoặc LOẠI BỎ, nhưng tùy chọn khi hành động là QUAN SÁT.

Không bắt buộc: Giải thích: Mã phân định cha mẹ được sử dụng khi hành động là BỔ SUNG để có cách đề cập đến liên kết trong các sự kiện tiếp theo khi hành động bị LOẠI BỎ. Mã phân định cha mẹ là tùy chọn khi hành động là QUAN SÁT vì cha mẹ không phải lúc nào cũng được biết trong quá trình quan sát trung gian. Ví dụ, một quá trình nhận pallet có thể dựa vào các thẻ RFID để xác định EPC của các trường hợp trên pallet, nhưng có thể không có thẻ RFID cho pallet (hoặc nếu có, nó có thể không đọc được).

AggregationEvent được dự định để chỉ ra tổ hợp giữa các đối tượng, và do đó các đứa con được phân định bởi các tầng EPC và / hoặc EPC. Tuy nhiên, thực thể cha mẹ không nhất thiết là một đối tượng vật lý hoặc số hóa tách biệt với bản thân tổ hợp và do đó cha mẹ được xác định bởi một URI tùy ý, có thể là EPC, nhưng CÓ THỂ là một mã phân định khác được rút ra từ một từ vựng riêng phù hợp.

Không bắt buộc: Giải thích: Trong nhiều hoạt động sản xuất, ví dụ, thông thường khi tạo một tải một vài bước trước EPC để giao tải. Trong những tình huống như vậy, mã số theo dõi nội bộ (thường được gọi là “mã số tấm giấy phép” hoặc LPN) được thừa nhận tại thời điểm tải được tạo và điều này được sử dụng cho đến điểm giao hàng. Tại điểm giao hàng, mã SSCC (là một EPC) được thừa nhận. Trong EPCIS, điều này sẽ được mô hình hóa bởi (a) một AggregateEvent có hành động như là BỔ SUNG tại thời điểm tải được tạo ra, và (b) một AggregationEvent thứ hai với hành động như là BỔ SUNG tại thời điểm SSCC được thừa nhận (liên kết đầu tiên cũng có thể bị vô hiệu hóa thông qua một AggregationEvent với hành động như là LOẠI BỎ tại thời điểm này). AggregationEvent đầu tiên sẽ sử dụng LPN làm mã phân định cha mẹ (được thể hiện bằng cách mô tả URI phù hợp; xem 6.4), trong khi đó AggregationEvent thứ hai sẽ sử dụng SSCC (một loại EPC) làm mã phân định cha mẹ, bằng cách thay đổi parentID.

Bảng 19 - Các trường của AggregationEvent

Lưu ý rằng trong liên kết XML (9.3), childQuantityList, sourceList và destinationList xuất hiện trong vùng mở rộng tiêu chuẩn, để duy trì tính tương thích trong tương lai với EPCIS 1.0.

Ngữ nghĩa hồi tưởng:

- Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra liên quan đến việc chứa thực thể parentID và các đối tượng chứa trong childEPCs và childQuantityList, tại eventTime và location readPoint.

- (Nếu hành động là BỔ SUNG) Các đối tượng được phân định trong childEPC và childQuantityList được tổ hợp với parentID của thực thể chứa.

- (Nếu hành động là LOẠI BỎ và childEPC hoặc childQuantityList không trống) Các đối tượng được phân định trong childEPC và childQuantityList được phân tách khỏi parentID.

- (Nếu hành động là LOẠI BỎ và cả childEPC và childQuantityList đều trống) Tất cả các đối tượng chứa được phân tách khỏi parentID của thực thể chứa.

- (Nếu hành động là BỔ SUNG và một bizTransactionList không trống được quy định) Một liên kết tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng được phân định trong childEPC và childQuantityList, và parentID của thực thể chứa.

- (Nếu hành động là QUAN SÁT và một bizTransactionList không trống được quy định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu hành động là LOẠI BỎ và một bizTransactionList không trống được quy định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

- (Nếu destinationList không trống) Sự kiện này diễn ra trong bối cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa viễn cảnh:

- (Nếu hành động là BỔ SUNG) Một tổ hợp tồn tại giữa parentID của thực thể chứa và các đối tượng được chứa trong childEPCs và childQuantityList.

- (Nếu hành động là LOẠI BỎ và childEPC hoặc childQuantityList không trống) Một tổ hợp không còn tồn tại giữa parentID của thực thể chứa và các đối tượng được chứa được xác định trong childEPCs và childQuantityList.

- (Nếu hành động là LOẠI BỎ và cả childEPC và childQuantityList đều trống) Một tổ hợp không còn tồn tại giữa parentID của thực thể chứa và bất kì đối tượng được chứa nào.

- (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng được phân định trong parentID, childEPC và childQuantityList được mô tả bằng cách bố trí.

- (Nếu bố trí bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng trong parentID, childEPCs và childQuantityList không thay đổi.

- (Nếu bizLocation được quy định) Các đối tượng liên kết với các đối tượng trong parentID, childEPCs và childQuantityList đang ở bizLocation của vị trí kinh doanh.

- (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng liên kết với các đối tượng trong parentID, childEPCs và childQuantityList không xác định.

(Nếu hành động là BỔ SUNG và một bizTransactionList không trống được quy định) Một sự liên kết tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong childEPCs và childQuantityList và parentID của thực thể chứa (nếu được quy định).

Không quy định: Giải thích: Trong trường hợp hành động là BỔ SUNG và một bizTransactionList không rỗng được quy định, hiệu ứng ngữ nghĩa tương đương với việc có một AggregationEvent không có bizTransactionList cùng với một TransactionEvent có bizTransactionList và tất cả các giá trị trường giống như AggregationEvent. Tuy nhiên, lưu ý rằng một AggregationEvent với một bizTransactionList không rỗng không gây ra TransactionEvent được trả về từ một truy vấn.

Không quy định: Lưu ý: Nhiều tình huống ngữ nghĩa không hợp lệ có thể được thể hiện bằng cách sử dụng không đúng tổ hợp. Ví dụ, các đối tượng tương tự có thể được cung cấp cho nhiều cha mẹ trong cùng một khoảng thời gian bởi các hoạt động BỔ SUNG riêng biệt mà không có sự loại bỏ xen kẽ. Tương tự như vậy một đối tượng có thể được xác định là một đứa con của ông bà hoặc thậm chí của chính nó. Một tổ hợp không tồn tại có thể bị LOẠI BỎ. Các tình huống này không thể được phát hiện về mặt cú pháp và nói chung một kho lưu trữ EPCIS riêng lẻ có thể không có đủ thông tin để phát hiện chúng. Do đó, tiêu chuẩn này không đưa ra các điều kiện lỗi này.

7.4.4  QuantityEvent (phân tầng của EPCISEvent) - KHÔNG DÙNG

Một QuantityEvent truy cập sự kiện diễn ra liên quan đến một số lượng quy định của một tầng đối tượng. Loại sự kiện này có thể được sử dụng, ví dụ, để báo cáo mức tồn kho của sản phẩm.

Kể từ EPCIS 1.1, QuantityEvent không được chấp nhận. Thay vào đó, các ứng dụng sử dụng một ObjectEvent có chứa một hoặc nhiều QuantityListElements. Một QuantityEvent tương đương với một ObjectEvent có chứa một EPCList rỗng và một QuantityListElement duy nhất chứa một số lượng và không có uom.

Bảng 20 - Các trường trong phần tử QuantityEvent

Lưu ý rằng bởi vì EPCCIass luôn biểu thị đơn vị đóng gói cụ thể (ví dụ: trường hợp 12 thương phẩm), không cần trường "đơn vị đo lường" rõ ràng. Đơn vị đo luôn là tầng đối tượng được biểu thị bằng epcClass như được định nghĩa trong dữ liệu chính cho tầng đối tượng đó.

Ngữ nghĩa hồi tưởng

- Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra liên quan đến đối tượng về số lượng của tầng EPC epcClass tại eventTime tại vị trí readPoint.

- (Nếu một bizTransactionList không trống được quy định) Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

Ngữ nghĩa viễn cảnh:

- (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng được mô tả bởi bố trí.

- (Nếu bố trí bị bỏ qua) Tình trạng kinh doanh của các đối tượng không thay đổi.

- (Nếu bizLocation được quy định) Các đối tượng đang ở vị trí kinh doanh bizLocation.

- (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng không xác định.

7.4.5  TransactionEvent (phân tầng của EPCISEvent)

Loại sự kiện TransactionEvent mô tả sự kết hợp hoặc phân tách các đối tượng vật lý hoặc số hóa cho một hoặc nhiều giao dịch kinh doanh. Mặc dù các loại sự kiện khác có trường bizTransactionList tùy chọn có thể được sử dụng để cung cấp bối cảnh cho một sự kiện, TransactionEvent được sử dụng để khai báo một cách rõ ràng rằng các đối tượng nhất định đã được liên kết hoặc hủy liên kết với một hoặc nhiều giao dịch kinh doanh là một phần của sự kiện.

Trường hành động của TransactionEvent mô tả mối quan hệ của sự kiện với vòng đời của giao dịch.

Bảng 21 - Ý nghĩa của giá trị hành động của TransactionEvent

Bảng 22 - Các trường của TransactionEvent

Lưu ý rằng trong liên kết XML (9.3), quantityList, sourceList và destinationList

xuất hiện trong vùng mở rộng tiêu chuẩn, để duy trì tính tương thích sau này với EPCIS 1.0.

Không bắt buộc: Giải thích: Việc sử dụng tên trường parentID trong cả TransactionEvent và AggregationEvent (7.2.10) không biểu thị sự giống nhau về chức năng hoặc ngữ nghĩa. Nói chung, một TransactionEvent mang cùng một thông tin phân định đối tượng như một ObjectEvent, đó là một danh sách các EPC và / hoặc QuantityElements. Tất cả các trường thông tin khác (bizTransactionList, bizStep, bizLocation, vv) áp dụng như nhau và thống nhất cho tất cả các đối tượng được quy định có hay không các đối tượng được quy định trong trường epcList và quantitylist hoặc nếu trường parentID tùy chọn cũng được cung cấp.

Không bắt buộc: TransactionEvent cung cấp cách thức mô tả sự liên kết hoặc phân tách các giao dịch kinh doanh với các đối tượng. Trường parentID trong TransactionEvent làm rõ một EPC cụ thể hoặc mã phân định khác như là đối tượng ưu tiên hoặc ban đầu nhưng không hàm ý mối quan hệ vật lý của bất kì loại nào, cũng như bất kì huyết thống hoặc thế hệ nào được ngụ ý bởi chính TransactionEvent. Chỉ các cá thể AggregationEvent mô tả các mối quan hệ cha-con thực sự và các mối quan hệ cha-con có huyết thống. Điều này có thể được thấy bằng cách so sánh ngữ nghĩa của AggregationEvent trong 7.2.10 với ngữ nghĩa của TransactionEvent dưới đây.

Ngữ nghĩa hồi tưởng

- Một sự kiện được mô tả bởi bizStep (và bất kì trường nào khác) diễn ra liên quan đến các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong epcList và quantityList, và parentID thực thể chứa (nếu có quy định), tại eventTime và readPoint vị trí.

- (Nếu hành động là BỔ SUNG) Các đối tượng trong epcList và quantityList và parentID thực thể chứa (nếu có quy định) được liên kết với các giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu hành động là LOẠI BỎ và epcList hoặc quantityList không trống) Các đối tượng trong epcList, quantityList, và parentID thực thể chứa (nếu có quy định) đã bị hủy liên kết khỏi các giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu hành động là LOẠI BỎ, cả hai epcList và quantityList đều trống, và parentID bị bỏ qua) Tất cả các đối tượng đã bị hủy liên kết khỏi các giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

- (Nếu danh sách đích không trống) Sự kiện này diễn ra trong bối cảnh cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa viễn cảnh:/kì vọng.

- (Nếu hành động là BỔ SUNG) Một liên kết tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong epcList và quantityList, và parentID thực thể chứa (nếu có quy định).

- (Nếu hành động là LOẠI BỎ và epcList hoặc quantityList không trống) Một liên kết không còn tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList, các đối tượng trong epcList và quantityList, và parentID thực thể chứa (nếu có quy định).

- (Nếu hành động là LOẠI BỎ, cả epcList và quantity List đều trống, và parentID bị bỏ qua) Một liên kết không còn tồn tại giữa các giao dịch kinh doanh được liệt kê trong bizTransactionList và bất kì đối tượng nào.

- (Nếu bố trí được quy định) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng trong epcList và quantityList và parentID thực thể chứa (nếu có quy định) được mô tả theo bố trí.

- (Nếu bố trí bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết với các đối tượng trong epcList và quantityList và parentID thực thể chứa (nếu có quy định) là không thay đổi.

- (Nếu bizLocation được quy định) Các đối tượng liên kết với các đối tượng trong epcList, quantityList, và chứa parentID thực thể chứa (nếu có quy định) đang ở bizLocation vị trí kinh doanh.

- (Nếu bizLocation bị bỏ qua) Vị trí doanh nghiệp của các đối tượng liên kết với các đối tượng trong epcList và quantityList và chứa thực thể parentID (nếu có quy định) là không xác định.

7.4.6  TransformationEvent (phân tầng của EPCISEvent)

Một TransformationEvent truy cập thông tin về một sự kiện trong đó một hoặc nhiều đối tượng vật lý hoặc số hóa được quy định bởi các mã phân định cấp độ-cá thể (EPC) hoặc cấp độ- tầng (EPC Class) được tiêu thụ toàn bộ hoặc một phần như đầu vào và một hoặc nhiều đối tượng được phân định bởi mã phân định cấp độ-cá thể (EPC) hoặc cấp độ - tầng (EPC Class) được tạo thành đầu ra. TranstormationEvent truy cập mối quan hệ giữa các đầu vào và đầu ra, sao cho bất kì đầu vào nào có thể đã đóng góp theo một cách nào đó cho mỗi đầu ra.

Một số quá trình chuyển đổi kinh doanh diễn ra trong một thời gian dài, và do đó, nó phù hợp hơn để đại diện cho chúng như một loạt các sự kiện EPCIS. Một TransfomationID có thể được bao gồm trong hai hoặc nhiều TransformationEvents để liên kết chúng lại với nhau. Khi các sự kiện chia sẻ một TranstormationID giống hệt nhau, ý nghĩa là các đầu vào cho bất kì sự kiện nào trong số những sự kiện đó có thể đã đóng góp theo một cách nào đó cho mỗi đầu ra trong bất kì sự kiện tương tự nào.

Bảng 23 - Các trường của TransformationEvent

Nếu conversionID bị bỏ qua, thì một TransformationEvent PHẢI gồm ít nhất một đầu vào (tức là, ít nhất một inputEPCList và inputQuantityList không rỗng) VÀ ít nhất một đầu ra (tức là, ít nhất một outputEPCList và outputQuantityList không rỗng). Nếu kể cả transformationID, thì một TranstormationEvent PHẢI bao gồm ít nhất một đầu vào HOẶC ít nhất một đầu ra (hoặc cả hai). Vế sau cung cấp khả năng về sự chuyển đổi được mô tả bởi một số sự kiện liên kết bởi một transformationID chung, bất kì một sự kiện nào cũng chỉ có thể BỔ SUNG cho đầu vào hoặc trích xuất khỏi đầu ra.

Ngữ nghĩa hồi tưởng:

- Một chuyển đổi được mô tả bởi bizStep (và bất kì trường nào khác) đã diễn ra với các đối tượng đầu vào được phân định bởi inputEPCList và inputQuantityList và các đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList, tại eventTime tại vị trí readPoint.

- Sự kiện này diễn ra trong bối cảnh giao dịch kinh doanh được liệt kê trong bizTransactionList.

- (Nếu transformationID bị bỏ qua ) Bất kì đối tượng đầu vào nào được phân định bởi inputEPCList và inputQuantityList của sự kiện này có thể đã đóng góp cho mỗi đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList của sự kiện này.

- (Nếu bao gồm cả transformationID) Bất kì đối tượng đầu vào nào được phân định bởi inputEPCList và inputQuantityList của sự kiện này, cùng với các đối tượng đầu vào được phân định bởi inputEPCList và inputQuantityList của các sự kiện khác có cùng giá trị transformationID, có thể đã đóng góp cho mỗi đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList của sự kiện này, cũng như cho mỗi đối tượng đầu ra được phân định bởi outputEPCList và outputQuantityList của các sự kiện khác có cùng giá trị trasformationID.

- (Nếu sourceList không trống) Sự kiện này diễn ra trong bối cảnh của một chuyển giao kinh doanh có điểm cuối có nguồn gốc được mô tả bởi các nguồn được liệt kê trong sourceList.

- (Nếu danh sách đích không trống) Sự kiện này diễn ra trong bối cảnh của một giao dịch kinh doanh có điểm cuối kết thúc được mô tả bởi các đích được liệt kê trong DestinationList.

Ngữ nghĩa viễn tưởng/kì vọng:

- Các đối tượng được phân định bởi các mã phân định mức- cá thể trong outputEPCList có thể xuất hiện trong các sự kiện tiếp theo.

- Các đối tượng được phân định bởi các mã phân định cấp độ-mức trong outputQuantityList có thể xuất hiện trong các sự kiện tiếp theo.

- (Nếu disposition được quy định) Điều kiện kinh doanh của các đối tượng được phân định bởi outputEPCList và outputQuantityList được mô tả bởi disposition.

- (Nếu disposition bị bỏ qua) Điều kiện kinh doanh của các đối tượng liên kết được phân định bởi outputEPCList và outputQuantityList không xác định.

- (Nếu bizLocation được quy định) Các đối tượng được phân định bởi outputEPCList và outputQuantityList đang ở bizLocation vị trí kinh doanh.

- (Nếu bizLocation bị bỏ qua) Vị trí kinh doanh của các đối tượng được phân định bởi outputEPCList và outputQuantityList không xác định.

- (Nếu ilmd không trống) Các đối tượng được phân định bởi outputEPCList và outputQuantityList được mô tả bởi các thuộc tính trong ilmd.

8  Tầng dịch vụ

Điều này bao gồm các quy định kĩ thuật tiêu chuẩn của các mô-đun trong tầng dịch vụ. Đồng thời, các mô-đun này xác định ba giao diện: Giao diện truy vấn EPCIS, Giao diện kiểm soát truy vấn EPCIS và Giao diện gọi lại truy vấn EPCIS. (Hai giao diện sau được gọi chung là Giao diện Truy vấn EPCIS.) Sơ đồ dưới đây minh họa mối quan hệ giữa các giao diện này, mở rộng theo sơ đồ trong điều 2 (sơ đồ này là không bắt buộc):

Hình 8 - Mối quan hệ giữa các giao diện

Dưới đây, các dịch vụ được quy định định bằng cách sử dụng Kí hiệu sơ đồ tầng UML Các sơ đồ tầng UML được sử dụng cho mục đích này có thể chứa các giao diện có các hoạt động, chứ không phải các trường hoặc các liên kết.

VÍ DỤ Biểu đồ định nghĩa dịch vụ cho Service 1

Biểu đồ này cho thấy một định nghĩa dịch vụ cho Service1, cung cấp ba hoạt động. Operation1 lấy hai đối số, arg11 và arg12, có các kiểu ArgType11 và ArgType12, tương ứng, và trả về một giá trị kiểu ReturnType1. Operation2 lấy một đối số nhưng không trả lại kết quả. Operations không nhận bất kì đối số nào nhưng trả về một giá trị kiểu ReturnType3.

Trong các mô tả UML, Kí hiệu << điểm mở rộng >> phân định một nơi mà các triển khai PHẢI cung cấp khả năng mở rộng thông qua việc bổ sung các hoạt động mới.

Cơ chế mở rộng PHẢI cung cấp cho cả hai phần mở rộng được ủy quyền bởi các nhà cung cấp các sản phẩm tuân thủ EPCIS và các phần mở rộng do GS1 quy định thông qua các phiên bản tương lai của tiêu chuẩn này hoặc thông qua các quy định kĩ thuật mới.

Trong trường hợp các ràng buộc WSDL tiêu chuẩn, các điểm mở rộng được thực hiện đơn giản bằng cách cho phép bổ sung các hoạt động bổ sung.

8.1  Mô đun hoạt động chụp lõi

Môđune hoạt động Capture Core cung cấp các hoạt động mà các sự kiện cốt lõi có thể được gửi từ một ứng dụng Capture EPCIS. Trong phần này, từ “khách hàng” đề cập đến một ứng dụng truy cập EPCIS và “dịch vụ EPCIS” đề cập đến một hệ thống triển khai giao diện truy vấn EPCIS.

8.1.1  Xác nhận và ủy quyền

Một số ràng buộc của Giao diện truy vấn EPCIS cung cấp phương tiện, đối với Dịch vụ EPCIS để xác nhận số phân định của khách hàng, đối với khách hàng để xác nhận số phân định của Dịch vụ EPCIS hoặc cả hai. Quy định kĩ thuật của các phương tiện để xác nhận được cho trong quy định kĩ thuật của từng ràng buộc. Nếu Dịch vụ EPCIS xác nhận số phân định của khách hàng, việc thực hiện CÓ THỂ sử dụng số phân định khách hàng để đưa ra các quyết định ủy quyền như được mô tả bên dưới. Hơn nữa, việc thực hiện CÓ THỂ ghi lại số phân định khách hàng với dữ liệu đã thu thập, để sử dụng trong các quyết định ủy quyền tiếp theo nhờ hệ thống thực hiện các Giao diện Truy vấn EPCIS, như được mô tả trong 8.2.2.

Do sự đơn giản của Giao diện truy vấn EPGIS, các điều khoản ủy quyền rất đơn giản để nêu rõ: cụ thể là, một triển khai có THỂ sử dụng số phân định khách hàng đã được xác nhận để quyết định liệu hoạt động truy cập có được phép hay không.

Không bắt buộc: Giải thích: Các đối tác thương mại sẽ luôn sử dụng các ràng buộc cung cấp xác nhận số phân định khách hàng hoặc xác nhận lẫn nhau khi sử dụng các giao diện EPCIS để chia sẻ dữ liệu qua các ranh giới của tổ chức. Các ràng buộc không cung cấp xác nhận được dự kiến sẽ chỉ được sử dụng trong một tổ chức duy nhất trong các tình huống mà không cần xác nhận để đáp ứng các yêu cầu bảo mật nội bộ.

8.1.2  Dịch vụ truy cập

Giao diện truy cập chỉ chứa một phương pháp duy nhất, truy cập, lấy một đối số duy nhất và không trả về kết quả nào. Việc triển khai giao diện truy vấn EPCIS PHẢI chấp nhận từng thành phần của danh sách đối số là một EPCISEvent còn hiệu lực hoặc loại phụ của chúng theo quy định kĩ thuật này.Việc triển khai CÓ THỂ chấp nhận các loại sự kiện khác thông qua việc mở rộng của nhà cung cấp. Sự đơn giản của giao diện này thừa nhận một loạt các ràng buộc, bao gồm các ràng buộc kiểu hàng đợi tin nhắn đơn giản.

Không bắt buộc: Giải thích: “Các ràng buộc loại hàng đợi của tin nhắn” có nghĩa như sau. Các doanh nghiệp thường sử dụng công nghệ “bus tin nhắn” để kết nối các thành phần hệ thống phản tán khác nhau. Một bus tin nhắn cung cấp một kênh đáng tin cậy để giao hàng trong các tin nhắn từ một người gửi đến một người nhận. (Mối quan hệ giữa người gửi và người nhận có thể là điểm-điểm (một tin nhắn "xếp hàng") hoặc một người đến nhiều người thông qua cơ chế xuất bản / đăng kí (một tin nhắn "chủ đề").) Giao diện truy vấn EPCIS chỉ đơn giản là chỉ định một kênh bus tin nhắn cụ thể cho mục đích cung cấp các sự kiện EPCIS từ một ứng dụng truy cập EPCIS đến một Kho lưu trữ EPCIS hoặc đến một ứng dụng Truy cập EPCIS theo Giao diện Gọi lại Truy vấn EPCIS. Mỗi tin nhắn sẽ có một dung lượng chứa một hoặc nhiều sự kiện EPCIS (được tuần tự hóa thông qua một số ràng buộc ở Tầng Định nghĩa Dữ liệu, ví dụ: một liên kết XML). Do đó, mỗi lần truyền / phân phối một tin nhắn tương ứng với một hoạt động “truy cập” duy nhất.

Thao tác truy cập ghi lại một hoặc nhiều sự kiện EPCIS, thuộc bất kì loại nào.

Bảng 24 - Mô tả đối số

Giá trị trả về:

(không có)

Các ràng buộc cụ thể của Giao diện truy vấn EPCIS trong điều 10 sử dụng cấu trúc tài liệu EPCIS được định nghĩa trong 9.5 để mang danh sách các sự kiện EPCIS được truy cập. Một tài liệu EPCIS có thể chứa dữ liệu chủ trong tiêu đề tài liệu. Việc thực hiện Giao diện truy vấn EPCIS phù hợp với tiêu chuẩn này CÓ THỂ chọn để lưu lại dữ liệu chủ hoặc CÓ THỂ chọn để bỏ qua nó - việc bố trí dữ liệu chủ nhận được thông qua Giao diện truy vấn EPCIS không được quy định theo tiêu chuẩn EPCIS. Tương tự như vậy, một hệ thống thực hiện Giao diện truy vấn EPCIS có thể cung cấp phương tiện để truy cập dữ liệu chủ bằng cách nhận một tài liệu dữ liệu chủ EPCIS (9.7) nhưng tiêu chuẩn EPCIS không yêu cầu sự hỗ trợ này.

Mặt khác, bất kì dữ liệu chủ của cá thể / lô nào được thực hiện trong phần ILMD của sự kiện PHẢI được truy cập như một phần của sự kiện, như là sự thật cho bất kì thành phần dữ liệu nào trong sự kiện EPCIS. Dữ liệu chủ như vậy PHẢI có khả năng truy vấn được bằng cách sử dụng các tham số truy vấn của SimpleEventQuery được quy định trong 8.2.7.1, nhưng không yêu cầu thực hiện để làm cho dữ liệu chủ trong phần HMD của sự kiện có sẵn cho truy vấn bằng SimpleMasterDataQuery được quy định trong 8.2.7.2.

Triển khai giao diện truy cập PHẢI hoặc truy cập tất cả các sự kiện được quy định trong hoạt động truy cập đã cho hoặc không truy cập tất cả các sự kiện trong hoạt động đó. Đó là, việc thực hiện KHÔNG ĐƯỢC có khả năng thành công một phần mà một số sự kiện trong danh sách được truy cập còn những những sự kiện khác thì không.

Lý do tại sao hoạt động truy cập bị lỗi là vệc thực hiện cụ thể. Ví dụ về các lý do lỗi có thể xảy ra bao gồm:

- Đầu vào cho hoạt động truy cập không được định dạng tốt hoặc không phù hợp với các yêu cầu cú pháp của ràng buộc cụ thể đang được sử dụng, bao gồm cả tính hợp lệ của lược đồ cho các ràng buộc cụ thể sử dụng các lược đồ XML được định nghĩa trong điều 9.

- Khách hàng không được phép thực hiện thao tác truy cập.

- Các giới hạn triển khai cụ thể được vượt quá về số lượng sự kiện trong một thao tác truy cập, tổng số sự kiện được lưu trữ, tần suất truy cập v.v...

- Các quy tắc cụ thể về thực thi liên quan đến nội dung của các sự kiện, hoặc trong sự cô lập hoặc có tham chiếu đến các sự kiện đã truy cập trước đó, đều bị vi phạm. Lưu ý rằng các quy tắc như vậy có thể phù hợp trong một hệ thống khép kín khi sử dụng EPCIS được điều chỉnh bởi một tiêu chuẩn ứng dụng cụ thể, nhưng có thể không phù hợp trong một hệ thống mở được thiết kế đề xử lý bất kì dữ liệu EPCIS nào. Quy tắc loại này có thể giới hạn khả năng tương tác nếu chúng quá hẹp.

- Lỗi tạm thời, chẳng hạn như tạm thời không có máy chủ hoặc mạng.

8.2  Mô-đun hoạt động truy vấn cốt lõi

Mô đun hoạt động truy vấn cốt lõi cung cấp hai giao diện, được gọi là Giao diện kiểm soát truy vấn EPCIS và Giao diện gọi lại truy vấn EPCIS, theo đó dữ liệu EPCIS có thể được truy xuất bằng một ứng dụng truy cập EPCIS. Giao diện kiểm soát truy vấn EPCIS xác định phương tiện đối với ứng dụng truy cập EPCIS và đối tác thương mại để thu thập dữ liệu EPCIS sau khi truy cập từ bất kì nguồn nào, thường là bằng cách tương tác với một kho lưu trữ EPCIS. Nó cung cấp phương tiện cho ứng dụng truy cập EPCIS để truy xuất dữ liệu theo yêu cầu và cũng có thể nhập đăng kí cho truy vấn thường trực. Các kết quả truy vấn thường trực được gửi đến ứng dụng truy cập EPCIS thông qua Giao diện gọi lại truy vấn EPCIS. Trong phần này, từ “khách hàng” đề cập đến một ứng dụng truy cập EPCIS và "dịch vụ EPCIS" đề cập đến một hệ thống thực hiện Giao diện kiểm soát truy vấn EPCIS, và ngoài ra cung cấp thông tin cho khách hàng thông qua Giao diện gọi lại truy vấn EPCIS.

8.2.1  Xác nhận

Một số ràng buộc của Giao diện kiểm soát truy vấn EPCIS cung cấp phương tiện đối với Dịch vụ EPCIS để xác nhân số phân định của khách hàng, đối với khách hàng để xác nhận số phân định của Dịch vụ EPCIS hoặc cả hai. Quy định kĩ thuật của các phương tiện để xác nhận được cho trong quy định kĩ thuật của từng ràng buộc. Nếu Dịch vụ EPCIS xác nhận số phân định của khách hàng, việc thực hiện CÓ THỂ sử dụng số phân định khách hàng để đưa ra các quyết định ủy quyền như được mô tả trong phần tiếp theo.

Không bắt buộc: Giải thích: Các đối tác thương mại sẽ luôn sử dụng các ràng buộc cung cấp xác nhận số phân định khách hàng hoặc xác nhận lẫn nhau khi sử dụng các giao diện EPCIS để chia sẻ dữ liệu qua các ranh giới của tổ chức. Các ràng buộc không cung cấp xác nhận cho dự kiến sẽ chỉ sử dụng trong một tổ chức duy nhất trong các tình huống mà không cần xác nhận để đáp ứng các yêu cầu bảo mật nội bộ.

8.2.2  Ủy quyền

Dịch vụ EPCIS có thể chỉ muốn cung cấp quyền truy cập vào một tập hợp con thông tin, tùy thuộc vào số phân định của khách hàng yêu cầu. Tình huống này thường xảy ra trong các trường hợp giữa các doanh nghiệp mà khách hàng yêu cầu thuộc về một tổ chức khác với tổ chức có dịch vụ EPCIS, nhưng cũng có thể phát sinh trong các tình huống nội bộ doanh nghiệp.