Checksum workflow: submitting a file, the original request and families we cannot compute

Checksum correction means recomputing the verification fields a unit needs in order to accept a file after it has been modified. At RemapCloud this runs in a tab of its own, separate from the delivery flow. This article describes the flow as it stands today, and its known limits.

Why it is a separate step

Checksum is never chained into delivery on its own. That is a deliberate decision: you decide for which file and at which moment you want the correction. A file you receive downloads without a checksum step as well, and the reminder stays on the screen.

The steps

You submit the file from the Checksum tab.

The engine tries to recognise the unit from the file.

If it does, it recomputes the verification fields and returns the corrected file.

In some families the computation needs a comparison with the original, that is the unmodified file. In that case the job goes into a state that waits for the original and you are asked to upload it.

Once you upload the original, the job returns to the queue and is computed from the difference between the two files.

If the unit is not recognised

If the engine cannot recognise the unit from the file, the job closes as failed and no credit is charged. This is a gate placed there so that coverage is not made to look wider than it is: writing guessed verification fields into an unknown family can leave the file unusable.

Four defects closed in the original-request flow

The flow was measured end to end and four broken steps were closed.

The same original was asked for again and again even when it was already attached. A job with an attached original no longer falls back into that state.

The upload area for the original existed only in the progress box shown at submit time; a customer who refreshed the page or came back later could not continue. The job can now be continued from the job list afterwards.

A waiting job waited forever; a timeout and a cancel were added.

A late or duplicated result could turn a finished job back into the waiting state; a status check was added.

Alongside those, you now receive a notification when the original is requested, and uploading the original is written to the audit trail. All of the texts on the screen exist in four languages.

The engine tests itself

Before it starts taking jobs, the engine tests itself against a sample file whose result is known in advance. If that test does not pass, no job is taken: it stops rather than quietly producing a wrong result.

Families we cannot compute

Some families that use modern signed verification, for example certain MED17, EDC17 and MG1 derivatives, are not computed on our side. Those families are detected and shown to you as a warning; the warning exists in four languages and is actionable, meaning it tells you what to do next. Such files need an external tool. We do not present coverage we do not have.

One source for the family table

Which verification method a family uses is kept in a single table; the screen, the engine and the reports all read from that table. The same family is never written differently in two places.

Where to look

The presentation of the software is on the chiptuning software page, the supported units are in the ECU list, and the service itself is on the chiptuning file service page.