TCPP

What TCPP is

TCPP describes how devices and services in the energy sector talk about a process: a charging session, a meter's own configuration, a tariff enquiry, a status change, an archived document. Each message is a JSON object with the same envelope (who sent it, to whom, about which process, at which moment, with which outcome) and a record body defined by the endpoint's schema.

Messages are signed. A TCPP frame is a compact JWS over the exact bytes of the JSON, so a record can be handed on, stored and re-checked years later against the public key of the party that issued it. Records carry references to the records they answer, which is what turns a pile of individual messages back into a traceable process.

The specification is a draft. Version 1.3.0 is complete enough to implement against, with the schema set, worked examples and a working reference node published here, and is being developed further within the “Reform Ladeinfrastruktur Germany & EU” working group in consultation with the federal authorities.

Who it is for

European manufacturers, software developers, operators and users of:

• Smart electricity meters: Smart Meter Light and BSI TR-03109 devices.
• Charging infrastructure: AFIR obligations, MID-011 meters and the requirements of legal metrology.
• Smart energy control systems: buildings, plants and grid-side load management.

What it is meant to achieve

TCPP applies ordinary, current computing practice (JSON Schema, JWS signatures, HTTP) to problems the energy sector has so far solved proprietarily, if at all:

• Make building and maintaining energy systems such as charge points cheaper.
• Let a charge point or building controller be operated from an app in a way that is legally sound and not tied to one vendor.
• Establish legal certainty between the parties to an energy transaction.
• Strengthen and open up legal metrology by software means.
• Create market transparency for users and market participants, and allow fair competition between them.
• Automate tariffs and make them auditable.
• Make MID-011 meters flexible by giving them a digital self-description.
• Enable interoperability in energy control and metering, and between backends (fleet and logistics charging included), without proprietary couplings.

What a message looks like

The smallest endpoint in the set, ping, shows the envelope every other endpoint shares. Only the record object changes from endpoint to endpoint.

{
  "tcpp": "https://tcpp.digital/schema/1.3.0/",
  "head": {
    "record_type": "ping",
    "record_direction": "request",
    "record_udt": "2018-07-27T14:30:07+01:00",
    "record_pagination": 45330,
    "record_version": "1.3.0",
    "origin_type": "CSU",          // a charge switch unit …
    "origin_id": "E:DE*PID*E*IWS*00100017",
    "target_type": "TMH",          // … asking a trusted management host
    "target_id": "P:ECS-HOST",
    "context_type": "INF",
    "context_id": "G:90676293-fa28-49bd-81ba-1b58a0f62abd",
    "error_code": "000000"
  },
  "record": { "ping": "Check alive" },
  "participants": [],
  "references": []
}

The schema documentation walks through the envelope field by field, the three-letter module types, the identifier prefixes and the error code scheme.