When a Machine Fails, Can the Service History Be Trusted?

An illustrative scenario

Consider a large engine installed in a ship or power-generation system. An engine failure leads to an incident, and the parties involved need to understand what happened.

The system owner may ask whether the last service was carried out correctly. The equipment manufacturer may need to establish which instructions were issued and which configuration was in use. The service company may need to demonstrate who performed the work and what was recorded at the time.

If the service documentation is held by only one party, questions may arise about whether an entry was changed, removed or added after the incident.

What should the record establish?

A useful history could provide independently checkable evidence of:

• which technician or service application authenticated to the equipment;
• which device accepted the connection and recorded the event;
• what operation or configuration change was requested;
• whether the request was accepted and completed;
• the order of maintenance, calibration and operational events; and
• whether an event was later erased, reordered or modified.

The goal is not simply to keep a more detailed log. It is to make the history itself verifiable by the parties that need to rely on it.

Identity, action and evidence

The machine and the service device can authenticate one another using cryptographic identities. A technician’s phone or another secure user device can carry a personal identity, anchored to the organisation’s existing credentials.

Each important action can then be associated with:

WHO       the authenticated technician or service application
WHAT      the requested operation or configuration change
WHERE     the machine or recording device that accepted it
WHEN      the agreed position and time in the event history
EVIDENCE  signatures and links that allow later verification

Conceptually:

Technician identity
         +
Machine identity
         +
Signed service event
         +
Cryptographic event chain
         ↓
Independently verifiable history

The participating organisations do not need to rely solely on a private log controlled by one of them. Each party can retain and verify evidence of the events in which it took part.

Beyond one machine

The same need can arise wherever equipment, operators and service organisations cross organisational boundaries:

• industrial machinery and power systems;
• ships, vehicles and fleets;
• maintenance and service histories;
• warranty and insurance investigations;
• supply-chain operations; and
• autonomous or semi-autonomous systems.

The scenario illustrates the broader ControlThings proposition: cryptographic identity establishes trustworthy participants, trusted access governs what they may do, and verifiable event logging provides evidence of what happened afterwards.

The technology behind the scenario

Read the technical explanation: From Device Identity to Verifiable Autonomy →

Read about secure identity and trusted access →

ControlThings holds intellectual property relating to secure device identity and cryptographically secured event logging. See the patents →