https://github.com/bri3d/VW_Flash/blob/master/flashsimos18.py here's a worked example of UDSonCAN -> Flash.
I hope this illustrates my main points:
The basic flashing routine is simple. Diagnostic session -> security access -> erasememory -> request download -> transfer data (repeat) -> exit transfer -> checksum -> reset is shared across almost all ECUs, because there's no reason to add complexity, and why make your dealer tools more expensive to develop? The details of SecurityAccess and the routines used in flashing differ from manufacturer to manufacturer, but for the most part, there's no reason to add extra cost to both the supplier's ECU development process and the manufacturer's tools development process.
Here's the thing though: this is where the commonalities end. The ability to flash arbitrary software on any given ECU is an exercise in reverse engineering much simpler than (most of the time...) but no different to jailbreaking a new mobile phone or games console: the trust chain needs to be compromised at runtime, arbitrary code must be inserted, and then a permanent "untethered" security bypass needs to be installed to allow for custom calibration.
This is the challenge in tuning and goes far beyond flashing, which is honestly the elementary part left to the reader. I think a lot of the reason you don't see more open-source flashing software, not to be elitist to _too_ great a degree, is that by the time you've built a tuning solution for an ECU, flashing is a distant, trivial afterthought.
