comframe
Connect comframe to your test automation
Connect your test sequencer or HiL system to comframe through the released interface. Select a test, request its start, monitor the status and retrieve results.
Test scenario: Schematic automation flow
Select an available configuration, request a test start, read its status and retrieve its outcome. Handle a rejected command or failed test explicitly before continuing. This describes the workflow, not API endpoint names: use the interface documentation for the actual commands, permissions and data formats.
Define the control and results your automation needs
Basis and scope
Source text dated:
01 / comframe
Connect external automation to the comframe workflow
- Configure
Select the project, approved configuration and permitted parameters.
- Coordinate
Coordinate HiL, power equipment, test benches and laboratory resources.
- Execute
Start, stop and monitor the test through the released interface.
- Retrieve
Collect status, measurements, verdicts, reports and approved exports.
- Repeat
Run repeatable regression sequences under controlled laboratory conditions.
Use comframe test logic with external automation
Keep ISO 15118 state behaviour, battery management system (BMS) condition logic, timing evaluation and data correlation in the released comframe workflow. The external system defines when and why a test runs. comframe handles the configuration, execution state, synchronised data and domain-specific evaluation.
Keep responsibilities clear between the external system and comframe so the integration remains maintainable as DUT (device under test) versions, standards, hardware modules or test campaigns change.
External system
- Provides order, DUT and build context
- Selects an approved workflow
- Triggers and monitors execution
- Coordinates shared laboratory resources
- Receives attributable test evidence
comframe
- Validates the selected configuration
- Controls the released test behaviour
- Synchronizes measurements and protocol data
- Evaluates the configured test and returns status and verdicts
02 / comframe
Use the same test workflow for engineering and external automation
Use the same approved comframe test asset for interactive engineering, a HiL (hardware-in-the-loop) sequence or a CI/CD trigger. Domain logic and evaluation remain controlled in each workflow.
03 / comframe
Connect the functions your engineering process needs
Define the interface around the workflow and functions you need. Use a focused integration specification for validation, security and maintenance.
Use the published programmatic boundary for applicable workflows. Endpoint and authentication scope remain release-specific.
Connect a real charging or BMS test system to the existing laboratory sequence and resource model.
Trigger approved physical campaigns after software changes under guarded laboratory conditions.
Coordinate external sources, loads and instruments where the project integration supports them.
Transfer metadata and approved results to test-management or quality processes.
Add project-specific adapters only where the released standard interface does not cover the required boundary.
04 / comframe
Control approved tests through the REST API
Representative comframe workflow. The delivered interface follows the selected product and software release.
REST API as the preferred programmatic boundary
The comframe REST API provides a stable concept for external control where the required functions are released. The integration contract should name the configuration objects, commands, states, result references and error behaviour needed by the project.
An EV charging test API is useful only when it preserves the physical and the applicable standard requirements of the test. The API should therefore request an approved action and return its state and outcome. It should not bypass hardware interlocks or allow undocumented control paths.
Record client, comframe, product and module versions.
05 / comframe
Coordinate physical tests through a defined interface
External automation can coordinate a charging or BMS test when resource ownership, hardware readiness, safe states and recovery are defined. The laboratory safety concept remains authoritative.
Select a released project or configuration, provide permitted parameters and check that the test asset is ready.
Connect HiL, sequencers, external power hardware and test resources while keeping charging-specific test logic in comframe.
| External workflow | What it contributes | What remains in comframe | Critical qualification |
|---|---|---|---|
| HiL sequence | DUT stimuli, vehicle states and system-level timing | Charging or BMS test configuration, data correlation and evaluation | Master timing, ownership and safe-state definition |
| CI/CD pipeline | Build trigger, DUT version and release gate | Approved campaign execution and result package | Laboratory availability, guarded execution and retry policy |
| Lab sequencer | Shared equipment, environmental conditions and test order | Domain-specific test behaviour and synchronised measurement | Resource locking and command responsibility |
| Production system | Serial number, order data and production control | Released test workflow, verdicts and report references | Cycle time, recovery, traceability and EOL product scope |
06 / comframe
Link results to the test conditions
Link DUT, configuration and run identifiers with measurements and reports so the receiving process can assess and use them.
DUT identifier, software or hardware build, test order, operator or automation source.
Project, test asset, parameter set, module and revision used for the run.
Start and stop time, system state, interruptions, retries and completion status.
Measurements, traces, standards-aware evaluations, verdicts and deviations where released.
Report and approved export references, including retention and access rules.
Client, API, comframe, firmware and module versions that formed the agreed test requirements.
07 / comframe
Choose the integration for your test system
Use this matrix to discuss the required scope; confirm the released interface before implementation.
| System | Primary integration use | Typical value | Approval gate |
|---|---|---|---|
| EVCA ComOnly | Controller bench and protocol development | Strong fit for remote selection, execution and evaluation in communication-focused workflows. | Confirm released API and protocol scope. |
| EVCA Flex | Modular laboratory and high-power integration | Strong fit for laboratory sequencing, external power coordination and regression. | Confirm hardware adapters, timing and safety ownership. |
| EVCA MCS | Megawatt Charging laboratory tests | Fit for coordinated MCS communication, signals, cooling and power workflows. | Confirm released MCS functions and equipment interfaces. |
| EVCA Multi Mobile / Interop | Portable and real-pair analysis | Selected remote-control, capture and reporting workflows can be relevant. | Field and test-event operation may require local control. |
| Battery Cell Simulator | Cell, sensor and fault simulation for BMS | Fit for BMS test automation, HiL sequencing and repeatable condition sets. | Confirm the Battery Cell Simulator generation, channel scope and safety. |
08 / comframe
Choose native workflow, API or custom integration
Native comframe workflow
Use the native workflow for interactive configuration, engineering analysis and maintenance with direct comframe control.
- Lowest integration effort
- Full released user workflow
- Direct visual analysis
REST API orchestration
Use REST API orchestration when a HiL system, pipeline or sequencer triggers repeatable approved tests and retrieves the reports.
- Clear programmatic boundary
- Reusable external orchestration
- Domain logic stays in comframe
Custom integration
Use custom integration when third-party equipment or a production environment needs an adapter beyond the released standard interface.
- Project-specific scope
- Higher validation effort
09 / comframe
Keep physical execution under laboratory control
Confirm that a command is approved for the intended operation, even if it is technically reachable.
10 / comframe
Plan the connection to your test environment
Agree how comframe and the external application work together before implementing the connection. Document the test workflow, result exchange and responsibilities in a shared integration specification.
Test workflow and control
Start with the selected test system, product configuration and the tasks your external application will control. Confirm which API functions are released for that scope, which commands are permitted and how states and errors are reported. This defines how the application can coordinate the test.
Data and results
Define which measurements, results and reports your receiving system needs and which released formats it can use.
Responsibilities and operation
Assign control of external equipment and define access permissions, security responsibilities and physical safety boundaries. Record the client, API, comframe and module versions, and agree who maintains and supports the integration. This keeps responsibilities clear when the setup or software changes.
FAQ
Frequently asked questions
What is comframe Integration & APIs?
Released comframe interfaces let an external system select approved test assets, trigger execution, monitor status and retrieve defined results. Use this integration while keeping charging and BMS domain logic in comframe.
Is a REST API available for comframe?
A REST API is part of the published comframe baseline. Exact endpoints, authentication, product coverage, payloads and file formats depend on the current software release, licensed modules and project configuration.
Does the API expose every function available in the comframe user interface?
Not automatically. API coverage is release-specific.
Can a Python program control comframe?
A Python application can act as a REST client when it follows the released API contract. This does not imply that a separate Python SDK or every comframe function is available.
Can comframe be integrated into a HiL system?
Yes, applicable configurations can be connected to a HiL or laboratory sequencer. The project must define control ownership, timing, external hardware, safety interlocks, data exchange and the supported comframe product scope.
Can CI/CD trigger physical EV or EVSE tests?
A CI/CD workflow can trigger approved test campaigns when the laboratory has controlled resource allocation, safe operating states, qualified hardware and a clear recovery strategy. A software pipeline must never bypass physical safety controls.
Software workflow
Agree the released interfaces, control and data exchange.