What I need for an analysis

Device and firmware

• Manufacturer, model and hardware revision
• Firmware version when the failure occurred, earlier versions and update history
• Serial numbers or internal IDs of affected units – pseudonymised if necessary
• Number of affected units, roughly in relation to the installed base

Connectivity

• Connectivity type: LAN, Wi-Fi or cellular
• For cellular: modem or module and its firmware, network, type of SIM card
• Signal quality, if logged
• Times of connection drops, ideally with time zone

Backend and OCPP

• Backend (CSMS): name or type, and version if known
• OCPP version and security profile
• OCPP traces covering the failure period, ideally from both charger and backend
• Relevant configuration keys, for example HeartbeatInterval, WebSocketPingInterval, MeterValueSampleInterval

Failure pattern

• What happens, and what should happen?
• Since when, how often, on which units?
• Any correlation with updates, time of day, locations or load situations?
• Error codes and status messages of the charger
• Actions taken so far and their results

Logs and returns

• Device logs covering the failure period, with some lead time
• Clock synchronisation of the units (NTP) and the time zone used
• Test reports of returned units

Calibration law and meter values (if affected)

• Signed meter values, for example OCMF records
• The corresponding public keys and when they changed
• Results of verification with the transparency software

Confidentiality and data protection

• NDA in place; DPA if personal data is included
• Personal data removed or replaced: names, email addresses, charging card identifiers (for example RFID UIDs or idTags), contract and vehicle identifiers
• Raw data only via the case-specific upload link

Via the pilot form I accept pseudonymised data only. Raw data only after NDA/DPA via a case-specific upload link.