355 Hacking the F1 TCU

In the automotive industry the development of an ECU of this complexity takes around 5 years. Usually two departments are involved, the hardware department and the software department. A typical software department consists of around 100 employees (architects, function developers, implementers, calibration engineers, testers, ...) while a hardware department is maybe half the size. Now let's do the math: 5 years * 150 engineers = 750 man years of development. If you are able to outsource half of that work to best cost countries, the average costs for an engineer are around 70k. That results in total costs of around 50M!

But that's only the labour! You'll need office space. You'll need equipment, tools, test benches. You'll need prototypes. And so on. That will easily double your costs!

Maybe you intervene now and tell that a "start-up solution" is enough. Plus part of the software is already there and only needs adaptation. But how much will that cut the costs? To half of that? A quarter? Even at 10% - which I'd consider as unrealistic - we're talking about 10M! And we still left out the risks. Will you find smart specialists that have experience in this area? Will they harmonize as a team?

Maybe you throw in that there is stuff like Megasquirt which could be used. And that's absolutely valid. Those boxes are even used in Motorsports and do a good job. But my customer is not asking for that. He is having a vintage Ferrari in his garage and seeks for a decent solution.

I truly appreciate your question. However a complete re-design of the ECU was definitely out of scope.

 

Part 9 of Hacking the F1 TCU

Intel, the well-known chip manufacturer, was known for a long time for its so-called Tick-Tock model. Instead of developing a completely new CPU each time, they devided the job into two halves and alternately did only one of it: either renew the CPU architecture (Tock) or perform a die shrink (Tick). That is when they released a new CPU, it was actually only half new (and half similar to its predecessor). This strategy saved them a lot of effort and costs. Interestingly Ferrari does something very similar with their V8 models: a new development of the bodywork is followed by a new development of the drivetrain. Therefore the shape of the F355 is similar to the F348, while its drivetrain is rather close to that of the F360.

Image Unavailable, Please Login


It suggested itself to compare the drivetrain of the two! I wanted to see which improvements Ferrari made to the F1 in the F360. I already knew that shift times are also rather slow there. However, during my search I found out that there is a special situation with the Challenge Stradale. I read that at least for that model shift times are considerably better!

I was curious about what the difference would be. I continued my search and stumbled across this thread. Unfortunately it doesn't mention any internal details on the difference. However it makes a clear statement: the CS TCU can be retrofitted into a Modena! Better still, it's only a matter of flashing the CS software!

This gave me further confidence that I was on the right track with my approach. If it's only a matter of software to achieve faster shift times in the F360, then this would definitely apply for the older F355, too! I had to find out what was improved there and then port this into the F355 Software! Or better: I would port the entire software of the F360 CS TCU into the F355 TCU! Mmh, would this be possible? I planned to buy an F360 TCU to have a closer look.


There is only a single TCU variant in the F355. It is called CFC-101. However for the F360 several variants were made. If I got it correctly, then the oldest is from the Modena and dates back to 2001. It is the CFC201F.01. Then later there was an update to the CFC201F.05. Finally the most modern variant is that of the CS, which is called CFC231. This was the one I was looking for!

Unfortunately, these units are rare and so I couldn't find an offer. But finally I found a CFC201F.05 which is said to be compatible with the CS. I bought it immediately and it arrived a few days later. I opened the case and checked the hardware.

It was not much of a surprise that the hardware is different:
Image Unavailable, Please Login


Unfortunately after a more thorough check I found that the differences are substantial! Though I recognized a similar structure, I noticed that innumerable details have been changed. Well, at least the processor is the same. These are the major differences:

Image Unavailable, Please Login


Next, I analyzed the software. I retrofitted the debug interface and dumped the code. I looked at it and discovered many functions which are completely identical. Then again I found some that differ only by minor things. But in the end I noticed that the majority of functions changed completely or are even new.

What a pity! Anyways, I wanted to try out whether the F360 software can run on the F355 TCU! Simply copying it wouldn't work now, of course. But I would do an adaption then. I went to work. Looking back the most difficult thing was to redesign the pin assignment of the processor. But also many other small details took so much time.

After all I think I've come quite far. I was able to basically make the software run on my F355 TCU! Gear indicator, switch, buzzer, relay, etc. - all that stuff was working! I was even able to shift gears using the diagnostic interface! However, the TCU refused to release the engine start inhibit. I tried a lot, but always got stuck in things where I did not (yet) understand the software well enough.

I decided to put this approach on hold. Maybe I would come back to it later. But this episode taught me two things: the F360 TCU bases on the F355 TCU. And that the key to faster shift times is in the software!

 

You're right, Ian. There was no evidence that the software would be the bottle neck. But there also was none that it would be anything else.

Moreover I had some indications pointing at the software. According to Ferraris development style described above, the hardware should be (mainly) the same between F355 and F360. Plus the shift times for F360 were slow in the beginning but were improved in the CS only by changing the software. Plus the TCU internally uses a slow cycle time for processing (as mentioned before). Plus I had a talk to an hydraulics engineer who explained me that it's likely not about low pressure level or slow solenoids (as mentioned before, too).

Still no evidence, yes. But enough for me to give it a try.

I think the missing part was coming from the engine ECU. There is a lot more stuff going on on the CAN bus in the F360.

 

Yes. You can easily add another note to send new messages. It is also possible to manipulate existing messages (which would be necessary here) by using a gateway.

But that's not the difficulty. Instead it is:
- The F360 shares information on the CAN bus, which simply is not available in the F355. Remember that the F360 has E-Gas and so on.
- The meaning of the messages is unknown. Demanded torque, current torque, wheel speeds, engine speed, engine temperature, various states (brake pedal, switches, ignition key and so on)... I suppose all that is available on the CAN and considered by the TCU. But you don't know in which message and in which data byte it is encoded.

I tried to reverse engineer that from the code. E.g. I found out that ID 0x1F0 contains the wheel speeds. But I didn't come far. You would need at least a CAN trace of a known driving scenario (hard acceleration, cruising, ...) with a known vehicle state (driving mode, brake pedal status, ...) to get any further.

 

Part 10 of Hacking the F1 TCU

By the way, while I was searching for information on the F360 TCU I suddenly came across a chinese patent. It dates from January 2008 and describes many solutions available in the F360 TCU. Most of them match down to the last detail of it! E.g. the electronic devices listed there are the very same, schematics are identical and so on! The author of the patent is a chinese company. Maybe it is related to the Chery QQ, which was already discovered here in FChat? If you like, search for patent CN101230913.

Of course automated manual transmissions (AMT) are not invented by Ferrari or Fiat on the other hand. They exist for a long time. However it was Magneti Matelli who launched the market in the mid to late 90s and made them popular for passenger cars. The idea is simple: Take a conventional manual transmission and replace all manual actuations with a hydraulic. That's it. The target was to close the gap between automatic transmissions with torque converter (comfortable, but heavy, expensive and inefficient) on the one side and manual transmissions (lightweight, inexpensive and sportive, but uncomfortable) on the other.

Magneti Marelli called its system Selespeed. Alfa Romeo also exactly used this name for their cars. Other car makers called it Cambiocorsa, E-Gear, SMG II, Duoselect or, well, F1. But whatever they called it, the basis always was the Selespeed system from Magneti Marelli.

Image Unavailable, Please Login

The Selespeed always works the same and usually is just an add-on to an already existing manual transmission: A gear actuator replaces the gearshift lever and will select and engage gears. A clutch actuator replaces the clutch cylinders and will control the clutch position.

Image Unavailable, Please Login

Above picture represents the gear actuator of the 355F1. Five solenoids exist, EV1 to EV5. They modulate a hydraulic pressure which is translated by the gear actuator into movement of the control arm in the desired direction. For example, a shift from gear 4 to 5 first turns on EV1/2 until gear 4 disengages. Then it activates EV4 until the control arm has reached the shift track for gear 5. Next it activates EV1 until gear 5 engages. Similar to a manual transmission an engaged gear is self-locking, so finally all EVs are deactivated. (Not shown is the EV0, which operates the clutch - this should be self-explanatory.)


Unfortunately most advantages of the AMT (lightweight, efficient) turned out to be irrelevant for most driving situations. Moreover most drivers didn't make any difference between AMT and normal automatic transmission. Due to both they perceived the AMT just as a slow and rather uncomfortable, but normal automatic transmission. A few years later the dual clutch transmissions entered the market and replaced the mentioned type (i.e. add-on type) of AMTs.

 

Part 11 of Hacking the F1 TCU

Spending much time with the program code I became more and more familiar with it. I made good progress and finally reached a point where I had all basic parts together. I knew how the shift request is generated, the gear positions are detected, the solenoids for clutch and control arm are driven and so on. However I could not bring it all together. I missed the big picture. I knew there must be a master algorithm that controls shifting procedure - but I couldn't locate it.

I got stuck. Once again I needed a new impulse, a new look at the things! I decided to put theory aside and try it with trial and error. To some this might sound unprofessional, but I think it's not. Many things were discovered by accident (Penicillin, X-Rays, Super Glue, Viagra... you name it).

Now I would have loved to simply jump into my 355F1 and trace the software while trying some stuff. Unfortunately there was none in my garage and the only 355F1 I knew of was that of my client. But I neither could nor wanted to ask him. So testing in an 355F1 was not possible. But maybe this was also not necessary. Maybe it would be sufficient if I built a component test bench and run my tests there! This way I would not need a whole car, but only an AMT. That is Power Unit, Control Arm, Clutch Actuator and some miscellaneous parts. With all that I could see how the unit works during operation as well!

Searching for the parts, I soon noticed that they are poorly available and incredibly expensive. For example, the Power Unit is no longer available at Ferrari. In a way that's a good thing, because they ask incredible €20,000 for it! Even a used one is still half of that though.

Last time I explained that all Selespeed AMT are very similar. So I extended my search and included the F360. And finally AMTs of other car manufacturers as well. After a while I came across a fascinating unit that Alfa Romeo used in their 156. It integrates all items in a single block! That means the Power Unit and all Actuators are in the same housing including the respective hydraulic lines. Only the hydraulic pump and the reservoir are kept seperately (likely to improve NVH characteristics). Due to that the block is very compact. That was the perfect choice for my needs!

I bought such a unit and mounted it on a frame. This is how it looks like:
Image Unavailable, Please Login

Next I modified the wiring harness so I could connect it to the TCU and my HiL. Then I powered everything up. From the beginning it worked... not at all! I can't remember what exactly was wrong. But I remember that I found a lot of "bugs" in my HiL and in my Reverse Engineering! So my test bench was already helping me before it even worked.

I put everything straight and tried it out again. Below is a video of one of my first functional tests, where I cycle through the gears: N -> 1 -> 2 -> N.



In order to carry out a shift, the TCU needs plausible values. This is especially true for the various speed values. If the speeds of gearbox input, clutch and gearbox output don't match, the TCU does nothing except set a DTC. To get them plausible, I had to write a simulation that copies the vehicle behavior as realistically as possible. I must admit that I first tried it myself. But soon I gave up. It's complex to design a system with three inertia (engine, gearbox, vehicle) that are connected by two independant clutches (regular clutch, synchronizer discs) and varying gear ratios. Fortunately, one of my employees graduated in physics. He wrote the simulation model for me. I think it's pretty good (though not perfect).

Now I can watch how the TCU actuates the clutch and shifts the gears in reality. The following video shows, how I power everything up, turn on ignition and virtually start the engine. If you pay attention to the clutch actuator (on the right), you can see how it seeks PIS. Then I request first gear and the control arm turns into position for odd gears. Next I accelerate until engine RPM hits the limiter. After a short time an automatic upshift into second gear occurs. (Which, frankly, surprises me, because in manual mode a sports car should hold the gear.)




After all this component test bench was a great decision. With it I left my deadlock behind me and I was able to try out many new things. Besides, it's fun to play with. Now all I'm missing is a real 355F1 ;-)

 

Back then I was still at a stage where I tried to figure out how the Software works. With the test bench I finally was able to see what it does in reality.

Take the gear engagement for example. Don't think of it as simply driving the right solenoid until the gear is engaged. Instead it's way more complicated. There is a basic current applied first. Next there is an offset. This offset is gradually increased over time (and depending on travel). Then there is a hold time. And if the gear did still not engage, then finally an overdrive current is let out. But that's not all. The entire process is synchronized with the gear selection and starts a bit in advance to preload the mechanic. And of course there also is the clutch control running in parallel. That's what makes it complex.

You cannot simulate this "orchestra" on a HiL and you will not figure out how it works by sitting at your desk. It's too complex. That's why I built the test bench.

Again, back then I was not yet aiming on any improvements. Although this was (and still is) my target, the first step was to understand how everything works. Yes, all this is very time consuming with little progress in the beginning. But if improving shift times is possible, then this is the approach that will definitely work and will bring the best results!

 

Whenever you request a new gear, your TCU estimates the new clutch speed after engagement. If it exceeds the maximum speed allowed, your shift request is rejected.

There are two tables holding the maximum speed allowed, one for "low grip" active and one for inactive. "Low grip" active is very conservative, as you might guess. For "low grip" inactive the maximum speed allowed is (nearly) redline for all target gears though. That is you can always perform a downshift as long as this won't over-rev your engine.

But as you have noticed, the one and only exception here is gear 1! For gear 1 the maximum speed is 6000 rpm. So whenever the clutch speed in target gear would exceed 6000 rpm, your downshift is rejected. I assume they did that for driveability matters (comfort, traction etc.).

This restriction can be removed of course. The only trouble is: if I'd build a customized software for you, you still won't be able to flash it to your TCU.

Maybe there will be a programing adapter some day... let's see!

Wolfgang