Supported Protocols

DK Studio covers both kinds of digital key protocol work. CCC, ICCE and ICCOA are public industry standards: your team writes the procedures for them as drivers and scripts on the bench, and the platform carries the commands, the results and the evidence. COT is DK Studio's own proprietary digital key protocol, and it ships with a driver of its own, so COT procedures run out of the box.

This page introduces what the platform does regardless of the protocol, how the driver layer is organised, and what it costs to bring a public standard in.

The protocols

Protocol	Kind	Scope	Where it shows up
CCC	Public industry standard	The 全球车联联盟 digital key specification.	OEM and Tier-1 digital key programmes.
ICCE	Public industry standard	The 中国智慧车联产业创新联盟 vehicle-side key and access protocols.	Vehicle-side implementations and readers.
ICCOA	Public industry standard	The 智慧车联开放联盟 specifications, covering digital key and T-Box connectivity.	China-market programmes.
COT	DK Studio's own protocol	The proprietary digital key protocol. It ships with a driver of its own.	Interoperability and conformance work, on the vehicle side, in the cloud and on the handset.

A protocol is spoken at three layers of the product: on the vehicle, in the cloud and on the handset. The protocol decides the frames at each of them; the platform reaches all three. See Testing the cloud services and Testing mobile wallets.

What the platform gives every protocol

Because the platform talks to machines rather than to protocols, the same capabilities apply regardless of the protocol:

Bench presence — know which test rigs are online and how long since each was last seen.
Serial access — list, open and write to the serial port that a reader or ECU is attached to.
Remote execution — run a script on the bench that drives the protocol: send a test frame, read the reply, write the outcome to a file, and pull the result back into the studio.
Trace capture — a script can save captured frames on the bench, and the studio can fetch the file over the same command channel.

That layer is protocol-agnostic by construction. It is also where most of the daily work of a verification team lives, and it is the same for a CCC programme, an ICCOA programme or an interoperability campaign.

The driver layer

The driver layer is where a protocol's specifics live. A driver knows how to encode a frame for that protocol, how to read its reply, and which bench commands exercise a given requirement. Everything above the driver — the agent fleet, presence, command execution, results, evidence — is shared.

There are two kinds of driver in it.

Driver	Who writes it	What it covers
A public standard driver	Your team, as drivers and scripts on the bench.	The frames and the procedures of CCC, ICCE or ICCOA.
The COT driver	DK Studio. It ships with the platform.	The COT frames and procedures, on any bench that has an agent.

For a public standard, protocol verification is written as shell scripts and drivers on the bench and driven from the studio. The protocol knowledge stays with the team that owns the specification; the platform carries the commands and the results. For COT, the driver is already on the bench: a COT procedure is a case, and running it needs nothing written by hand.

Bringing a family in

A public standard is brought into DK Studio by extending the driver layer, not the platform:

Attach the bench. Connect the reader or ECU to the bench and confirm the agent sees the serial port — get_serial_ports on the agent is the check.
Encode and decode. Implement the family's framing in a driver or script on the bench: send a frame, read the reply, report the outcome.
Express the check as a procedure. Write the steps as bench commands — the same command vocabulary the platform already uses, so the procedure runs on any bench that has an agent.
Map it to the specification. Record which clause of the family specification each procedure covers, so coverage is a query rather than an argument.
Run it and keep the evidence. Execute the procedure through the studio and keep the log excerpts, captured frames and files pulled from the bench.

COT does not have to be brought in. Its driver ships with the platform, so a COT procedure runs on any bench that has an agent.

What a family costs you

Some work is inherent to a public standard and cannot be taken off your desk by the platform:

Frame-level knowledge. Only your team can encode a family's frames and interpret its replies.
Requirement mapping. Turning specification clauses into procedures is the expensive part of a conformance programme, and it is per family.
Reader and ECU variants. Hardware variants differ per programme; the platform reaches them all through the same serial and shell commands.
Evidence handling. Large traces and logs are produced on the bench and pulled back over the command channel, so your scripts stay in charge of what is captured and retained.

For COT the frame-level knowledge and the driver are supplied, so what remains is the requirement mapping for your programme and the handling of the evidence — the same work as for any other family.

Everything else — who is online, what ran, what it returned, what the evidence was — the platform already does.

Architecture — how the studio and the agent talk to each other.
Deployment modes — where the studio that carries the runs runs.
Connect Your First Agent — get a bench talking to the platform.
Remote Shell and Serial — drive a protocol from the browser.
Testing the cloud services — the cloud layer of a digital key programme.
Testing mobile wallets — the handset layer.