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)

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