HMI Approval Interface

This document is an integration guide for the machine-side ECU FOTA workflow. It describes what needs to be implemented at each checkpoint — from signaling update availability to the operator, through to confirming that the new ECU firmware is working correctly. For the underlying CANopen object definitions, addresses, state machine details, and the state machine diagram, refer to the CANopen Specification.

This document is intended for the engineering team responsible for the machine's on-board software - typically the team developing the HMI display logic and ECU application validation.

Note

The OEM is responsible for ensuring the ECU is in a state that accepts a UDS programming session before approving the update. This includes verifying that no active processes on the machine interfere with CAN communication during flashing. Consult the ECU manufacturer's documentation for the specific preconditions required by your ECU model.

Terminology

Throughout this document, the following terms are used:

Term	Meaning
HMI	The operator-facing display or control panel on the machine
CANopen client	Any software component that reads or writes the ECU FOTA CANopen objects
OEM logic	The OEM-side software responsible for Checkpoint 2 — verifying ECU health after flashing

Checkpoint 1 is an operator decision, typically surfaced through the HMI. Checkpoint 2 is an automated software check, typically performed by OEM logic without operator involvement. Both checkpoints use the same CANopen interface.

The approval workflow can be implemented in HMI systems, PLCs, embedded OEM software, CANopen gateways, or custom logic running in the Proemion Configurator. The implementation approach is customer-specific.

Workflow Overview

The machine-side workflow consists of two mandatory checkpoints. The TCU waits for confirmation at each checkpoint before proceeding. The update is only finalized on DataPlatform after both checkpoints are completed.

Checkpoint	When it occurs	What is required
Checkpoint 1	After the TCU has downloaded and verified the firmware	Operator explicitly approves or rejects the update
Checkpoint 2	After UDS flashing is complete and the ECU has rebooted	OEM logic confirms the ECU application is healthy

Machine Preconditions

Before approving an ECU update at Checkpoint 1, verify:

• the machine is in a safe state for a firmware update
• ECU communication is stable
• power supply conditions are valid
• the operator has explicitly confirmed the update

Checkpoint 1 — Operator Approval

After the TCU has downloaded and verified the firmware image, it signals update availability by setting update_available to 0x01.

The machine-side client must:

1. Detect that an update is available by reading update_available (0x5FF3:0x01).
2. Display the pending update to the operator and request approval.
3. Put the machine into a safe state before proceeding.
4. Write the operator's decision to apply_update (0x5FF3:0x40):
5. 0x01 — operator approved, trigger the update
6. 0x02 — operator rejected, cancel the update

Warning

Before writing 0x01 to apply_update, ensure the target ECU is ready to accept a programming session. If the ECU is busy or in an incompatible operating state, the TCU will be unable to start flashing and will set update_status to a failure code. What "ready" means in practice depends on the ECU — consult the ECU manufacturer's documentation for the required preconditions.

After the TCU accepts the approval, it sends the configured bootloader CAN frame (if any), waits the configured delay, then initiates the firmware programming sequence.

Flashing Status Monitoring

After Checkpoint 1, poll update_status (0x5FF3:0x50) periodically to track progress and detect the transition to Checkpoint 2.

update_status	Meaning	Recommended HMI action
0x01	Flashing in progress	Show progress indicator; continue polling
0x10	Flashing complete — ECU health check required	Proceed to Checkpoint 2
0x40	Update successful	Display success to operator
0x50	Flashing failed	Display failure; advise checking the TCU log in the DataPortal
0x51	Health verification failed	Display failure; OEM logic reported the ECU is not healthy
0x52	Verification timed out	Display failure; health check was not submitted within the timeout period
0x60	Update cancelled	Display cancellation state

Checkpoint 2 — Application Health Verification

After flashing completes (update_status = 0x10), the ECU reboots and starts the new application. OEM logic must verify that the new ECU firmware is functioning correctly before the update can be finalized.

OEM logic must verify that:

• the ECU application started correctly
• the ECU is operational and responding as expected
• no critical faults are present

Once the verification is complete, write the result to ecu_health_check (0x5FF3:0x60):

• 0x01 — ECU is healthy, update successful
• 0x02 — ECU is not healthy, update failed

Warning

If your integration writes a diagnostic log to oem_update_log (0x5FF3:0x61), it must be fully written before writing to ecu_health_check. Once ecu_health_check is set, the verification window closes and the log can no longer be submitted.

If no result is written within the configured timeout (default: 10 minutes), the TCU automatically marks the update as failed with status 0x52. The timeout is configurable via ecu_health_check_timeout (0x5FF3:0x62).

The update is marked as completed in DataPlatform only after ecu_health_check is written.

Recommended HMI Behavior

At minimum, the HMI should:

• indicate when an ECU update is available and prompt the operator for approval or rejection
• show that flashing is in progress (a progress bar using update_progress at 0x5FF3:0x51 is optional but recommended)
• show the final outcome: success, failure with reason, or cancellation

Troubleshooting

Problem	Possible Cause
Update not visible on HMI	ECU FOTA disabled, or no pending update request in DataPortal
Approval has no effect	Wrong CANopen object address used — verify against CANopen specification
Flashing does not start after approval	ECU was not in a state to accept the programming session — check ECU preconditions
update_status remains 0x10	OEM logic has not written a result to ecu_health_check
Verification timeout (0x52)	ecu_health_check was not written within the configured timeout window
Update cancelled unexpectedly	Operator rejected the update, or it was cancelled remotely via DataPortal