Delphi / Autocom in an Evidence-Driven Multi-Brand Workflow

What Delphi / Autocom is used for

Delphi (now Delphi Technologies / PH2 VCI) and Autocom are multi-brand diagnostic platforms covering a wide range of vehicle makes. They provide:

• System scan — reads fault memory across accessible modules
• DTCs and freeze frames — fault detail with conditions
• Live data — parameter values per module
• Actuator / output tests — command components (where supported)
• Adaptations / settings — some module configuration (coverage varies)
• Generic OBD-II — standard emissions-related access

In an evidence-driven workflow, Delphi / Autocom is the evidence acquisition tool. MechanIQ is the reasoning layer that consumes its output and finds the next best test.

Scan tool vs MechanIQ — correct positioning

| Role | Owner | |---|---| | Acquire vehicle evidence (system scan, DTCs, live data, actuator results) | Scan tool (Delphi / Autocom) | | Interpret evidence, rank hypotheses, recommend next-best test, verify repair | MechanIQ |

MechanIQ does not replace the tool. It takes the evidence the tool produces and applies structured diagnostic reasoning.

System scan

The system scan reads fault memory across the modules the tool can access for the identified vehicle. Save the full scan before clearing anything. On multi-brand tools, note which modules were read and which were not — coverage gaps are themselves information.

DTCs and freeze frames

Delphi / Autocom reports DTCs with freeze-frame conditions where available. The freeze frame captures the operating state when the fault set — this is the condition to reproduce during testing. Read the freeze frame, not just the code.

Live data

Live data streams parameter values per module. As with any tool, the diagnostic value is in cross-parameter relationships and requested-vs-actual comparisons where the tool exposes them:

• Fuel trims (STFT/LTFT) vs load
• MAF / MAP vs calculated load
• Rail pressure vs command
• Battery / charging voltage vs RPM

Log values under the complaint condition where the tool supports logging.

Actuator tests where applicable

Actuator / output tests command a component directly (solenoid, relay, injector, EGR, fan). A component that responds to an actuator test is electrically functional — that is strong evidence narrowing the fault to control, mechanical, or sensor-input causes. Coverage varies by model; use where available.

Generic / multi-brand use

Delphi / Autocom's strength is breadth across makes. For a workshop servicing many brands, it is a practical primary tool. For deep, manufacturer-specific workflows (e.g., BMW no-start immobiliser, VAG mechatronic adaptation), a brand-specific tool may be needed alongside it.

Vehicle identification limits

Multi-brand tools identify the vehicle by VIN and decode to model/engine — but identification precision can be lower than a brand-specific tool. Confirm vehicle identity (engine code, transmission, market) independently before relying on parameter names or specifications. A parameter labelled generically may not map to the exact system on a specific variant. Vehicle-specific verified specification required.

Exporting / copying results

• Scan report — export to text/PDF
• Live-data log — export to CSV/Excel where supported
• Freeze frames — copy from the fault screen

The exported scan report and live-data log are the evidence artefacts that import into MechanIQ.

How MechanIQ uses imported evidence

MechanIQ ingests:

1. The scan report — all module fault memory and freeze frames
2. Live-data logs — parameter values over time
3. Actuator-test results — component functional/functional-not responses

It structures the evidence, identifies the affected system, ranks hypotheses, and recommends the next-best test that most changes the probability — accounting for the tool's coverage limits.

Common limitations

• Coverage gaps — some modules or data blocks may not be accessible on every vehicle
• Parameter naming — generic labels may not match the specific system
• Adaptation depth — deep coding may require a brand-specific tool
• Identification precision — confirm engine/variant independently

When the tool cannot reach a module, MechanIQ flags the communication gap as a hypothesis (module power/ground or bus) rather than assuming the module is faulty.

Example multi-brand diagnostic workflow

1. Complaint: "Low power, warning lamp, mixed-brand fleet vehicle."
2. Delphi / Autocom system scan: Engine — P0299 (underboost); other modules read OK.
3. Live data (road test): requested boost vs actual — actual stalls under load.
4. Actuator test: wastegate solenoid clicks — electrically functional.
5. MechanIQ interpretation: control functional, boost leak or mechanical.
6. Next-best test: boost-leak test (MechanIQ recommendation).
7. Result: split charge-air hose.
8. Repair + verify: requested vs actual within tolerance on road test; no code return.

The scan tool acquired the evidence; MechanIQ reasoned to the next best test. No parts were replaced on guess.

Trademark disclaimer

Delphi and Autocom are trademarks of their respective owners. MechanIQ is not affiliated with, endorsed by, or sponsored by any of these companies. All references identify the tools for diagnostic purposes only. Vehicle-specific verified specification required for all tests.