Contact & Support

Adapt a Test System to Your Application

Extend a standard platform when your device, connection or workflow needs an additional function. Define the interface, responsibilities and acceptance test before the custom integration begins.

Custom where needed. Standard where proven.

CUSTOM SOLUTIONS

Protect the validated core while adapting modules, interfaces and workflows.

COMEMSO SYSTEM

  1. Core

    Released

  2. Modules

    Project fit

  3. Interfaces

    Connected

  4. Acceptance

    Evidence

  5. Lifecycle

    Supported

REFERENCE CORE · PROJECT MODULES · LIFECYCLE

Known counterpartTest without a customer vehicle
Guided workflowRepeatable checks for technicians
Defined boundaryFunction, safety or metrology by product
Documented resultKeep the inspected-unit record

01 / Contact & Support

Use proven platform functions wherever the problem is already solved

Complexity belongs in the background.

ENGINEERING WORKFLOW

Connect the test object once, then turn signals into repeatable engineering evidence.

COMEMSO SYSTEM

  1. Connect

    Interfaces

  2. Simulate

    Behaviour

  3. Analyse

    Signals

  4. Automate

    Sequences

  5. Prove

    Evidence

DEEP TESTING · CLEAR OPERATION · REUSABLE EVIDENCE

Custom engineering should concentrate on the project boundary. It should not recreate productized test knowledge, safety functions or data workflows without a reason.

Released platform core

Start with the suitable product family and its supported operating model. comframe supports the compatible EVCA, Calimera and Battery Cell Simulator configurations. Easy Chester provides standalone operation without a laptop.

Configured standard functions

Select released interfaces, protocols, measurements, capabilities, Test Libraries, reports and automation required by the application.

Project modules

Add mechanics, switching, cooling, wiring, adapters, software objects or test sequences that are specific to the agreed project.

Third-party systems

Define commands, data, timing, safe states, ownership and support for source, load, HiL (hardware-in-the-loop), MES, database or other external equipment.

Acceptance and lifecycle

Prove the agreed scope, deliver documentation and training, and define changes, updates, spares and long-term ownership.

Define the custom hardware, interfaces and responsibilities

02 / Contact & Support

The final architecture may span hardware, software, mechanics, power, metrology and operating processes.

DUT interfaces

Project-specific connectors, fixtures, adapters, breakouts, switching and signal access around a defined DUT (device under test) boundary.

Power and load integration

Selection and coordination of source, load, regenerative equipment, switching, cooling and safety for the required operating envelope.

Fault and measurement modules

Released or project-specific fault paths and measurement channels with explicit limits and safe-state control.

Mechanical integration

Rack, trolley, case, production fixture, cable management, service access and environmental constraints.

Software and automation

comframe projects, workflows, API contracts, external equipment adapters, report logic and attributable data handover.

Production and metrology

Cycle time, variant management, MES, unit identity, reference meters and market-specific metrology boundaries.

Close the acceptance question before engineering starts

03 / Contact & Support

A supportable custom system is built through explicit gates.

Requirements and exclusions

Define DUT, lifecycle, interfaces, limits, standards, evidence, assumptions and what the project will not include.

Architecture and ownership

Assign control, safety, timing, data, mechanical, metrology and third-party responsibilities.

Released core selection

Choose the closest supported product, software modules and standard functions before adding project work.

Engineering and integration

Implement the approved modules and interfaces under version and change control.

Verification and acceptance

Execute defined factory or site acceptance criteria with attributable results and open-item handling.

Handover and lifecycle

Deliver documentation, training, backups, spares, update rules, support boundaries and change ownership.

  • 01 Requirements and exclusions Define DUT, lifecycle, interfaces, limits, standards, evidence, assumptions and what the project will not include.
  • 02 Architecture and ownership Assign control, safety, timing, data, mechanical, metrology and third-party responsibilities.
  • 03 Released core selection Choose the closest supported product, software modules and standard functions before adding project work.
  • 04 Engineering and integration Implement the approved modules and interfaces under version and change control.
  • 05 Verification and acceptance Execute defined factory or site acceptance criteria with attributable results and open-item handling.
  • 06 Handover and lifecycle Deliver documentation, training, backups, spares, update rules, support boundaries and change ownership.

04 / Contact & Support

Examples show the engineering pattern. They do not define the current universal offer.

Every example remains tied to its date, customer context and released project scope.

Easy Chester EOL with customer power electronics

A published customer project combined a released production-test system with internally developed power electronics. The pattern is a standard product with a separately defined equipment interface.

Easy Chester Long Duration Unit

A dated system example added a 1.8 kW extension for up to 60 minutes of continuous testing. It illustrates a focused project extension around a real operating need.

Modular EVCA and comframe integration

EVCA Flex and comframe support project-specific combinations of charging interfaces, external power equipment, faults, automation and evidence.

  • Customer hardware remains a named boundary.
  • Command ownership and integration scope are explicit.
  • Current API and product compatibility require confirmation.
  • Do not infer current availability from the article alone.
  • comemso does not claim to analyse OCPP in that example.
  • Current product, power and timing scope require release approval.
  • Use released modules first.
  • Define external hardware adapters and safety ownership.

05 / Contact & Support

The deliverable is more than assembled hardware

The contract should make the test and support boundary reviewable after handover.

Requirements baseline

Approved use cases, DUT, standards, interfaces, limits, evidence, assumptions and exclusions.

System architecture

Hardware, software, mechanics, power, network, safety and third-party ownership.

Interface contract

Commands, data objects, timing, authentication, errors, safe states and version compatibility.

Configuration and software

Released product configuration, project files, licences, modules, source ownership and deployment package.

Acceptance plan

Factory and site criteria, test data, open-item process, responsibilities and sign-off.

Documentation

Operating, safety, maintenance, integration, backup, restore and change-control information.

Not every requested combination should become a product

06 / Contact & Support

A request proceeds only when it can be made safe, testable, supportable and commercially explicit.

On smaller screens, scroll the table horizontally to see every column.

GateQuestionStatus
SafetyCan the operating envelope, access, interlocks, faults and safe states be engineered and validated?Mandatory
Technical feasibilityCan the required interfaces, timing, measurement and power behaviour be achieved?Mandatory
Product fitIs there a released platform close enough to preserve supportability?Preferred
Standards and metrologyAre the relevant documents, editions, roles and legal boundaries identified?Mandatory where applicable
AcceptanceCan success and exclusions be proven with objective criteria?Mandatory
LifecycleCan updates, calibration, spares and change ownership be sustained?Mandatory
Schedule and capacityCan development and validation be completed without hiding uncertainty?Commercial gate
IP and dataAre ownership, confidentiality, source access and evidence retention defined?Contract gate

Use the relevant standard product or service page

07 / Contact & Support

Explore standard products, integration interfaces and applicable standards to define the basis for your custom solution.

Quote & Configurator

Capture the application, technology, limits, capabilities and existing infrastructure.

comframe Integration & APIs

Define REST API, HiL, CI/CD, third-party equipment and evidence handover.

Product Platforms

Select the product and its supported operating model before defining project modules.

Consulting

Clarify strategy, standards, reuse and roadmap when the requirement is still ambiguous.

09 / Contact & Support

Turn the project boundary into acceptance criteria.

Start with the released core. Define interfaces, safety, evidence, ownership and lifecycle before integration.

FAQ

Frequently asked questions

It is a project-specific configuration or extension built around a released comemso platform, explicit interfaces, acceptance criteria and lifecycle ownership. It is not an undefined promise to implement every requested function.

Usually not. The preferred architecture uses released hardware, software and test functions as the core, then adds only the project modules required by the application.

It can be considered where a released or project-approved interface exists. Commands, timing, safety, safe states, data, support and ownership must be defined. The agreed interface is specific to the delivered system.

Yes, in applicable projects. The interface contract must define control ownership, commands, data, authentication, timing, errors, evidence, retention and long-term support.

Safety ownership is allocated explicitly across local hardware, comemso components, third-party equipment, customer infrastructure and operating procedures. Software control never replaces physical safety functions.

Acceptance should use a defined plan covering use cases, interfaces, limits, safe states, evidence, reports, failure handling and exclusions. Factory and site acceptance may be separated.

What does this service include, and what should we agree in advance?

Agree the test task and the interfaces around the released platform. These answers explain the solution basis and the conditions for integrating customer equipment and external systems.

Field workflow planning

Choose the tool from the service question.

Describe the test task, required interfaces and operating ranges, and the equipment to be integrated. Tell us which acceptance criteria are already defined.