Trace, replay and reporting

ChargeLink Native stores machine-readable traces, reports, evidence and diagnostic envelopes below the configured artifact root. These files are the operational record of what ChargeLink started, what it observed, which test logic ran, how a verdict was produced and whether the evidence remained unchanged after the run.

This chapter explains why the artifacts exist, what each artifact is for, how to find and validate a run, how deterministic replay works, and how to prepare a safe customer or support handoff.

Exported artifacts may contain network identifiers, certificate metadata, protocol payload fields and customer signals. Apply the built-in redaction policy, protect signing keys and define retention before sharing evidence outside your organization.

1. Why evidence should be treated as part of the test

A successful protocol session or test verdict is not enough by itself. An operating team normally also needs to answer:

• Which ChargeLink version, protocol profile and role produced the result?
• Which run ID connects the runtime session, trace, report and support bundle?
• Was the run live, replayed or dry-run?
• Which PICS/PIXIT values and test-package filters were applied?
• Were any cases blocked, skipped or excluded?
• Were the files modified after generation?
• Can another engineer reproduce the result from the same inputs?
• Is the evidence safe to send outside the laboratory?

ChargeLink uses a run-oriented artifact model to answer those questions. Assign a meaningful run ID before starting a test and keep that run ID in issue trackers, test records and customer correspondence.

2. The artifact and runtime roots

ChargeLink has two independent roots:

For customer installations, use absolute paths instead of relying on the current working directory. The examples below use C:\ChargeLinkData.

$ChargeLinkExe = "C:\Program Files\DEVlink\ChargeLink Native\chargelink.exe"
$RuntimeRoot   = "C:\ChargeLinkData\runtime"
$ArtifactRoot  = "C:\ChargeLinkData\artifacts"
$RunId         = "LAB-A-ISO20-DC-20260806-001"

New-Item -ItemType Directory -Force -Path $RuntimeRoot, $ArtifactRoot | Out-Null

Use the same global roots on every command that operates on the same run:

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  artifacts index

A command executed without the same --runtime-root and --artifact-root may look in a different location and report that no session or manifest exists.

3. Create a traceable run

3.1 Choose a run ID

A useful run ID is unique, readable and stable. Include the laboratory or bench, protocol, date and sequence number.

Recommended format:

<SITE>-<BENCH>-<PROTOCOL>-<YYYYMMDD>-<SEQUENCE>

Examples:

GOT-BENCH03-ISO20DC-20260806-001
MUC-HIL02-ISO2AC-20260806-004
CUSTOMER-A-DIN70121-20260806-002

Avoid spaces, personal names, passwords, vehicle registration numbers and certificate subjects in a run ID.

3.2 Start an EVSE run with explicit roots

The following example starts an ISO 15118-20 DC EVSE session and writes runtime and artifact data to the selected roots. Replace the interface and IPv6 values with values from the target PC.

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  evse start `
  --run-id $RunId `
  --protocol iso15118-20 `
  --profile-id iso15118_20_dc `
  --host "::" `
  --tcp-port 50118 `
  --udp-port 15118 `
  --advertise-ipv6 "fe80::1234:5678:90ab:cdef%19" `
  --interface-index 19 `
  --external-evcc-session `
  --foreground

For a background or service-managed workflow, omit --foreground and use the runtime commands to inspect and stop the session.

3.3 Record the version and environment

Before changing the setup, save the executable version and environment diagnostics beside the run record:

& $ChargeLinkExe --json --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot cli version |
  Out-File -Encoding utf8 "$ArtifactRoot\$RunId-version.json"

& $ChargeLinkExe --json --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot doctor |
  Out-File -Encoding utf8 "$ArtifactRoot\$RunId-doctor.json"

If the installed release exposes version information through a different packaging command, use chargelink --help and chargelink cli --help from that exact installed version.

4. Find and inspect evidence

4.1 List all known artifact manifests

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  artifacts index

Use this when the run ID is unknown or when confirming that a completed run was registered below the expected artifact root.

4.2 Inspect one run manifest

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  artifacts inspect --run-id $RunId

The manifest is the inventory for the run. Review at least:

• run ID and role;
• protocol and profile identifiers;
• file names and relative paths;
• file sizes;
• SHA-256 digests;
• creation timestamps;
• redaction or export classification, where present;
• report and evidence references.

4.3 Inspect runtime lifecycle information

Artifact inspection answers “what files exist.” Runtime inspection answers “what happened to the process.”

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  runtime inspect --run-id $RunId

Use runtime information to diagnose:

• a stale session after a power loss;
• an unexpected process exit;
• a role lock that prevents a new EVSE or EVCC start;
• a missing heartbeat;
• a run that was never cleanly stopped.

List all sessions and locks when the run ID is not known:

& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json runtime list
& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json runtime locks

Do not delete runtime files manually while ChargeLink is running. Use the documented stop and recovery commands.

5. Verify artifact integrity

Integrity verification recalculates the recorded file hashes and compares them with the manifest.

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  artifacts integrity --run-id $RunId

Run this check:

1. immediately after a test run;
2. before creating a report or support bundle;
3. after copying evidence to another storage location;
4. before customer delivery;
5. when reopening archived evidence.

A failed integrity result means the evidence set is no longer identical to the manifest. Do not silently regenerate only the manifest. Preserve the original files, record the failure and repeat the run if trustworthy evidence is required.

Example: save the integrity result

$IntegrityFile = Join-Path $ArtifactRoot "$RunId-integrity.json"

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  artifacts integrity --run-id $RunId |
  Tee-Object -FilePath $IntegrityFile

6. Understand the main artifact types

The exact file set depends on the protocol, role, package and execution mode. A typical evidence set can include:

A filename alone is not proof that an artifact is suitable for external release. Always inspect the manifest, verify integrity and apply redaction.

7. Protocol traces: what to look for

A trace is most useful when it lets an operator reconstruct the session without relying on memory. Review it in this order:

1. Session identity — run ID, role, protocol, profile and software version.
2. Transport setup — interface, IPv6 address, UDP/TCP ports, CAN backend or gateway endpoint.
3. Discovery and connection — SDP, TCP acceptance, TLS negotiation or CAN initialization.
4. Protocol sequence — ordered request/response or state transitions.
5. Timing — timestamps, duration, heartbeat and timeout events.
6. Faults — negative responses, malformed input, disconnects, certificate failures or safety interlocks.
7. Closure — clean stop, peer disconnect, timeout or process termination.

Trace data that may be sensitive

Depending on the run, traces can contain or reveal:

• IPv4 or IPv6 addresses and interface indexes;
• MAC-related or adapter information;
• EVCCID, EVSEID or other protocol identifiers;
• certificate subjects, issuers, serial numbers and fingerprints;
• contract or authorization metadata;
• customer-defined VeriStand channels and signal names;
• measured voltage, current, state-of-charge or battery limits;
• fault-injection values;
• local file paths and machine names.

Private keys, passwords and tokens must never be added to comments, run IDs or copied command transcripts.

8. Normalized trace comparison

ChargeLink includes normalized trace comparison commands for supported fixtures. These commands are useful for deterministic engineering checks and regression analysis. They do not replace a live interoperability or accredited conformance test.

8.1 Show the trace policy

& $ChargeLinkExe --json trace policy
& $ChargeLinkExe --json trace hardening-policy

8.2 Normalize a supported fixture

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  trace normalize `
  --fixture iso20-service-setup `
  --run-id "$RunId-normalized"

8.3 Compare a native normalized trace with the stored reference fixture

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  trace compare-strict `
  --fixture iso20-service-setup `
  --run-id "$RunId-compare"

8.4 Write comparison artifacts

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  trace compare-strict-artifacts `
  --fixture iso20-service-setup `
  --run-id "$RunId-parity"

Use strict comparison when fingerprints and deterministic parity evidence are required. Keep the generated comparison artifacts with the change request or release evidence that triggered the check.

9. Deterministic replay

Replay verifies a deterministic simulation report or transcript hash from a previous simulation. It is intended for repeatability, regression checks and offline review. It does not create a new physical charger interaction.

9.1 Create a deterministic simulation report

ISO 15118-20 example:

$ReplaySource = Join-Path $ArtifactRoot "$RunId-simulation.json"

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  sim paired `
  --protocol iso15118-20 `
  --scenario dc-bpt-nominal `
  --seed 42 `
  --run-id "$RunId-sim" `
  --write-artifacts `
  --output $ReplaySource

ISO 15118-2 example:

$ReplaySource = Join-Path $ArtifactRoot "$RunId-iso2-simulation.json"

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  sim legacy-scenario `
  --protocol iso15118-2 `
  --scenario iso2-dc-pnc-nominal `
  --seed 42 `
  --run-id "$RunId-iso2-sim" `
  --write-artifacts `
  --output $ReplaySource

DIN 70121 example:

$ReplaySource = Join-Path $ArtifactRoot "$RunId-din-simulation.json"

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  sim legacy-scenario `
  --protocol din70121 `
  --scenario din-dc-basic `
  --seed 42 `
  --run-id "$RunId-din-sim" `
  --write-artifacts `
  --output $ReplaySource

Use chargelink sim legacy-catalog --json to confirm the scenario identifiers supported by the installed version before copying an example into a controlled test procedure.

9.2 Replay and verify the report

$ReplayResult = Join-Path $ArtifactRoot "$RunId-replay-result.json"

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  sim replay `
  --trace $ReplaySource `
  --output $ReplayResult

A successful replay demonstrates that the deterministic input and transcript are internally reproducible. It does not prove that a physical EV, EVSE, CAN interface, PLC modem or VeriStand target will behave identically.

9.3 Practical replay uses

• Reproduce a software regression without reconnecting laboratory hardware.
• Compare behavior before and after a ChargeLink update.
• Verify a known negative case in CI.
• Attach a compact, deterministic reproducer to a support ticket.
• Review a test sequence when the original bench is unavailable.

10. Generate package reports

For licensed ATS packages, the package flow produces the most complete reporting set. The execute command performs PICS/PIXIT preparation, campaign construction, execution and verdict/report generation in one flow.

10.1 ISO 15118-20 EVSE report example

$LicenseFile = "C:\ProgramData\DEVlink\ChargeLink\license.json"
$PackageRoot = Join-Path $ArtifactRoot "$RunId-iso20-package"

& $ChargeLinkExe `
  --license $LicenseFile `
  --artifact-root $ArtifactRoot `
  --json `
  ats package execute `
  --package iso15118-20-evse `
  --role evse `
  --profile-id iso15118_20_dc `
  --pics "$PackageRoot\pics.json" `
  --pixit "$PackageRoot\pixit.json" `
  --out "$PackageRoot\run" `
  --evidence-mode dry-run `
  --executable-only

Change --evidence-mode only when the required environment is connected and qualified:

• dry-run — plan and validate without claiming live evidence;
• replay — use supported recorded evidence;
• live — execute against the configured live environment.

10.2 Rebuild a verdict report from an existing run directory

& $ChargeLinkExe `
  --artifact-root $ArtifactRoot `
  --json `
  ats package report `
  --run-dir "$PackageRoot\run" `
  --out "$PackageRoot\run\verdict_report.json"

The report command also prepares customer-report and support-bundle metadata for the run directory. Review all generated files before external release.

10.3 Report interpretation

Treat the outcome categories separately:

A generated customer report is not, by itself, an accredited certification result. Check the claim boundary and contractual release notes for the installed package.

11. Redact evidence before sharing

ChargeLink classifies artifacts using redaction classes such as:

• public_metadata;
• operator_log;
• protocol_trace;
• sensitive_credential;
• customer_confidential;
• unknown.

Show the installed policy:

& $ChargeLinkExe --json artifacts policy

Create redacted copies for one run:

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  artifacts redact --run-id $RunId

After redaction:

1. inspect the redaction result;
2. open representative text and JSON files;
3. search for customer identifiers, machine names, IP addresses and certificate details that are not required by the recipient;
4. confirm that no private key, password, token or unrestricted customer signal is present;
5. verify integrity of the prepared set;
6. create the support bundle.

Redaction reduces exposure; it does not transfer responsibility for release approval. Apply your organization's export-control, privacy, security and customer-contract rules.

12. Create a support bundle

The support-bundle command prepares a safe support-bundle manifest from the redacted artifacts associated with a run.

& $ChargeLinkExe `
  --runtime-root $RuntimeRoot `
  --artifact-root $ArtifactRoot `
  --json `
  artifacts support-bundle --run-id $RunId

A support handoff should normally include:

• the support-bundle manifest;
• the redacted artifact set referenced by that manifest;
• the integrity result;
• ChargeLink version and edition;
• protocol, role and profile;
• whether the run was live, replay or dry-run;
• a concise problem description;
• expected and actual behavior;
• exact reproduction steps;
• time zone and timestamp of the failure;
• relevant hardware and gateway versions.

Do not attach the entire artifact root by default. Share only the files required for the investigation.

13. A complete copy-and-paste evidence workflow

The following workflow assumes that a run with $RunId has completed.

$ChargeLinkExe = "C:\Program Files\DEVlink\ChargeLink Native\chargelink.exe"
$RuntimeRoot   = "C:\ChargeLinkData\runtime"
$ArtifactRoot  = "C:\ChargeLinkData\artifacts"
$RunId         = "LAB-A-ISO20-DC-20260806-001"
$ReviewRoot    = "C:\ChargeLinkData\handoff\$RunId"

New-Item -ItemType Directory -Force -Path $ReviewRoot | Out-Null

# 1. Inspect the run.
& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json `
  runtime inspect --run-id $RunId |
  Tee-Object -FilePath "$ReviewRoot\runtime-inspect.json"

& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json `
  artifacts inspect --run-id $RunId |
  Tee-Object -FilePath "$ReviewRoot\artifact-inspect.json"

# 2. Verify the original evidence.
& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json `
  artifacts integrity --run-id $RunId |
  Tee-Object -FilePath "$ReviewRoot\integrity-before-redaction.json"

# 3. Apply the product redaction policy.
& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json `
  artifacts redact --run-id $RunId |
  Tee-Object -FilePath "$ReviewRoot\redaction-result.json"

# 4. Prepare support-bundle metadata.
& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json `
  artifacts support-bundle --run-id $RunId |
  Tee-Object -FilePath "$ReviewRoot\support-bundle-result.json"

# 5. Preserve an artifact index for the handoff record.
& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json `
  artifacts index |
  Tee-Object -FilePath "$ReviewRoot\artifact-index.json"

Before sending the handoff, open the files in $ReviewRoot, review the redacted output selected by the support-bundle manifest and obtain the required internal approval.

14. Retention and access control

Define retention before the first customer run. A production policy should specify:

• who can create, read, redact, sign, export and delete evidence;
• how long raw traces are retained;
• how long redacted customer reports are retained;
• whether failed and passed runs have different retention periods;
• where signing keys are stored and who can use them;
• whether artifact roots are encrypted at rest;
• how evidence is backed up and restored;
• how deletion is logged;
• how customer-specific segregation is enforced.

Recommended operational controls:

1. Put the artifact root on an access-controlled volume.
2. Do not grant normal operators access to signing-key material.
3. Use one customer or project boundary per controlled storage area.
4. Prevent automatic cloud synchronization unless approved.
5. Keep raw and redacted artifacts in separate directories.
6. Record every external transfer in the project or support system.
7. Re-run integrity verification after archival restore.

15. Troubleshooting

No active runtime session or run not found

Confirm that the command uses the same runtime root and run ID as the start command:

& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json runtime list
& $ChargeLinkExe --runtime-root $RuntimeRoot --artifact-root $ArtifactRoot --json artifacts index

Manifest not found

The run may have ended before artifact finalization, may have used an overridden --artifact-root, or may have been started from a different working directory with the default relative root. Search the intended data volume and inspect the start command transcript.

Integrity verification fails

Do not overwrite the evidence. Copy the complete run directory to quarantine, record the failing paths and hashes, and determine whether the cause was manual editing, antivirus quarantine, partial copying, storage corruption or an interrupted write.

Replay fails

Confirm that --trace points to the deterministic simulation report expected by sim replay, not to an arbitrary PCAP, text log or live protocol trace. Confirm that the file was produced by a compatible ChargeLink version and has not been edited.

Redaction output still contains customer data

Stop the handoff. Record the data class and file path, restrict access to the output and escalate through the security or product-support process. Do not attempt to solve the issue by deleting isolated lines without updating integrity and handoff records.

Report contains blocked cases

Review the package campaign, PICS/PIXIT, entitlement evaluation, hardware prerequisites and evidence mode. Blocked cases are not passed cases and must remain visible in the customer report.

16. Final handoff checklist

Before sharing any evidence outside the organization, confirm all items below:

• The run ID uniquely identifies the test.
• The ChargeLink version, protocol, role and profile are recorded.
• The execution mode is identified as live, replay or dry-run.
• The original artifact integrity check passed.
• PICS/PIXIT and campaign selection are included when a package was used.
• Failed, blocked, skipped and not-applicable cases remain distinguishable.
• Redaction completed and the output was manually reviewed.
• No private key, password, token or unnecessary customer signal is present.
• The support-bundle manifest matches the files being transferred.
• Signing keys were not copied into the bundle.
• The receiving party and retention period are approved.
• The transfer is recorded in the applicable support, quality or project system.