ChargeLink Native
Developed byDEVlink

Support Escalation and Evidence Collection

A good support case should let another engineer reproduce the failure without first asking "which version, which profile, which interface, and where are the logs?" This chapter defines the minimum information to collect and how to prepare it safely.

Before opening a support case

  1. Stop the active test safely.
  2. Preserve the failing run directory; do not rerun over it.
  3. Record the local time and timezone of the failure.
  4. Record what you expected and what actually happened.
  5. Collect the product, environment and runtime evidence below.
  6. Apply redaction before sharing outside your organization.

One-command collection template

Run from PowerShell after the system is in a safe state:


$CL = 'C:\Program Files\ChargeLink Native\bin\chargelink.exe'
$Data = 'C:\ChargeLinkData'
$Stamp = Get-Date -Format yyyyMMdd-HHmmss
$Case = "$Data\support\case-$Stamp"
New-Item -ItemType Directory -Force $Case | Out-Null

& $CL --version | Out-File -Encoding utf8 "$Case\version.txt"
& $CL --json license status | Out-File -Encoding utf8 "$Case\license-status.json"
& $CL --json license entitlements | Out-File -Encoding utf8 "$Case\license-entitlements.json"
& $CL --json doctor | Out-File -Encoding utf8 "$Case\doctor.json"
& $CL --json runtime list | Out-File -Encoding utf8 "$Case\runtime.json"
& $CL --json integration health --endpoint http://127.0.0.1:50051 |
  Out-File -Encoding utf8 "$Case\grpc-health.json"

Get-ComputerInfo | Out-File -Encoding utf8 "$Case\windows.txt"
Get-NetAdapter | Format-List * | Out-File -Encoding utf8 "$Case\net-adapters.txt"
Get-NetIPAddress | Format-Table -AutoSize | Out-File -Encoding utf8 "$Case\ip-addresses.txt"
Get-NetTCPConnection -ErrorAction SilentlyContinue | Out-File -Encoding utf8 "$Case\tcp-connections.txt"
Get-NetUDPEndpoint -ErrorAction SilentlyContinue | Out-File -Encoding utf8 "$Case\udp-endpoints.txt"

If the failure is a protocol run, copy the specific run directory into the case folder rather than the entire artifact root.


Copy-Item 'C:\ChargeLinkData\artifacts\<RUN_DIRECTORY>' "$Case\run" -Recurse

For VeriStand, add the customer-safe configuration and logs:


Copy-Item 'C:\ChargeLinkData\veristand\gateway.json' "$Case\gateway.json"
Copy-Item 'C:\ChargeLinkData\veristand\operator-launcher.json' "$Case\operator-launcher.json" -ErrorAction SilentlyContinue

Do not copy proprietary models, private keys, or customer signals that are not needed to diagnose the issue.

What to include in the ticket

Use this structure:


Subject: <protocol/integration> - <short failure> - <ChargeLink version>

ChargeLink version:
License/edition:
Protocol and role:
Profile ID:
DUT identity/model/firmware:
Workstation Windows version:
Network/CAN adapter:
VeriStand version (if applicable):
Run ID:
Failure timestamp + timezone:
Expected behavior:
Observed behavior:
First visible error/event:
Was the problem reproducible? yes/no
Did the same setup work previously? version/date
Safety impact: none / session stopped / bench interlock / other
Attached evidence bundle: <filename>

Redact before sharing

Artifacts can contain customer and infrastructure information. Review at least:

  • IP addresses, MAC addresses and host names;
  • certificate subjects, serial numbers and chain metadata;
  • contract/certificate identifiers;
  • customer signal names and values;
  • DUT serial numbers or VIN-like identifiers;
  • Windows user/domain names;
  • file paths that reveal customer project names;
  • tokens, passwords, private keys, PFX files, signing keys or secret environment variables.

Never send a private key merely because a TLS handshake failed. Support can normally diagnose trust/path issues from public certificate metadata and error evidence.

Package the reviewed bundle

After review/redaction:


$Zip = "$Case.zip"
Compress-Archive -Path "$Case\*" -DestinationPath $Zip -Force
Get-FileHash $Zip -Algorithm SHA256

Send the SHA-256 value with the case when your support channel supports integrity verification.

Severity guidance

SeverityExampleOperator action
S1 - Safety/service criticalUnsafe command behavior, fail-safe not reached, product prevents a critical validated operationPut bench in safe state, stop further live testing, escalate immediately through the contracted critical channel.
S2 - MajorReproducible failure blocks a protocol/integration with no practical workaroundPreserve evidence and open a high-priority case.
S3 - NormalFunctional issue with workaround or limited scopeOpen a normal support case with complete evidence.
S4 - Question/documentationUsage question, unclear command, enhancement requestInclude version and page/command reference.

What support should not have to ask for

A production-ready case should already include version, license/edition, protocol/role/profile, run ID, timestamp, environment identity, the first error, and the relevant run evidence. Missing these fields is the most common reason support resolution slows down.