Design Observations
ECU Design: General Observations
Hardware
By decoding the schematics and compiling the set of inputs, it appears that the Aprilia/Rotax ECU is based on a generic design, and has been adapted for use on the Aprilia twin. Evidence leading to this conclusion include things like:
It is capable of driving up to four spark plugs (albeit two at a time) for use in a two or four cylinder engine.
The circuit wiring is capable of driving four fuel injectors. The parts required to drive the remaining two injectors are not present. In industry parlance, the missing parts are described as having not been "stuffed".
There are two MAP select wires, meaning that the ECU is capable of supporting up to four maps. Even so, the 549US software that ships with the 2003 models ignores the second MAP select wire in a slightly inconsistent fashion. It would take a bit of programming effort to properly activate a four-map setup properly.
It appears that the ECU wiring supports an oxygen sensor as an ECU input, although the related circuitry is not stuffed.
It appears that the ECU supports a heated oxygen sensor. The ECU circuit board has an output driver labeled 'HEAT".
The Aprilia implementation probably does not use an oxygen sensor for cost reasons. It might be an interesting project to see if the ECU software could be rewritten to use an oxygen sensor and convert the fuel injection system from open-loop to closed-loop. The benefits would be improved fuel mileage, and the ability to compensate for fuel pump pressure differences, among other things. Conceptually, it should be possible, but it would be a ton of work.
Software
Viewed as a whole, the software has a few interesting characteristics. For one thing, it would seem that the software was originally written for a different processor. The proof of this is that even though the 68HC11 has both X and Y index registers, the ECU software never uses the Y register. From a programmer's standpoint, this is basically unthinkable: embedded processors have so few resources inside them that to not use something as valuable as an extra index register is just plain ludicrous. That leads me to believe that the software was originally written for an older Motorola microprocessor that did not support a Y register. Over time, the software was ported to the newer 68HC11G. As anyone who has experience writing complicated firmware knows, you just don't arbitrarily mess with something that is known to work.
There are other indications that the programmers who wrote the firmware were reluctant to make changes, too. All throughout the code, you can find little snippets of debug code. For example, a lot of variables are calculated and stored into RAM, but then never referenced. I would bet that these variables were being stored so that if the ECU crashed during development, the developers could scrounge through memory and see what the box was up to when it croaked. What is interesting is that this code still exists in the production version. As mentioned before, when things work, programmers become very reluctant to make changes, even if the changes seem harmless. I think that every programmer in history has been burned more than once by making what seemed to be a "harmless" change to their code. For example, a common side effect of removing otherwise harmless code is to change the timing of the rest of the code. In the worst case, the difference in timing could cause the program logic to fail. One could argue that the original code had a latent bug waiting to be exposed by the timing change, which would be correct. In practical terms, if the timing delay due to the harmless debug code prevented the latent bug from occurring, then in some peculiar sense, the version including the harmless code has no bug. Therefore, by not changing things, you avoid introducing bugs that you are not aware of. In practical terms, "if it ain't broke, don't mess with it".
This point is driven home by the method that was used to disable the dual-map "derestriction" wire-cutting trick in the 549US software. The software could have been modified in about a dozen places to ignore the derestriction input wire entirely. Instead, the software does exactly the same as it always did: it dutifully checks the wire hundreds of times per second and decides if you are using the restricted or the derestricted map. The only difference is that in the "un-derestrictable" versions of software, each pair of maps contains identical data. Regardless of the wire-cut, it doesn't matter which map the processor reads from, since it is going to get the same data anyway. Since the program logic was not changed in any way, there was no possibility that an otherwise harmless-looking change could possibly introduce any new bugs. This was probably viewed as a much safer solution when the byproduct of a software bug might involve blowing up a customer's engine.