Integration assessment requires the actual devices and application protocols on both sides. A brand name or a statement that CAN is supported is insufficient. List available documents, missing inputs and test conditions to separate protocol analysis, customer-board firmware and device integration work.
Project Input Checklist
| Input Group | Required Information | Decision Supported |
|---|---|---|
| Equipment identity | Battery, BMS or BMU and inverter models and firmware, system connections | Protocol applicability and version differences |
| Application protocols | Actual CAN documents, versions, field definitions and permitted use | Frame decoding, limits and state mapping |
| Electrical interface | Pinouts, supply, reference ground, termination, harness and isolation | Board selection and connection conditions |
| Raw samples | Timestamped messages, configuration and known operating conditions | Fields, timing, signs and startup behavior |
| Board and software | Schematics, controllers and transceivers, SDK, drivers and existing code | Firmware implementation and interface resources |
| Tests and deliverables | Available devices and personnel, operating scope, milestones and pass criteria | Integration plan, acceptance and cost boundaries |
How to Confirm the Protocol Documents
Check the interface, version and applicable models stated in each document. An RS485 document does not replace a CAN application protocol, and similar protocol names do not establish the same version. Brand, model and compatibility statements in reference diagrams require confirmation against actual devices and test records. For restricted manufacturer documents, agree on permitted use and review arrangements before sharing them.
What Can Start with Incomplete Inputs?
Initial work can include an input gap register, interface resource review, analysis of available messages and a bounded prototype plan. Missing limits, states or timeout definitions leave the corresponding functions unconfirmed. Simulator tests and device integration are separate milestones when equipment is unavailable. A quotation should distinguish executable work, work dependent on additional inputs and sample or testing costs.
Freeze Input Versions Before Acceptance
Link the delivery list to device, protocol, board and firmware versions, with test cases and open issues retained. A different inverter model, firmware update, message change or replacement board requires impact review and relevant regression tests. An earlier device combination does not automatically validate the changed system.
Questions and Answers
What work can start when protocol or equipment information is incomplete?
Work can first identify missing inputs, review available interface information and establish authorized message capture and equipment support. If critical fields, states or test devices are unavailable, an input review must not be reported as completed integration or as a commitment that all functions will pass.
Which version details are needed in addition to equipment names?
Record both device models, BMS and inverter firmware, their protocol versions, and the gateway board, MCU, SDK and driver versions. Messages and test records should trace to that version set rather than combining information from different revisions into one acceptance baseline.
How should a protocol or firmware change during development be handled?
Record the previous and new versions and the affected fields, interactions and test cases, then define the additional development and regression scope. Update the mapping table and acceptance baseline and verify the affected functions. Passing records for the old version do not directly establish a pass for the new one.
Online
Phone
WeChat
Top