EPCIS 2.0 for Cold Chain — A Practical Guide to Sensor Data Standards

If you have been following this series, you already know the problem. Our first editorial explored how South Africa’s cold chain IoT landscape is fragmented across incompatible monitoring platforms, each speaking its own proprietary language. Our second piece examined how blockchain and traceability solutions depend entirely on having standardised data underneath — and how most current implementations skip that foundation entirely.

This article is about the standard that fills the gap.

EPCIS 2.0, published by GS1 and ratified in June 2022, is the global standard for capturing and sharing supply chain event data — including sensor readings like temperature, humidity, and location. It is not theoretical. It is deployed in production systems across multiple industries, it has been adopted as an ISO standard (ISO/IEC 19987:2024), and it was designed specifically for use cases like cold chain traceability.

This is not a developer manual. It is a practical orientation for operations managers, IT leads, compliance officers, and anyone evaluating how to move from fragmented, proprietary temperature data toward something standardised, shareable, and future-proof. If you are a South African cold chain operator wondering what EPCIS means for your business, this guide is for you.

EPCIS 2.0 in Five Minutes

EPCIS stands for Electronic Product Code Information Services. The name is a holdover from its origins in RFID and barcode systems, but the standard has evolved well beyond that. Today, EPCIS is GS1’s flagship data-sharing standard for supply chain visibility — and it does not require RFID, EPC codes, or any specific hardware to use.

The core idea is simple. Every time something meaningful happens in a supply chain — a product is packed, shipped, received, stored, inspected — that event gets recorded in a standardised format. Each EPCIS event answers five fundamental questions:

• What was involved? A specific product, pallet, container, or shipment identified by a standardised code (GS1 GTIN, SSCC, or other identifier).
• When did it happen? A precise timestamp recorded in UTC with timezone offset.
• Where did it happen? A standardised location identifier (GS1 GLN — Global Location Number) pinpointing the facility, dock, or zone.
• Why did it happen? The business context — was this a shipping event, a receiving event, a storage observation, a quality inspection? This uses the Core Business Vocabulary (CBV), a companion standard defining approximately 41 standardised business step codes (like “shipping,” “receiving,” “storing,” “inspecting”) and disposition codes (like “in_transit,” “sellable_not_accessible,” “damaged”).
• How was the condition? This is the dimension that changed everything for cold chain. Added in version 2.0, the “How” dimension captures sensor data — temperature readings, humidity levels, light exposure, gas concentrations — directly within supply chain events.

EPCIS defines five event types that serve as building blocks for modelling any supply chain process.

• ObjectEvent records something happening to one or more identified objects — the most common type for cold chain monitoring.
• AggregationEvent records packing relationships — individual items into cases, cases onto pallets.
• TransactionEvent links events to business documents like purchase orders or invoices.
• TransformationEvent records manufacturing processes where inputs become outputs.
• AssociationEvent, new in version 2.0, records loose associations between objects such as attaching a sensor device to a pallet.

Critically, EPCIS 2.0 uses JSON-LD (JSON for Linked Data) as its data format and defines a REST API for capturing and querying events. This matters because it makes EPCIS accessible to any modern software development team. Previous versions relied exclusively on XML and web services — technologies that created high barriers to entry. JSON-LD and REST APIs are the standard building blocks of modern web applications, which means any technology provider serving the cold chain market can realistically implement EPCIS 2.0 support.

The sensorElementList — Cold Chain’s Key Feature

Before version 2.0, EPCIS could tell you that a shipment was received at a cold store at 14:30 on Tuesday. It could not tell you what the temperature was when it arrived, what it was during transit, or whether a door was opened en route. That information lived in separate monitoring systems — usually locked in proprietary formats that could not be easily shared with trading partners.

• The sensorElementList changes that. It is a structured data element that can be attached to any EPCIS event, embedding sensor readings directly into the supply chain record. The structure has two key components.
• sensorMetadata captures context about the measurement: when the measurement period started, when it ended, which device recorded it, and the device’s metadata (such as calibration status or firmware version). This is the information auditors and compliance officers need to verify the data’s integrity.
• sensorReport captures the actual readings: what was measured (temperature, humidity, illuminance, gas concentration), the observed values (including minimum, maximum, mean, and standard deviation over the measurement period), and the unit of measure using standardised codes (CEL for Celsius, A93 for relative humidity percentage, and so on).

To make this concrete, here is what EPCIS sensor data looks like in practice — formatted for readability rather than as raw data structures.

Example 1: Temperature Compliance Proof During Cold Storage

This represents an observation of chilled pharmaceutical products in a validated cold room:

Event Type: ObjectEvent
Action: OBSERVE
Event Time: 2025-02-07T08:00:00+02:00
Business Step: storing
Disposition: active
Read Point: GS1 GLN identifying the cold room location
EPC List: SSCC identifying the specific pallet

Sensor Element:

• Metadata Start: 2025-02-06T20:00:00+02:00
• Metadata End: 2025-02-07T08:00:00+02:00
• Device: Calibrated logger serial number and model
• Sensor Report — Type: Temperature
• Min Value: 2.1
• Max Value: 4.8
• Mean Value: 3.4
• Unit: CEL (Celsius)

This single event proves that a specific pallet was stored in a specific location over a twelve-hour period and that the temperature remained within the +2°C to +8°C pharmaceutical range throughout. It includes the device identity for calibration traceability and the precise time window — everything a SAHPRA GDP audit would require.

Example 2: Temperature Excursion During Transport

This represents a cold chain breach detected during road transport:

Event Type: ObjectEvent
Action: OBSERVE
Event Time: 2025-02-07T11:45:00+02:00
Business Step: transporting
Disposition: non_sellable_returnable
Read Point: GPS coordinates or last-known location identifier

Sensor Element:

• Metadata Start: 2025-02-07T11:30:00+02:00
• Metadata End: 2025-02-07T11:45:00+02:00
• Sensor Report — Type: Temperature
• Value: 9.3
• Max Value: 9.3
• Unit: CEL (Celsius)

The disposition code “non_sellable_returnable” immediately signals that this is an excursion event. The reading of 9.3°C exceeds the +8°C maximum for pharmaceutical products and the +5°C maximum for most R638 chilled food categories. Because this data is in a standardised format, it can trigger automated alerts, feed directly into quality management systems, and provide an immutable compliance record — without anyone manually extracting data from a proprietary logger platform.

Example 3: Multi-Sensor Shipment (Temperature, Humidity, Door Events)

For high-value or sensitive shipments, EPCIS supports multiple sensor reports within a single event:

Event Type: ObjectEvent
Action: OBSERVE
Event Time: 2025-02-07T14:00:00+02:00
Business Step: transporting
Read Point: Vehicle/container identifier

Sensor Element 1 — Temperature:

• Min Value: -19.2
• Max Value: -17.8
• Unit: CEL
• (Frozen product within acceptable range)

Sensor Element 2 — Relative Humidity:

• Value: 88
• Unit: A93 (percent)

Sensor Element 3 — Door Status:

• Type: BooleanState
• Value: false
• Component: Door sensor
• (Door closed — no breach detected)

This composite event captures a complete environmental snapshot: temperature within range, humidity appropriate for frozen storage, and door integrity confirmed. For export shipments passing through PPECB inspection, this kind of multi-dimensional data provides far richer evidence than a single temperature reading from a data logger download.

How sensorElementList Maps to SA Requirements

The practical relevance becomes clear when you map EPCIS sensor capabilities to the specific regulatory requirements South African operators face.

• R638 temperature categories translate directly to sensorReport temperature values with defined acceptable ranges. When R638 requires chilled meat at ≤ +4°C, the EPCIS equivalent is a sensorReport with type Temperature, a maximum value of 4.0, and unit CEL. The standard provides the same precision — it just does it in a machine-readable format that every system in the supply chain can understand.
• SAHPRA GDP continuous monitoring requirements are addressed by time-series sensorElement entries. GDP requires continuous temperature monitoring with documented evidence of control — exactly what a sequence of EPCIS ObjectEvents with sensorElementList data provides. The sensorMetadata fields for device identity and calibration information directly support SANAS calibration traceability requirements.
• PPECB export documentation connects through EPCIS events with sensor data attached to shipping business steps. When the PPECB confirms product temperature and container conditions during loading, that inspection translates to an EPCIS ObjectEvent at the “shipping” business step with sensorElementList data capturing the verified temperatures. The chain of EPCIS events from packhouse through cold store to port creates the documented cold chain history that export certification requires.

Mapping EPCIS to South African Cold Chain Operations

The following table maps specific SA regulatory and operational requirements to their EPCIS 2.0 equivalents. These are the actual data elements the standard provides for each use case.

SA Requirement	EPCIS Element	Example Value
R638 chilled transport (≤ +4°C for raw meat/poultry/fish)	sensorReport type: Temperature, maxValue	maxValue: 4.0, uom: CEL
R638 frozen storage (-18°C or colder)	sensorReport type: Temperature, maxValue	maxValue: -18.0, uom: CEL
R638 dairy products (≤ +5°C)	sensorReport type: Temperature, maxValue	maxValue: 5.0, uom: CEL
SAHPRA GDP pharmaceutical monitoring (+2°C to +8°C)	Continuous sensorElement entries with device calibration metadata	minValue: 2.0, maxValue: 8.0, uom: CEL, device: calibrated logger ID
PPECB export temp verification at loading	ObjectEvent at bizStep “shipping” with sensorElementList	Verified product and container temperatures at port
DALRRD export certification traceability	Linked chain of EPCIS events from origin to port	ObjectEvents, AggregationEvents across supply chain
SANAS calibration traceability	sensorMetadata device identification fields	Device serial, calibration date, accreditation reference
Retailer supplier compliance (e.g., CGCSA codes)	EPCIS events shared via standard API with trading partners	Standard REST API query returning certified event data

Where EPCIS Adds Value Versus Current Practice

Most SA cold chain operators currently manage temperature compliance through a combination of PDF temperature reports downloaded from proprietary logger platforms, manual data extraction for compliance documentation, and retailer-specific reporting formats that differ from one customer to the next.

The result is that the same temperature data gets manually re-entered, reformatted, or re-exported multiple times as it moves between trading partners. A transport operator downloads data from their monitoring platform, generates a PDF, emails it to the cold store, which manually records the arrival temperature in their own system, which then generates a different report for the retailer’s quality team.

EPCIS replaces this with standardised, machine-readable events that any authorised system can capture, query, and process automatically. The temperature reading that a sensor captures in a truck in Johannesburg can flow to a cold store management system in Durban, a quality platform at the retailer’s head office, and an export certification system at the PPECB — all using the same data format, the same API, and the same vocabulary. No re-entry. No reformatting. No incompatible exports.

This is not about replacing monitoring hardware. Your sensors, loggers, and IoT devices continue doing what they do. EPCIS is the language they use to share what they have captured — across companies, platforms, and regulatory systems.

Integration Patterns for SA Operators

Adopting EPCIS 2.0 does not require ripping out your existing monitoring infrastructure. There are three practical integration patterns, each suited to different starting points.

Pattern 1: Retrofit — Existing Platform Exports to EPCIS

This is the most practical path for operators who already have established IoT monitoring systems from providers like Emerson, Carrier Lynx, Sensitech, or local platforms. The approach is straightforward: your existing monitoring platform continues to capture sensor data as it always has, but adds an EPCIS export capability that translates its internal data into standardised events.

The data flow works like this: your sensors feed data to your existing monitoring platform, which passes it to an EPCIS event generator module, which then publishes standardised events to a shared repository or directly to trading partners.

The key question to ask your monitoring provider: “Do you support or plan to support EPCIS 2.0 export?” If the answer is no, ask them what their roadmap looks like — because their competitors are working on it.

Pattern 2: Native EPCIS — New Deployment with EPCIS-Native Platform

For operators building new monitoring infrastructure — whether for a new facility, a new product line, or because existing systems have reached end-of-life — deploying an EPCIS-native platform eliminates the translation layer entirely.

OpenEPCIS is a fully open-source, GS1-compliant EPCIS 2.0 implementation maintained by benelog GmbH with active community development. It provides a complete repository, REST API, test data generator, and format conversion tools — all available under the Apache 2.0 licence for the Community Edition. This means operators or their technology partners can deploy a standards-compliant EPCIS repository without licensing fees.

The data flow is more direct: sensors feed data to an EPCIS-native platform that captures events directly in the standard format, eliminating the translation step. This is the cleanest architecture but requires the most change from current practice.

Pattern 3: Hybrid — EPCIS at Handoff Points Only

This is the most realistic pattern for multi-party supply chains where you cannot control what systems your trading partners use internally. The approach focuses EPCIS standardisation where it matters most: at the handoff points between companies.

Your internal monitoring stays on whatever platform you use today. EPCIS events are generated only at key transition points: when product moves from packhouse to cold store, from cold store to transport, from transport to port, from port to destination market. At each of these handoffs, an EPCIS event captures the “what, when, where, why, how” of the transfer — including sensor data confirming temperature conditions at the moment of handoff.

This pattern delivers the highest value for the lowest disruption. It connects internal monitoring data to inter-company traceability without requiring anyone to change their daily operations. It is also the pattern that best matches how SA cold chain relationships actually work — multiple independent operators collaborating along a supply chain, each managing their own vehicles and facilities but sharing responsibility for end-to-end temperature integrity.

The data flow: internally, your sensors feed your existing monitoring platform as usual. At each handoff point, your system generates an EPCIS event that captures the transition with sensor data attached. These handoff events link together across companies to create an end-to-end traceability chain — from Western Cape packhouse through Gauteng cold store to Durban port.

Getting Started — Practical Steps

You do not need to implement the full EPCIS standard to start gaining value from it. Here is a practical sequence for SA operators.

• Step 1: Audit your current data output. Before thinking about EPCIS, understand what you have. What format does your monitoring platform export data in? CSV? PDF? Proprietary format? Can it export via API? What fields does it include — just temperature, or also humidity, GPS, door status? How easy is it to extract data programmatically? This audit tells you how much work the EPCIS translation layer would require.
• Step 2: Map your critical supply chain handoff points. Identify where data needs to flow between your business and your trading partners. Packhouse to transport? Transport to cold store? Cold store to export agent? Port to vessel? Each of these is a potential EPCIS event point. Start with the handoffs where you currently lose visibility or spend the most time on manual documentation.
• Step 3: Contact GS1 South Africa. GS1 South Africa (based in Sandton, Johannesburg) administers GS1 membership, barcode allocation, and standards implementation support for the local market. They can explain membership options, EPCIS resources, and any SA-specific implementation guidance. If you already have GS1 membership for barcodes — which most SA food manufacturers and retailers do — you already have a relationship to build on.
• Step 4: Ask your monitoring provider about their EPCIS 2.0 roadmap. This is a simple but important conversation. Technology providers who are serious about interoperability will have a position on EPCIS 2.0 support — whether it is already available, in development, or planned. Providers who have never heard of EPCIS may not be thinking about interoperability at all, which tells you something about their strategic direction.
• Step 5: Start with one supply chain. Pilot EPCIS event capture on your highest-value or most-regulated product line. Pharmaceutical cold chain is an obvious candidate given GDP documentation requirements. Export produce through PPECB is another, given the multi-party handoff chain and destination market traceability demands. Pick the supply chain where standardised data exchange would eliminate the most manual work or reduce the most compliance risk.
• Step 6: Explore OpenEPCIS tools. The OpenEPCIS test data generator lets you create realistic EPCIS events for testing and evaluation without deploying any infrastructure. You can model your own supply chain scenarios, generate events with sensor data, and see exactly what standardised cold chain data looks like. The OpenEPCIS GitHub organisation provides additional tools including format converters, event hash generators, and a full EPCIS 2.0 repository.

Resources and Further Reading

GS1 EPCIS 2.0 Standard Documentation

• EPCIS 2.0 Standard Specification — the complete technical standard, ratified June 2022
• Core Business Vocabulary (CBV) 2.0 Standard — companion vocabulary defining business steps, dispositions, and sensor measurement types
• EPCIS and CBV Implementation Guideline 2.0 — practical implementation guidance with worked examples, ratified March 2023
• GS1 EPCIS Overview Page — non-technical introduction and links to all related resources

Open-Source Tools

• OpenEPCIS Platform — open-source, GS1-compliant EPCIS 2.0 implementation by benelog GmbH
• OpenEPCIS Test Data Generator — create realistic EPCIS events for testing and evaluation
• OpenEPCIS GitHub — full source code, repository, converters, and tools
• GS1 EPCIS Example Data — official JSON-LD and XML example events

GS1 South Africa

• GS1 South Africa Website — membership, barcode services, and standards support
• GS1 South Africa Contact Page — Pinmill Farm, Katherine Street, Sandton
• GS1 South Africa Standards and Guidelines — local standards resources including EPCIS and traceability

ColdChainSA Related Content

• South Africa’s Cold Chain Compliance Matrix — every regulation, certification, and requirement mapped by operator type
• Why Your Cold Chain IoT Sensors Can’t Talk to Each Other — Editorial 1 in this series: the interoperability problem
• Blockchain in Cold Chain: What SA Operators Actually Need to Know — Editorial 2 in this series: blockchain signal vs. noise
• Technology Directory — temperature monitoring and technology providers serving the SA cold chain market

Conclusion

EPCIS 2.0 is not a future technology — it is a ratified international standard, adopted as ISO/IEC 19987:2024, with open-source implementations available today. Its sensorElementList capability was designed precisely for the cold chain use case: capturing standardised, machine-readable temperature and environmental data as part of supply chain events that can be shared across trading partners without proprietary lock-in.

South African operators do not need to implement the full standard overnight. The practical path starts with understanding the data model, identifying where standardised data exchange would add the most value — typically at multi-party handoff points — and then piloting EPCIS event capture on one product line or supply chain.

The operators who engage with EPCIS 2.0 early gain three specific advantages. First, interoperability — the ability to share compliance data with trading partners, regulators, and export certification bodies without manual reformatting. Second, reduced documentation burden — automated, standardised events replacing PDF downloads, email attachments, and manual data entry. Third, positioning for export market requirements — as the EU’s Digital Product Passport regulations and EUDR traceability requirements take effect, SA exporters with EPCIS-compatible data systems will be ready while competitors scramble.

The standard exists. The tools are available. The question for SA cold chain operators is not whether to engage with EPCIS 2.0, but when.

Sources & References

About These Sources

This article draws on authoritative primary standards from GS1, ISO/IEC international standards, open-source implementation documentation, verified industry deployment case studies, and South African regulatory sources. All URLs were verified as of February 2025 and represent the most current publicly available information on EPCIS 2.0 and its application to cold chain operations.

Citation Methodology

Direct technical descriptions of EPCIS data structures, event types, and sensorElementList capabilities reference the GS1 EPCIS 2.0 and CBV 2.0 specifications. South African regulatory requirements are drawn from published R638 regulations, SAHPRA GDP guidelines, and PPECB mandates. Where the article extends into operational recommendations specific to SA cold chain conditions, these reflect the author’s direct operational experience in refrigerated transport and industry-specific analysis.

Currency Note

EPCIS 2.0 was ratified in June 2022 and adopted as ISO/IEC 19987:2024. The standard is stable and current. South African regulatory requirements (R638, SAHPRA GDP, PPECB mandates) were current as of February 2025 but may be subject to amendment. Readers should verify current regulatory requirements with the relevant authorities for compliance-critical decisions.

Primary Standards and Specifications

• GS1 EPCIS 2.0 Standard — Complete EPCIS 2.0 specification, Release 2.0, Ratified June 2022. Defines the data model, event types, sensorElementList structure, JSON-LD format, and REST API. Also adopted as ISO/IEC 19987:2024.
• GS1 Core Business Vocabulary (CBV) 2.0 Standard — Companion standard providing standardised terminology for business steps, dispositions, sensor measurement types, and other vocabulary elements used within EPCIS events. Also adopted as ISO/IEC 19988.
• EPCIS and CBV Implementation Guideline 2.0 — Practical implementation guidance with detailed supply chain examples, ratified March 2023. Developed by the EPCIS/CBV 2.0 Mission-Specific Work Group.
• ISO/IEC 19987:2024 — EPC Information Services — ISO/IEC adoption of the EPCIS 2.0 standard under ISO/IEC JTC 1.

Implementation and Open-Source Tools

• OpenEPCIS Platform — Open-source, GS1-compliant EPCIS 2.0 implementation by benelog GmbH & Co. KG. Includes EPCIS repository (Community Edition under Apache 2.0 licence), test data generator, format converters, and event hash generators.
• OpenEPCIS GitHub Organisation — Source code for all OpenEPCIS tools and repositories, including the Community Edition EPCIS 2.0 repository built on Kafka, Quarkus, and OpenSearch.
• GS1 EPCIS GitHub Repository — Official GS1 repository with EPCIS 2.0 development artefacts including schemas, JSON-LD context files, and API specifications.

Industry Deployments and Case Studies

• ATGA Table Grapes Traceability Pilot — Australian Table Grape Association deployment using GS1 Digital Link QR codes and EPCIS events (including temperature logging) for end-to-end traceability, implemented by Result Group and EVRYTHNG (Digimarc), funded by Agriculture Victoria.
• Digimarc — EPCIS 2.0: Transforming the Global Supply Chain — Overview of EPCIS 2.0 ratification and deployment examples from Dominique Guinard (VP Innovation, Digimarc; co-chair GS1 Digital Link work group; EPCIS 2.0 contributor).
• Digital Traceability in Agri-Food Supply Chains: A Comparative Analysis — Peer-reviewed analysis of EPCIS-based traceability implementations including the fTRACE solution by GS1, demonstrating cloud-based supply chain event recording.

South African Regulatory Context

• R638 Regulations — South African Department of Health regulations governing the transport and storage of perishable foodstuffs under the Foodstuffs, Cosmetics and Disinfectants Act (Act 54 of 1972). Specifies temperature requirements by product category: raw meat/poultry/fish ≤ +4°C, dairy ≤ +5°C, frozen meat -12°C to 0°C, deep frozen -18°C or colder.
• SAHPRA GDP Requirements — South African Health Products Regulatory Authority enforcement of Good Distribution Practice for pharmaceutical cold chain, requiring continuous temperature monitoring, SANAS-calibrated sensors, deviation investigation, and documented evidence of +2°C to +8°C control.
• PPECB Cold Chain Services — Perishable Products Export Control Board, South Africa’s official certification agency for perishable export products. Mandated under the PPEC Act (No 9 of 1983) to perform cold chain services including temperature verification at loading and en-route temperature management.
• GS1 South Africa — National GS1 Member Organisation administering barcode allocation, GTIN management, traceability solutions, and standards support for South African businesses.

Background and Analysis

• IOTA Foundation — Ratification of EPCIS 2.0 — Technical overview of EPCIS 2.0 ratification and its implications for DLT-based supply chain transparency, including EU Digital Product Passport applications.
• OpenEPCIS — EPCIS 2.0 and EPCIS 1.2 Comparison — Detailed technical comparison highlighting key 2.0 enhancements: JSON/JSON-LD format support, REST API binding, sensorElementList, AssociationEvent type, and persistent disposition capability.

About ColdChainSA

ColdChainSA.com is South Africa’s dedicated cold chain industry directory and resource platform — built by operators, for operators. ColdChainSA provides the technical depth and operational credibility that generic logistics directories cannot match.

Browse the Technology Directory to find monitoring, IoT, and traceability providers serving the South African cold chain market.