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 result. 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.
Keep DUT build, configuration revision, run ID and evidence linked throughout. Endpoint, product and data scope remain release and configuration dependent.
Use comframe test logic with external automation
Keep ISO 15118 state behaviour, battery management system (BMS) condition logic, timing evaluation and result 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 results
comframe
- Validates the selected configuration
- Controls the released test behaviour
- Synchronizes measurements and protocol data
- Evaluates the configured test and returns status and results
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 evidence 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.
REST API
Use the published programmatic boundary for applicable workflows. Endpoint and authentication scope remain release-specific.
HiL and test benches
Connect a real charging or BMS test system to the existing laboratory sequence and resource model.
CI/CD and regression
Trigger approved physical campaigns after software changes under guarded laboratory conditions.
Power and measurement
Coordinate external sources, loads and instruments where the project integration supports them.
Data and quality systems
Transfer result metadata and approved evidence to test-management or quality processes.
Custom interfaces
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 evidence. 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.
Control approved workflows
Select a released project or configuration, provide permitted parameters and check that the test asset is ready.
Execute and monitor
Start, stop and monitor a physical test within the comframe state machine and hardware safety boundary.
Coordinate the laboratory
Connect HiL, sequencers, external power hardware and test resources while keeping charging-specific test logic in comframe.
Keep returned measurements with their test conditions
Return status, measurements, verdicts, reports and identifiers together with the DUT and configuration revisions used for the test.
On smaller screens, scroll the table horizontally to see every column.
| 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 evidence | 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 line control | Released test workflow, results 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 the evidence.
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
The available integration differs by product and configuration. Use this matrix to discuss the required scope; confirm the released interface before implementation.
On smaller screens, scroll the table horizontally to see every column.
| System | Primary integration use | Typical value | Approval gate |
|---|---|---|---|
| EVCA ComOnly | Controller bench and protocol development | Strong fit for remote selection, execution and evidence 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 evidence 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 evidence.
- 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
Plan API design, laboratory safety and configuration management together. 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. Keep the device under test, configuration and run linked in the result records so the evidence can be used in test management or quality processes.
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 evidence. 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. The integration scope must identify which configurations, commands, states, results and reports are required and confirm that each is available through the selected interface.
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. The supported interface and client responsibilities must be confirmed for the project.
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, result 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
Connect your test system with the engineering workflow
Define the domain module, released interfaces, control model and evidence exchange.