Overview

This page introduces DK Studio: its core product definition, the value it brings to digital key development and delivery, and the distributed architecture that sets it apart.

What is DK Studio?

DK Studio is an AI-driven, full-stack automated test platform for digital key systems, built for the global connected-vehicle ecosystem. It is the dedicated test infrastructure behind digital key hardware and software delivery quality, providing fully automated verification across the whole product lifecycle — from development through production validation.

1. Target devices and technologies

The platform goes past the single node a traditional tool reaches, and covers the whole "vehicle – cloud – handset" chain of devices under test (DUT).

Layer	What is under test	How the platform reaches it
Vehicle	MCU, UWB, NFC and BLE modules, and the digital key controllers, readers and ECUs.	The agent on the bench opens the serial port the module is attached to and drives it directly.
Cloud	The digital key backend: interface performance, key generation and distribution logic, and the vehicle–cloud–handset security certificate chain.	The studio exercises the backend interface and asserts on what it returns.
Mobile	System-level wallet car keys on branded phones and smart watches, across the main wallet ecosystems, and the vehicle maker's own app.	The agent drives the handset over USB, and the studio drives the wallet over its cloud interface.

2. System architecture

The system is a Platform + Agent decoupled architecture — a centralised platform and distributed workstations — delivered either as a SaaS service or as an enterprise in-house private installation.

• DK Studio Platform (the control centre) — a unified web console. It owns test asset management, case orchestration and scheduling, load balancing across the distributed agent pool, the AI core engine that parses the results, and the aggregation of delivery-grade, multimodal reports.
• DK Studio Agent (the edge execution node) — a lightweight daemon deployed on the workstations of each physical lab. It connects to the test phones, DK Studio's own simulation hardware boxes, programmable RF attenuators and test rigs beside it, and receives and executes the test instructions the platform dispatches.

See Architecture for how the two talk to each other, and Deployment modes for the hosted studio and the in-house installation.

3. Protocol compatibility matrix

The platform covers both industry public standards, for conformance certification, and enterprise proprietary protocols, for development and tuning.

• Industry public standards — CCC (全球车联联盟), ICCE (中国智慧车联产业创新联盟) and ICCOA (智慧车联开放联盟). The platform is protocol-agnostic above the driver layer: your team writes the procedures for a family as drivers and scripts on the bench, and the platform carries the commands, the results and the evidence.
• COT — DK Studio's own proprietary digital key protocol. It ships with a driver of its own, so COT procedures run out of the box, and the platform asserts against the high-bar, customised business flows an internal programme needs.

See Supported protocols for how the driver layer works, and Standards and conformance for what a conformance suite covers.

4. Target users

• Digital key hardware and software suppliers — factory self-test and full baseline establishment, shortening the iteration loop across hardware, software and cloud services.
• Vehicle makers (OEM) — large-scale multi-phone compatibility sweeps before production, and one place to manage every supplier's bench and its cloud counterpart.
• Third-party test and certification bodies — load a standard's conformance suite in one step and produce a compliance-grade certification report.

Why DK Studio

A digital key is a "vehicle – cloud – handset" system of three tightly coordinated ends. In a traditional development and delivery flow, the development and test teams are stuck in a quagmire of handset ecosystem isolation, brittle test script maintenance, and multi-device scheduling across regions.

DK Studio exists to break those bottlenecks, and it does so with a different architecture.

1. High-precision timing and assertions across vehicle, cloud and handset

• The pain — a complete digital key business (remote vehicle control, key sharing, passive entry) spans three entirely different physical dimensions: the vehicle bus and radio, cloud certificate distribution, and the system wallet on the handset. Traditional test methods cannot capture the latency and the anomalies across those nodes on a single timeline, so locating an intermittent failure — an unlock timeout, a certificate validation failure — is like looking for a needle in a haystack.
• The answer — DK Studio uses a distributed synchronisation mechanism across Platform and Agent. When the platform dispatches a test plan, the system aligns the vehicle CAN frames, the cloud API response logs, the handset's Logcat and Syslog, and the external camera video on a microsecond-accurate timeline. When a test fails, the team replays the vehicle–cloud–handset timeline in one click and locates the fault in seconds.

2. The automation blind spot in the handset's protected interfaces

• The pain — modern phone operating systems (iOS Apple Wallet in particular, and the Android Secure Element area) block screenshots outright and intercept every attempt by a traditional UI automation framework (ADB, WebDriverAgent) to read the UI tree on the screens where a digital key is activated, a card is presented, or a biometric prompt appears. The end-to-end automation flow breaks there.
• The answer — DK Studio introduces an external high-resolution camera and a purpose-built AI vision engine on the edge agent. The system reads the privacy-sensitive state and the system pairing dialogs on the handset screen the way a person reads them, through computer vision and OCR, and closes the automation blind spot on the handset.

3. Far less maintenance on the scripts, far less wear on the assets

• The pain — the vehicle maker's app and the system wallet change interface often, and a test script written against element selectors or absolute screen coordinates breaks with the first layout change and is worthless after the next release. A long 7x24 stress run is then interrupted by a minor UI edit, and the people and the equipment on the bench are wasted with it.
• The answer — the platform has an AI self-healing mechanism built in. When the app's layout shifts or an element's attributes change, the AI engine recognises it while the run is live and corrects the tap coordinates. With data-driven testing (DDT) on top, a team writes one set of cases for COT or for one of the three public standards, and the run sweeps hundreds of mainstream handsets on its own. Script maintenance drops by more than 80%.

4. Hardware on one site, used from every site

• The pain — high-value hardware (HIL rigs, programmable RF attenuators, driven slides) sits in one particular physical lab, and the engineers, the cloud team and the test teams spread across regions cannot call on those assets whenever they need them.
• The answer — the distributed, decoupled architecture of DK Studio runs as a SaaS service or installed in-house. The hardware and the handsets under test only have to be connected to an agent workstation at whatever site they sit on, and the engineers and testers anywhere in the world compose, dispatch and run unattended stress tests from one Platform console.

How it works

The platform never touches your hardware directly. It sends a command, the agent executes it on the machine that owns the hardware, and the result comes back.

That split is what lets one studio serve a lab in Shanghai and a bench in Stuttgart without opening a single inbound port on either. The agent initiates every connection and dials out to the studio; the studio never dials back. Benches keep working behind corporate NAT, without port forwards and without a VPN client on the rig.

There are two transports for a command, and the agent uses both:

• Push — a Socket.IO command request goes out over the persistent socket; the agent replies with a command response. This is the fast path and the one the web UI uses.
• Poll — if the socket is down, the agent polls GET /api/agent/commands every five seconds, claims a command, and posts the outcome back.

Both paths write to the same agent_commands table, so the state you see is the same either way: pending → in_progress → completed.

What DK Studio does

• First-run setup — a guided wizard that takes you from a bare server to a configured database and your first admin account.
• Agent licensing and registration — issue a licence, watch agents claim it, revoke it when a machine is retired.
• Live agent presence — which agents are connected right now, and how long since each was last seen. Presence is derived from the live socket, not from a stored flag.
• Remote commands — run a shell script, read system info, list and open serial ports, write bytes to a port, all from the browser.
• A serial console on the agent — open a port on the bench and interact with it from the agent's own page at http://localhost:3001. The studio drives the same serial commands over the command API.
• Test cases and suites — write a capability once, cover it per protocol family, device type and project, and organise the work into suites.
• Execution, scheduling and reporting — run a suite across the agent pool, schedule the run, and read the results and the evidence behind them.
• AI assistance — draft cases from a requirement, understand what is on a screen, and cluster failures to their likely cause.
• Users and roles — three roles, a session cookie, and an administration screen for creating users.
• A REST API — the same operations, scriptable.

The product coverage page maps every capability to the page that documents it.

Key terms

• Platform — the DK Studio server: web console, REST API, socket server and database.
• Agent — the companion process on the machine under test; it holds the credentials and executes the commands it is handed.
• Device under test — the reader, ECU, module, phone or rig the agent is attached to; the thing being verified.
• Licence code — the one-time ticket an agent presents to register.
• Licence — a record that authorises exactly one agent registration, and says whether the machine becomes a personal one or part of the lab.
• Socket — the persistent Socket.IO connection between an agent and the studio, and the push path for commands.

The full vocabulary is in the glossary.

Where to go next

• Architecture — how the studio and the agent talk to each other, and where the state lives.
• Installation — get the platform running.
• Setup wizard — create the first admin account and database.
• Product coverage — every capability, and the page that documents it.