Standards and Conformance

Which protocol specifications DK Studio is aimed at, what a conformance pack is, what it contains, how it runs against a bench, and how the coverage of a standard family is reported.

The protocol families we target

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

A family is the unit that a conformance pack is written against. For a public standard the platform does not implement the family's stack itself: the frames are spoken by the key reader, the ECU or the bench script, and the platform carries the commands, the observations and the results. COT is DK Studio's own protocol, and its driver ships with the platform.

What a conformance pack is

A conformance pack is a structured set of test cases, each one traced back to a requirement of a specification. It is the meeting point between a standard and the test-case model: the requirement says what the specification demands, the test case says what behaviour is asserted, the procedure says how it is exercised, and the expectation says what counts as a pass.

Layer	The question it answers	What it holds
Requirement	Which clause of the specification does this cover?	The requirement id, the specification version, and the clause reference.
Test case	What behaviour is being asserted?	The title, the preconditions, the capability and variant it applies to.
Procedure	How is it exercised?	The steps: the commands to run on the bench, the frames to send, the readings to take.
Expectation	What counts as a pass?	The observable outcome, the tolerance where one applies, and the evidence to keep.

What a pack contains

A requirement table — one table per specification, one row per requirement, with the clause reference and the specification version it came from.
Cases traced to requirements — every test case names the requirement it covers, so coverage is a query rather than an argument.
Procedures expressed as bench commands — the steps use the platform's command vocabulary, so a pack runs on any bench that has an agent.
Expectations and evidence — each case states what counts as a pass and what evidence to keep (log excerpts, captured frames, files pulled from the bench).
Parameters — the project data the procedure binds to: the IMSI, the port, the timeouts.
A run and report definition — a pack run produces a per-case result and a report, in the same run and report model as everything else.

Running a pack against a bench

A pack runs through the same command channel as every other test in the platform.

Select the suite and the target. The suite is the pack; the target names the protocol family, the device type, the OEM and the project.
Resolve the case to a procedure. Each test case in the pack resolves to the variant that matches the target, and the variant owns the procedure.
Bind the parameters. The project's data is substituted into the procedure's placeholders, and the rendered steps are hashed so a later edit to the script is visible in the history.
Hand the steps to the driver. The driver is the execution backend: the agent driver runs the procedure over the command channel — shell, open_serial, serial_write — against the device under test; a local driver runs the same procedure on a workstation. The driver is the only layer that knows about a specific lab.
Evaluate the expectations. Each step produces an observation, the extractor reads the value out of it and the matcher decides pass or fail. The case passes when all of its expectations hold.
Record the run. The run, its executions and their durations are stored, the evidence is attached as an artifact, and the report is produced from the same model as any other run.

A case whose variant does not match the target is skipped with a reason, not failed. A missing mandatory parameter is a configuration error, because it is a problem with the run rather than with the device under test.

Reporting coverage of a standard family

Coverage is reported per family, from the requirement table outwards. Because every case names its requirement, the report is a query over the pack rather than a count kept by hand.

Reported	How it is derived
Requirements in the family	The rows of the family's requirement table.
Requirements covered	The requirements named by at least one test case in the pack.
Requirements executed	The requirements whose cases were executed in the run, with their pass/fail outcome.
Uncovered requirements	The requirements with no case, or with a case that was not executed.
Cases without a requirement	The cases in the pack that name no requirement. These are reported so that the trace stays complete in both directions.

The numbers are reported for the whole family and for each case within it, so a gap is always attributable to a named requirement. See The Test Case Model for the layers the report is built on, and Results and Reports for how a run is turned into a report.