Contact & Support
Get Help with a Charging or BMS Test
Tell application support what you expected, what happened and which system you used. Include the configuration and recording so the team can investigate the same conditions.
Evidence before escalation.
APPLICATION SUPPORT
Investigate the observed failure using its recorded test conditions.
COMEMSO SYSTEM
System
Context
Release
Version
DUT
Identity
Reproduce
Same case
Evidence
Trace
Action
Verified
SERVICE SCOPE · EVIDENCE · OWNERSHIP
01 / Contact & Support
Route the question before collecting more screenshots
Different technical questions require different owners. A support request should make the decision type explicit.
Operation and setup
Clarify a released function, connection, project setup, configuration or normal operating sequence.
Unexpected test result
Review a repeatable deviation with configuration, DUT (device under test), expected behaviour and captured evidence attached.
Suspected equipment issue
Route damage, failed self-check, unusual behaviour or measurement concern to product service or calibration.
New capability or integration
Treat a new standard, hardware interface, automation function or third-party device as an enhancement request.
- System and release known
- Expected workflow identified
- Question reproducible without hardware service
- Expected versus actual
- Time-correlated evidence
- Repeatability and boundary stated
- Stop if safety is uncertain
- Record as-found state
02 / Contact & Support
Make the first support message technically usable
The request should preserve the chain from system identity to observed behaviour.
1. System
Product name, serial number, hardware generation, modules, accessories and recent physical changes.
2. Release
Software, firmware, domain module, Test Library and relevant configuration version.
3. DUT
Device, role, connector, protocol, power path, test direction and third-party equipment.
4. Reproduction
Prerequisites, exact steps, timestamp, frequency and whether a second DUT or configuration changes the result.
5. Expected result
The expected state, message, measurement, verdict or workflow outcome and its technical basis.
6. Actual evidence
Project export, report, trace, screenshot, error text, logs and time-correlated measurements.
03 / Contact & Support
Reproduce, isolate and decide the next owner
Support should reduce uncertainty without silently changing the technical question.
Confirm intake
Check that the system, release, DUT, evidence and safety state are sufficient for analysis.
Reproduce or delimit
Determine whether the result is repeatable and whether it follows the DUT, configuration, interface or equipment.
Compare the baseline
Review the released workflow, known conditions, expected states and relevant documentation.
Form a hypothesis
Identify the smallest technical explanation that fits the evidence.
Request targeted evidence
Collect only the additional trace, measurement or configuration needed to test that hypothesis.
Close or reroute
Resolve the application question or route product service, calibration, custom engineering or consulting with the context preserved.
- 01 Confirm intake Check that the system, release, DUT, evidence and safety state are sufficient for analysis.
- 02 Reproduce or delimit Determine whether the result is repeatable and whether it follows the DUT, configuration, interface or equipment.
- 03 Compare the baseline Review the released workflow, known conditions, expected states and relevant documentation.
- 04 Form a hypothesis Identify the smallest technical explanation that fits the evidence.
- 05 Request targeted evidence Collect only the additional trace, measurement or configuration needed to test that hypothesis.
- 06 Close or reroute Resolve the application question or route product service, calibration, custom engineering or consulting with the context preserved.
04 / Contact & Support
Application Support helps interpret the released workflow. It does not replace every engineering authority.
Clear boundaries protect safety, evidence and accountability.
On smaller screens, scroll the table horizontally to see every column.
| Boundary | Support contribution | Authority retained elsewhere |
|---|---|---|
| Official standards | Support can explain product use in the relevant context. | The official document and approved edition remain authoritative. |
| Compliance or certification | Support can help prepare and understand evidence. | Only the competent test or certification body issues the formal decision. |
| Customer DUT design | Support can analyse interaction with the test system. | The customer retains design and safety responsibility for the DUT. |
| Third-party equipment | Support can review a defined interface where released. | Compatibility and ownership must be agreed. Undocumented control is not implied. |
| Remote action | Remote review can accelerate analysis. | Local interlocks, emergency controls and qualified personnel remain authoritative. |
| Response and availability | The public route accepts requests. | SLA, hours, on-site service and escalation depend on the contract and region. |
05 / Contact & Support
Find the product information, documentation or support contact you need.
Self-service is useful when it reduces ambiguity. Historical documents must not override current release information.
Product Page
Confirm the intended system role, released configuration and product boundaries.
Supported Standards
Identify document, part, edition, DUT role and technical layer.
Knowledge Center
Find test methods, terminology and topic routes.
Resources Library
Open current resources and clearly dated historical evidence.
E-learning Portal
Review entitled product and application training content.
Firmware Update
Contact support for current firmware and software update guidance.
06 / Contact & Support
Send the evidence packet through the current support route
The public support route covers Germany and North America. Contract-specific channels remain valid where agreed.
Support team
Use the public form when email is not the appropriate route.
comemso North America Corp.
Use the public form when email is not the appropriate route.
Contact page
Use the public form when email is not the appropriate route.
08 / Contact & Support
Preserve the evidence chain before escalation.
Send system identity, versions, DUT, reproduction steps, expected behaviour and captured evidence.
FAQ
Frequently asked questions
What is Application Support?
Application Support helps with released test-system setup, reproducibility, evidence interpretation and application-specific workflows. It connects the system, release, DUT and observed result before identifying the next action.
What information should be included in a support request?
Include product and serial number, hardware and software versions, configuration, DUT and test direction, exact steps, expected and actual behaviour, logs, reports, traces, screenshots and the current safety state.
Can support analyse a screenshot without the project or trace?
A screenshot may illustrate the symptom but rarely preserves configuration, timing and context. The project, report, trace or relevant export should be included wherever possible.
What should I do if equipment safety is uncertain?
Stop operation, move the system to the applicable safe state, preserve the as-found condition and follow local safety procedures. Do not continue remote troubleshooting through an unsafe electrical condition.
Does support confirm that my DUT complies with a standard?
No. Support can help operate the system and understand evidence. Formal compliance or certification decisions belong to the competent test or certification body and the applicable approved scope.
Can Application Support change the software or add a function?
A support case can identify a defect, configuration issue or enhancement need. A new function, interface or project-specific change is routed through product management or Custom Solutions and requires separate feasibility and release control.
What does this service include, and what should we agree in advance?
Agree the system, release and reproducible issue before troubleshooting. The linked answers cover the service scope, request evidence, screenshot limits and safe operation.
Field workflow planning
Choose the tool from the service question.
Describe your test system, hardware and software versions, the expected result and the observed behaviour. Include the steps and available logs needed to reproduce the issue.