CANoe File Types and Configuration Management
A configuration is a dependency graph, not one file
Copying a CANoe .cfg to another computer does not guarantee the same experiment can run. The configuration can refer to CAPL source, include files, network databases, panels, DLLs and external data. Some are inputs; others are reproducible outputs or records of a particular run. Classify them before deciding what to archive.
Start with the files you can explain
| File | Role | Recovery question |
|---|---|---|
.cfg |
Main CANoe configuration | Can it resolve all required referenced paths on a clean checkout? |
.can |
CAPL source | Can the target installation compile it? |
.cin |
CAPL include source | Is it included at the intended path, with no missing dependencies? |
.cbf |
Compiled CAPL binary | Can this project regenerate it, or is it an intentional supplied dependency? |
.dbc / .ldf |
CAN / LIN network descriptions | Does the version match the identifiers, signals and encoding expected by the source? |
.dll |
External executable dependency | Are architecture, version, licensing and provenance known? |
.asc / .blf |
Common text / binary logging formats | Is this a required replay input or a new measurement output? |
The .cin extension means an include file, not a callback interface. An include is source used by another CAPL program; renaming it does not turn it into an independent simulation node. The compiled .cbf is not a replacement for editable source when the project is expected to be rebuilt.
This table describes the roles relevant to a small CAPL project, not every format or option supported by every CANoe version. Verify version-specific formats with the installed help.
Work through one missing-dependency case
Suppose DoorModel.can includes DoorLimits.cin and accesses signals from Door.dbc. A colleague receives only the CFG and CAN file. Three different failures are possible:
- The node path resolves on your computer but points outside the copied directory on theirs.
- Compilation cannot find the include, even though the main source opens successfully.
- The source compiles against a different database revision, so raw/physical values or message layout differ from the expected experiment.
Check the resolved paths and the exact database revision before rewriting event handlers. The defect is in the experiment's dependency set, not necessarily in CAPL logic.
Separate inputs from evidence
Use explicit directories such as Nodes, Database, ReplayInputs and RunEvidence. These names are a suggested team convention, not CANoe requirements. A BLF used as a controlled replay fixture is an input and needs a stable version. A newly recorded BLF is evidence and should identify its run. Ignoring all BLF files would lose the former; committing every recording would bury the intended inputs.
For a release, keep a manifest with the source revision, required files, CANoe version, necessary options, database revisions, external dependency versions and relative paths. Preserve the actual run evidence separately with its case identifier.
Prove recovery from a clean location
- Check out the selected source revision into a new directory.
- Obtain declared dependencies through the team's authorized process.
- Open the configuration and resolve paths without relying on the author's private directories.
- Compile from source and retain diagnostics.
- Run a defined positive case and a missing-sender negative case; preserve the resulting trace and configuration.
This is a recovery procedure to execute, not a claim that the site has tested a supplied project. Continue with Git configuration management for a conservative repository policy.
The CAPL source/include roles follow the authorized Vector CANoe 12 help, including its Include Files section. The dependency classification, failure analysis and recovery workflow are this site's analysis.