TraceTracker Traceability Model
Relevant terms
It is recommended that you read this section to familiarize yourself with the TraceTracker terminology.
Batches and Trade units.
Batch and TradeUnits are two kinds of traceable entities. They are the basic objects used to model the traceability chain. Batch is an object of production. It has a unique identifier, a type and a set of properties, and can partake in transformations. It is used to model ingredients and raw material used in production and the results of the production process. TradeUnit is, as the name suggests, a unit of trade. It may represent a large bulk of smaller trade item, but the TradeUnit is the smallest set of objects that can be uniquely identified. This means that a TradeUnit may exist at several physical locations at the same time. Ideally each physical object should be uniquely identified, but information to do this may not exist. A trade unit has, like Batch, a unique identifier, a type, a set of properties and can partake in transformations. The main difference between batches and trade units is that trade units can be traded between organizations. Anything traded between organizations is by definition a trade unit.
A consequence of this is that raw materials and ingredients received from other organizations to be used in production, will always be received as Trade Units. Batches and trade units are identified by a unique id which ideally is located on the physical objects. This id cannot be reused at a later time even if the former object no longer exists. Objects that are reused in different shipments, should be modeled as clusters to separate them from the content.
A TradeUnitCluster is a usually contained set of TradeUnits or other TradeUnitClusters. It can be used to model pallets or boxes. It is typically used where a group of objects are inside a container making the content invisible and untraceable, while the external container is not. A Cluster may be heterogeneous, containing Trade units of multiple types, and may be used for modeling "virtual" grouping like a shipment.
Transformations
Transformations are operations between traceable entities. They are used to model how raw material and ingredients are combined into a final product and describe the relations and interactions between batches and trade units. Transformations have timestamps used for specifying when the interaction took place. These timestamps are important when determining how different batches and trade units are related: If Batch A interacts with Batch B, and Batch B interacts with Batch C, then A and C will be related, if and only if the A-B interaction happened before the B-C interaction. There are six basic transformations. Join, Split, Mix, Convert, EnterCluster, LeaveCluster.
Transformation | Type | Description |
|---|---|---|
JOIN | Many-to-One | One or more traceable objects are fully joined into another. This implies that the joining traceable objects cease to exist after this transformation. |
SPLIT | One-to-Many | One or more traceable objects are segmented off another. This may not be a complete split of the source entity, and it will continue to exist after the transformation. |
CONVERT | One-to-One | A conversion of a traceable entity. The converted entity is fully transformed, with a new identifier, and the original ceases to exist. |
MIX | Many-to-Many | A part of one or more traceable objects are mixed into other traceable objects. |
EnterCluster | Aggregation | A traceable object is placed inside of another. |
LeaveCluster | Deaggregation | A traceable object is taken out of another. |
TradeUnitCluster
TradeUnitClusters are traceable entities used to describe collections of trade units. They are most commonly used to model Logistic units. A real word example of a TradeUnit cluster is a pallet of trade units. A cluster will have its own id, and as it passes through a readpoint to be scanned, it is the id on the outside of the cluster that is scanned. A batch or trade unit cannot be transformed while inside a cluster.
Clusters can contain other clusters.
Stations
Stations are locations where batches and trade units are located. A station may be a mobile object, like a truck or a container, or it can be a factory, a production line or a part of a production line. Like batches and trade units, a station has a type, and a set of properties and is identified by a unique id. Batches and trade units may enter and leave stations, and a station’s properties may apply to the batches found inside. Stations can be seen as a combination of a readpoint and a business location.
Unlike clusters, which are created as needed and disposed when the cluster is split up, a station has a long lifespan and is re-used to hold many different groups of traceable entities. Traceable entities may also be transformed while inside a Station.
Stations may have barcode readers which gather data on which traceable entities enter and leave.
As of TIX v5.0 stations are modelled using EPCIS business locations. The EPCIS model does not have messages to describe objects leaving a business location, but leaving is implicit when objects are observed at a new location. Please see the EPCIS Specification for details.
Properties
A property value describes an attribute of a Batch, TradeUnit or Station. It has a timestamp, and several values from different times are combined to form a property log. Properties are usually used to describe attributes that differ between the batches or trade units. If all trade units of a specific type are 1 liter bottles of something, then adding a property value that specifies that the bottle is 1 liter is redundant. A property value with the expiration date is more relevant since this date will differ between trade units. Properties common to a class of trade units are better modeled as MasterData.
Traceability Resource Definitions
The Traceability Resource Definitions define the different types of batches, trade units, and stations for your traceabiliy data. It specifies which properties exist for each type, and which of those that are required for that type. Similar batches may be of the same type, and have the same properties, but with different values. Two buckets of paint may be modelled as a "PaintBucket"-type, but have different values in the PropertyType named "Color".
Units of Measurement
PropertyValues of the datatype REAL or NUMBER may have a unit of measurement, e.g. "kilogram", "meter" or "liter". Some units can be converted into other units. They are then said to be compatible. The unit "meter" is compatible to "yard" since they are both units of length, in the same way "gallon" is compatible to "liter", both being units of volume.
The units "liter" and "meter" however are not compatible. A Property of a PropertyType defining a unit of measurement must have a value with a compatible unit.
An amount and a unit may also be attached to Transformation of types Split, Mix, EnterCluster and LeaveCluster.
Time and date formats.
The data import format uses a subset of iso-86011 for time and date formats. Timestamps are always specified with a timezone, but seconds and milliseconds is optional. Look to the table below for a few examples.
Example | Description |
|---|---|
2006-02-28T12:03Z | 28th of February, 2006, at 12:03 Zulu time |
2006-02-28T12:03:20Z | 28th of February, 2006, at 12:03:20 Zulu time |
2006-02-28T11:03:20.12+01:00 | 28th of February, 2006, at 11:03:20 and 12 milliseconds GMT+1 |
Time Zone Offset.
For every XML element that has a timestamp attribute, TIX will preserve a time zone offset for the timestamp in the database. The time zone offset is an integer representing the offset from GTM in milliseconds.
The time zone offset is determined in the following way
- If the XML element has an attribute eventTimeZoneOffset, the value of that attribute will be used.
- If the XML does not have the eventTimeZoneOffset, the time zone offset will be taken from the timestamp attribute.
- If the timestamp attribute is not present (for some elements the attribute is not required), both the timestamp value and time zone offset is inherited from an enclosing element. That is, if the timestamp is missing for a given element, the eventTimeZoneOffset is ignored.
The valid syntax for the eventTimeZoneOffset is simliar to the time zone offset that can be encoded into the timestamp attribute. It must consist of a sign (+/-) followed by the hours part of the offset (00-14), the character ':', and the minutes part (00-59). Note that the eventTimeZoneOffset will not affect parsing or interpretation of the associated timestamp
attribute.