An SOC display alone does not establish completed integration. The value may come from only some status messages or from cached data. It does not prove correct interaction for all limits, alarms and control states. Acceptance should cover the required data and states defined in the protocol, with equipment, firmware and test conditions recorded.
Suggested Acceptance Checks
| Check | What to Observe | Evidence to Retain |
|---|---|---|
| Data consistency | Units, direction, scaling and validity of SOC, voltage, current and temperature | Raw messages, decoded data and device displays |
| Operating constraints | Protocol transfer of permitted voltage, current and charge or discharge enable | Input limits, conversion results and device response |
| Alarms and states | Consistent alarm activation, clearance and state transitions | State sequences, timestamps and logs |
| Link loss and stale data | Detection and specified handling of stopped messages, lost links or invalid fields | Timeout definitions, trigger steps and actual behavior |
| Recovery and restart | Initialization and permitted recovery after reconnection or restart | Startup logs, recovery sequences and open issues |
How to Define Pass Criteria
Before testing, define input conditions, expected outputs, permitted tolerances or time windows, responsibility for device operation and evidence format. Charging and discharging tests are performed by the project party equipped to operate the system. A gateway must not fabricate normal states to bypass BMS or inverter protection. This table supports test planning; thresholds come from the device protocols and the agreed test plan.
How to Record Milestone Results
Record message decoding as field sample verification. Record partial interaction on a development board with its actual prototype scope. Device tests report pass, fail and unverified cases individually. Model or firmware changes need regression assessment. A single display observation does not replace unperformed operating conditions or continuous operation tests.
Questions and Answers
Does a plausible SOC value pass if the data is stale?
A plausible value alone is insufficient. Check data timing, validity, timeout behavior and recovery conditions against the target protocol. Keep input messages and timing records in the acceptance evidence so that a continuously displayed old value is not mistaken for a healthy link.
What evidence should a link-loss and recovery test retain?
Record equipment and firmware versions, normal input, the message-stop or disconnection condition, event timing, outputs or states on both sides, recovery steps and the actual result. Timeout thresholds and expected behavior come from the applicable protocols and project test plan; this general article does not invent universal values.
Does the previous acceptance result cover a BMS or inverter firmware upgrade?
The old record remains evidence for the original tested combination. Applicability to a new version requires a review of protocol and behavior changes. Identify the affected fields, limits, alarms, startup, timeout and recovery cases, run the relevant regression tests and record a result for the new version.
Online
Phone
WeChat
Top