[apalrd]

Ideas on parameters:

I work a lot with automotive controllers, and the way we calibrate (and integrate with Simulink, in many cases) is rather simple:
-I can use a Simulink constant block, but type a workspace variable instead of a number. I can then define the variable and type in a 'data dictionary' which defines the calibratable parameters and their default values. We usually allow normal single-value types (although not always float types depending on the processor). We can also define 2d and 3d interpolation lookup tables, with the x, y, z indexes and data.
-I can also define 'measurement points' in the DD, and they correspond to Points in Simulink (wires get a blue thingy to indicate they are measurement points)
-When I do a SW build, it compiles the list of variables and their locations in memory (we don't dynamically allocate memory) into an 'A2L' file, with the code and default calibration in a Hex or S-record file. The A2l also includes the scaling from memory to engineering units, describes what units they are, limits, and used memory regions.
-I have a 'calibration tool' which is capable of communicating with the ECU in question. This is usually over CAN, since we already have a CAN bus to use, but it dosen't have to be. It's usually a SW program on my laptop, although I also have a physical box which can read data.
-In the cal tool, I can define screens, where I create indicators to read measurement points and controls to set calibrations. Nicer programs can draw 2d/3d interpolation tables as curves and surfaces, lesser ones just show the tables as a grid of data.
-If I am working with a development ECU, the ECU will copy the entire calibration block to RAM on boot, and I can switch between the Flash and RAM calibration pages easily ("Reference" and "Working" pages). I can only modify calibration in RAM. When I am done, some ECU's can write the Flash from RAM, others I have to flash using the normal flash process. For production ECU's, I can't change anything without flashing, that's a RAM size limitation.
-I can save copies of the calibration on my computer, in Hex or Srec formats. Along with the appropriate A2l, I can read any cal as labels in engineering units, some programs provide nice dataset management, and can merge cals by label.

The problems with this exact system:
-You must use the right A2l for the software build, or the RAM addresses are wrong. We don't build often, but we still have to manually deal with this issue. Since you have an SD card, you could keep the SW build files needed to read RAM on the card, and read them when you connect to the ECU.
-You can't dynamically allocate memory with this method, unless you use something other than RAM address to identify the cals. Using a 32-bit address is more efficient than a name, and can be used directly by separate program segments, so we use this method.
-You could use Ethernet as the transport layer, all fine there.
-I can provide some more details if necessary.