comframe
comframe Modules for Charging Protocols and BMS Tests
A module gives comframe the messages, states and measurements of a specific charging or battery-testing application. It helps translate raw data into the terms used by the system being tested.
01 / comframe
A protocol module should explain the test. Not merely decode the bus.
Shared software. Domain-specific meaning.
A generic data tool can show frames, messages and measurement channels. It does not automatically know which charging state the DUT is in, how a low-level signal relates to the communication sequence or which configuration objects belong together.
The comframe protocol modules add that missing engineering context. They map interface-specific data to the selected charging or BMS (battery management system) workflow while the generic core keeps projects, synchronised data, visualization, reports, automation and integration consistent.
Shared software behaviour stays familiar. Domain logic changes with the device and interface under test.
02 / comframe
Choose the module from the DUT, interface and required evidence
Do not select a module because a bus technology appears somewhere in the system. Select it because the test must understand a specific EV charging or BMS domain.
Transport does not define the domain
CHAdeMO and GB/T both use CAN, but their messages, state models, timing and test assets remain different.
Software module and system are separate decisions
The module provides the domain-specific workflow. The configured EVCA, Calimera or BCS hardware determines the physical test scope.
The name alone is not enough
Standard edition, DUT direction, product firmware, module version, licence and Test Library must be confirmed together.
03 / comframe
Choose the module for the interface your product uses
comframe provides domain modules for CCS, CHAdeMO, GB/T, MCS and BMS within a shared workflow. Check the current release matrix for supported functions and combinations.
Applicable NACS and SAE J3400 workflows are handled within the corresponding charging configuration. Confirm the product, connector and standard scope for your project.
Protocol versions, DUT direction and Test Library scope require release-specific confirmation.
CCS / NACS
Adds the charging-specific relationship between low-level signals, PLC (power line communication) communication, HLC (high-level communication) messages, timing and electrical behaviour.
CHAdeMO
Maps CHAdeMO messages, states, timing and charging behaviour into the shared comframe workflow.
GB/T
Adds GB/T-specific message semantics, state logic, timing and physical interface context rather than treating the session as generic CAN traffic.
MCS
Connects 10BASE-T1S communication, MCS low-level states, thermal and cooling information and high-power behaviour in one domain-specific workflow.
BMS
Adds cell, sensor, balancing, isolation, fault and battery-state concepts to the same projects, automation, measurement and evidence foundation.
- Control Pilot (CP) and Proximity Pilot (PP) states
- PLC and SLAC
- DIN 70121 and ISO 15118 context
- TLS and certificate context where configured
- AC and DC measurement context
- CAN communication
- Charging states and requests
- Connector and interlock context
04 / comframe
Connect low-level states, PLC communication and high-level protocol on one timeline
The CCS module is the primary EV charging protocol software path for applicable AC, DC-CCS and related NACS or SAE J3400 configurations. It can connect CP and PP behaviour, PLC and SLAC, HLC messages, timing, certificate context and electrical measurements.
This domain context enables software functions such as standards-aware analysis, configurable simulation, issue reproduction, live gateway workflows and executable Test Libraries where those functions are released for the selected product and standard.
05 / comframe
Keep CHAdeMO and GB/T semantics separate
Both charging families can use CAN communication, but the module must understand more than the transport. Message meaning, state logic, timing, connector behaviour and released test assets differ.
06 / comframe
MCS needs a module built around the complete interface, not only higher current
The MCS module connects communication, low-level states, temperature and cooling context and high-power system behaviour in one workflow. It is associated with the EVCA MCS physical platform and the released MCS software configuration.
The architecture must be qualified with the standard editions, communication stack, low-level signals, measurement channels, cooling interfaces and EV or EVSE (electric vehicle supply equipment, or charging station) test direction for the selected project.
07 / comframe
Give cell and sensor simulation the same project, automation and evidence foundation
The BMS module extends the generic core beyond charging. It relates cell-voltage simulation, NTC and PTC sensor behaviour, balancing, electrical faults, isolation conditions and BMS state information to the configured Battery Cell Simulator.
This creates a purpose-built BMS test software path without forcing engineers to represent battery behaviour through charging terminology. The same comframe principles remain available: projects, configuration, synchronised data, automation, reports and supported interfaces.
08 / comframe
Keep familiar software behaviour while the domain changes
Representative comframe workflow. The delivered interface follows the selected product and software release.
Across supported modules, comframe can provide a common foundation for projects, configuration, synchronised measurement, visualization, filtering, automation, Test Libraries, reports and REST API integration. The current public Release 1.0 material establishes this shared software direction.
Each domain module provides the relevant objects, states, signals and workflows. Panels and capabilities vary across CCS, MCS and BMS.
09 / comframe
Combine the module with the capability required by the engineering decision
Modules enable the domain. Capabilities define the test mechanism.
A domain module alone does not define the complete test. It must be combined with the physical system and the released capability scope.
Automated Standards Analysis
Relate measured behaviour to normative expectations.
Professional Simulation
Configure difficult or non-conform communication behaviour where released.
Charge Playback
Physically reproduce recorded charging-partner behaviour.
Manipulating Gateway
Modify selected communication while both real partners remain connected.
Charge Cycle Automation
Turn saved configurations into repeatable campaigns.
Conformance Test Libraries
Run released test cases for a defined standard, role and scope.
10 / comframe
The product provides the physical test. The module provides its software language.
The table is a routing model. It is not a release matrix. Exact combinations must be confirmed against the selected hardware, licence and software version.
On smaller screens, scroll the table horizontally to see every column.
| Product path | Typical module family | Primary physical role | Qualification |
|---|---|---|---|
| EVCA ComOnly | CCS / NACS | Controller and communication-focused EVCC or SECC testing. | Confirm protocol, DUT direction and capability licence. |
| EVCA Multi Mobile | CCS, CHAdeMO, GB/T | Portable EV, EVSE and interoperability analysis. | Connector, power and gateway scope are configuration-dependent. |
| EVCA Interop | CCS, CHAdeMO, GB/T | Real EV to real EVSE root-cause analysis. | Confirm passive or manipulating mode, TLS and evidence scope. |
| EVCA Flex | CCS, CHAdeMO, GB/T | Modular laboratory integration, power and fault testing. | Confirm source, load, power level and electrical fault hardware. |
| EVCA MCS | MCS | Megawatt Charging EV and EVSE testing. | Confirm communication, low-level, cooling and power scope. |
| Battery Cell Simulator | BMS | Cell, sensor and fault simulation for BMS validation. | Confirm BCS generation, channels, sensors, currents and faults. |
FAQ
Frequently asked questions
What is a comframe protocol or domain module?
It is the software layer that adds the terminology, signals, messages, states, configuration objects and test workflows of a specific EV charging or BMS domain to the shared comframe core.
Why does comframe use modules instead of one generic data viewer?
A generic viewer can display bus traffic and measurements. A domain module relates that data to the charging or BMS state, the device under test and the expected workflow. This is required for standards-aware analysis, usable simulation and attributable results.
Which domain module families does comframe provide?
The public architecture uses CCS, CHAdeMO, GB/T, MCS and BMS module families. Exact protocol editions, DUT directions, hardware connections and software functions depend on the current release and selected configuration.
Is NACS a separate comframe module?
Not in the current public architecture. Applicable NACS and SAE J3400 workflows are handled within the corresponding charging configuration and must be confirmed by product, connector and standard scope.
What does the CCS module add?
It can connect CP and PP states, PLC and SLAC, high-level charging communication, timing, certificate context and electrical measurements for applicable AC, DC-CCS and related charging configurations.
Why are CHAdeMO and GB/T separate modules if both use CAN?
The transport technology does not define the complete test domain. CHAdeMO and GB/T use different message semantics, state models, timing rules, interface concepts and test assets. Separate modules preserve that meaning.
Software workflow
Connect the test system to the engineering workflow.
Define the domain module, released interfaces, control model and evidence exchange.