TIC 4.0
KPI White Paper
Introduction
The aim of TIC 4.0 is to represent any reality in digital format. The way to represent an instantaneous reality (a frozen image of reality) is through the “status” without time dimension (position, speed, status) in a specific timestamp.
(e.g. at 06-10-2023 09:00 Straddle Carrier 01 is working bay 01A 02 01 and driving with speed of 10 km/h)
But, how we can represent the reality across time? Usually, reality suffers many changes across time and human factor needs to simplify this “movie” of realities into a simple digital representation (a number or a small series of numbers). We call this number “KPI” because it tries to represent a long series of realities in just one short abstract value giving a meaning with the final goal of improving.
(e.g. on the day of 06-10-2023 Straddle Carrier 01 had an average driving speed of 15 km/h)
KPIs stands for KeyPerformance indicator. But to consider it as key or not key depends on the use of its value. For the TIC4.0-user KPI means a way to compress the reality across time in data with meaning, understandable for humans with the aim of representing in a “simple” way a complex reality point of view across time.
In the last 30 years, several models have been developed to measure the performance of organizations. The Business Balanced Scorecard of Kaplan and Norton (1992) is probably one of the most well-known frameworks that use KPI scorecards to inform stakeholders. The KPI, short for Key Performance Indicator, is a measure of performance against a strategic objective and goal (Sharda, Delen & Turban, 2018). KPI’s are used to measure business processes, usually in the dimensions of Time, Cost, Quality or Flexibility (Dumas, La Rosa, Mendling & Reijers). We can distinguish KPI’s in leading and lagging indicators. Lagging indicators describe the process that already has been executed while leading indicators predict future performance.
KPI’s can be created using data warehouses and OLAP cubes. Often these systems support operations like Slicing, Dicing, Drilling, Roll-up and Pivoting based on facts and dimension tables. Facts are historical events or observations related to dimensions that describe business entities (Microsoft, 2023).
TIC 4.0 aims to develop a proper KPI semantic data model that allows the industry to get to the most value.
The aim of this paper
This paper intends to create an understanding of the methodology of how any KPI (standard or exotic) may be calculated and represented using the TIC4.0 semantic. By using this semantic, the TIC4.0 user is empowered to create his/her own KPI which best suits the user’s requirements.
This paper does not intend to re-create existing KPIs such as “crane productivity” or “terminal throughput”.
However, it illustrates how to use TIC4.0 semantic to represent such common KPIs and provides examples with 5 simple and popular KPIs. This list of examples will be extended in future releases.
TIC 4.0 KPI Definition
KPI = Represents in a consolidated way a reality, during a period of time, filtered, grouped and split in such a way that allows the reader to understand it creating value.
TIC 4.0 KPI SEMANTIC
The KPI semantic defines the ontology to express a unique meaning of a KPI (consolidated reality) just in one “sentence” or long name. A KPI is always a Mathematical Formula that represents a dataset time series in a consolidated way. To get it, many attributes should be included in this sentence to consider all the dimensions of such consolidation. The most relevant are:
Datapoints: refers to the time series values we are going to operate (observe and represent). These could be just one or multiple values that will be consolidated by the “operator”.
Operator: the mathematical formula (one or several operators) that combines the datapoints creating a rational relation between them (sum, average, standard deviation, medium, max, min, ratio, etc). The formula could be also a combination of formulas (iterative calculation).
Timeframe: period of observation of the datapoints (filter per time), which will always include the Start-timestamp and End-timestamp of the time series.
Filter: filters are used to include/exclude some values from the time series (e.g. che.type = TT; timestamps = Monday)
Split: time series data points can be preagregated reducing its size (resolution) before its operation splitting them by any type of event or time value before it is aggregated. The operator will be then applied to the “reduced” (preagregated) time series. An example could be the time a CHE is working, the original timeseries is per second (1Hz). But before operating, the time series is first split and aggregated per time (total working time per hour, shift or day) or per event not-available/available (giving one register with all the working time available and notavailable).
Bucket: is a special filter that applies to every KPI creating a group by any kind of metadata or relation (ie represents the KPI per shift|CHE|Driver|time). A bucket can be aggregated in another bucket (subbucket).
OLAP: in case the data is represented in a cube, the cube should be defined in OLAP language (optional)
Value: The combination of datapoints, timeframe, filter, split and bucket results in a unique representation of the reality where TIC4.0 defines this as value. This value can be expressed in many units. The unit must be included in the description of the KPI.
Name: Datapoints+Operator+Unit
KPI Elements: All the elements are used to define how the operator is represented. Starting by timeframe, filter, split, and bucket.
1º Example
Name: Average Moves (box per minute)
Datapoints:
che.@.cycle.@.move.counter.output.actual.box
che.@.on.timer.actual.output.actual.#unit#second.value
Operator: SUM(che.@.cycle.@.move.counter.output.actual.box) / SUM(che.@.on.timer.actual.output.actual.#unit#second.value)
Timeframe: 2023-01-01T00:00:00.000Z - 2024-01-01T00:00:00.000Z
Filter: che.@.name: STS01
Split: by che.cycle
Bucket: per day of the week; per hour
Unit: boxes/minute
KPI Elements: year 2023 bucket per hour split per cycle and filter by che name STS01
Average Moves (box per hour) = 23.4
2º Example
Name: Average fuel consumption (liter per hour)
Datapoints:
che.@.energy.consumed.output.actual.#name#fuel.#unit#liter.value
che.@.on.timer.ouput.actual.#unit#hour.value
Operator: sum(che.@.energy.consumed.output.actual.#name#fuel.#unit#liter.value) /
sum(che.@.on.timer.output.actual.#unit#hour.value)
Timeframe: TODAY
Filter: by che.@.type = TT
Split : by che on|off
Bucket :
Unit: liter/hour
KPI Elements: TODAY filter by che type TT, split by che on|off and for all TTs (not bucked by TT)
Average fuel consumption (liter per hour) = 6.4
3º Example
without bucket, without filter per name
Name = CheckInOutPlanned
Datapoints: carriervisit@.cargovisit.checkin_or_checkout.counter.planned.box
Operator = sum (carriervisit@.cargovisit.checkin_or_checkout.counter.planned.box )
Timeframe: TODAY
Filter: by (cargovisit.inbound or outbound.#modality#vessel) and (cargovisit.checkin_or_checkout.time.#timestamp#TODAY)
Split: per cycle
Bucket: All
KPI Elements: TODAY filter by inbound or outbound vessel, split per cycle
CheckInOutPlanned (box) = 3.167
with filter by name
Name = CheckInOutPlanned
Datapoints: carriervisit@.cargovisit.checkin_or_checkout.counter.planned.box
Operator = sum (carriervisit@.cargovisit.checkin_or_checkout.counter.planned.box )
Timeframe: TODAY
Filter: by inbound or outbound vessel and vessel name [NewYork, Marseille]
Split: per cycle
Bucket: All
KPI Elements: TODAY filter by inbound or outbound vessel and vessel name [NewYork, Marseille], split per cycle
CheckInOutPlanned (box) = 2.378
With bucket per name multiKPI
TABLE
Name = name | Datapoints: carriervisit@.carrier.name | Operator = none
Name = starttime | Datapoints: carriervisit@.terminaloperations.cargooperations.start.time.actual.timestamp | Operator = none
Name = vesselServiceName | Datapoints: carriervisit@.cargovisit servicevisit.name | Operator = none
Name = CheckInOutPlanned| Datapoints: carriervisit@.cargovisit.checkin_or_checkout.counter.planned.box | Operator = sum (carriervisit@.cargovisit.checkin_or_checkout.counter.planned.box )
Timeframe: TODAY
Filter: by inbound or outbound vessel
Split: per cycle
Bucket: per carriervisit@.carrier.name
KPI Elements: TODAY filter by inbound or outbound by vessel, split per cycle, bucket per carriervisit name.
CarrierVisitName | StartTime | VesselServiceName | CheckInOutPlanned (box) |
---|---|---|---|
SuperCurro | 2023-10-26T00:00:00.000Z | FARAWAY | 234 |
Lopez | 2023-10-26T12:00:00.000Z | MUYLEJOS | 555 |
NewYork | 2023-10-26T16:00:00.000Z | LOIN | 2345 |
Marseille | 2023-10-26T10:00:00.000Z | SUPER | 33 |
© Copyright - TIC 4.0 All rights reserved | Design web by Fundación Valenciaport