Skip to content
BUSMUST
Support中文

BMCLI database

Reference version: BMCLI 1.6.5. Command names, parameters and machine-readable fields retain their source spelling.

Persistent lifecycle for typed engineering database resources. database owns registration, validation, discovery, and removal; protocol-specific operations remain under dbc, ldf, and future database categories. Resources are stored in the per-user BMCLI state directory and remain available to later processes.

database load

Section titled “database load”

Validate and register a DBC, LDF, A2L, or mapping file. The type is inferred from the extension unless --type is supplied. The default resource name is the filename stem. Loading the same canonical path again is idempotent.

Terminal window
bmcli database load --file=network.dbc --name=vehicle
bmcli database load --file=body.ldf --name=body-lin

database unload

Section titled “database unload”
Terminal window
bmcli database unload vehicle
bmcli database unload --all

DBC, LDF, and A2L are peer typed resources. All three unload through this generic lifecycle; there are no dbc unload, ldf unload, or a2l unload aliases.

database list / info / validate

Section titled “database list / info / validate”
Terminal window
bmcli database list --format=json
bmcli database list --type=dbc --format=json
bmcli database info vehicle --format=json
bmcli database validate --file=network.dbc --format=json
bmcli database validate vehicle --format=json

validate --file does not change registry state. A successful validation computes source_hash as lowercase SHA-256 of the source file’s exact bytes; the hash is non-empty, independent of the file path, and changes when any byte changes. DBC, LDF, A2L, CANopen, and EdgeX Modbus profile validation use the same rule. Direct-file validation reports that digest as both source_hash and current_source_hash.

Registered resources retain their load-time source_hash. database list and database info probe the source without changing or deleting the registry and report source_state as available, missing, unreadable, or hash_changed. When readable, current_source_hash contains the live digest; otherwise it is null. A missing or unreadable source remains visible and can still be unloaded. Commands that require a missing or unreadable source fail with the logical resource name, state, and path. source_reason is null for an available source and otherwise explains the state. database info includes its parser summary only while the current source remains parseable; a malformed hash-changed source remains queryable with its parser failure in source_reason.

GET /api/v1/databases and GET /api/v1/databases/{name} expose the same source-state meanings through REST. They keep missing, unreadable, and hash-changed registrations queryable with source_hash, current_source_hash, source_state, and source_reason; parser summaries and DBC message catalogs are returned only for an available source. The REST envelope is transport-specific and need not duplicate the CLI envelope.

All first-load DBC entry points apply the same BO_/SG_ declaration checks before exposing parsed objects. A malformed DBC is rejected consistently by validation, registration, inspection, decode, encode, and message-send preflight; a failed database load leaves no registry entry. Diagnostics include a 1-based line and position where available.

Source of truth: BMCLI 1.6.5 repository documentation. Run bmcli help <category> <action> --format=json for the exact contract of the installed version.