Telemetry Snooping

[carvetia]

I was wondering what systems the teams use for sending and receiving data from the cars, to what extent this data is obfuscated/encrypted, and whether teams have ever attempted to hack or steal other teams' telemetry as it flies through the air? Is it part of the standard ECU?

I also noticed an article on this site mentioned the use of microwaves. How would this work, surely they are highly directional and require line-of-sight from the car which seems very impractical for such a fast-moving object!

This more recent article points to using just a normal radio, however it also says:

With the satellite link we have a very high bandwidth to be able to send and retrieve data, huge amounts if necessary in a very small amount of time to make sure the communication itself is not the bottle neck

What satellite system is this? As far as i know they all have very low bandwidth and extremely high latency, so i would love to know what provider F1 teams are using!

[Ciro Pabón]

AFAIK, the first provider for Williams was Plextek. They used a special radio system, because GSM, Bluetooth or DECT are not able to keep up with the data rates (or so they say). The article by Plextek seems rather old, I don't know if the technology has changed. They don't mention satellites at all but they studied the spectrum to find some "free channels" in every country where races are held.

Measured signal strength at a circuit (I'm guessing here that the X-axis is frequency)

[Belatti]

I guess F1 telemetry is picking up data from various sensors at arround 500Hz, so the bandwidth must be a thing to have in mind.

With the satellite link we have a very high bandwidth to be able to send and retrieve data, huge amounts if necessary in a very small amount of time to make sure the communication itself is not the bottle neck

What satellite system is this? As far as i know they all have very low bandwidth and extremely high latency

I think your "low bandwidth" benchmark is not quite right. The latency is not a problem, is not that something bad is gonna happen if the pits receive the data 3 or 5 secs after it actually happens in the car.

[White Knight]

Read an article years back regarding encryption of their signals, but it may have been confined to radio communications only, and was before standard ecu implementation. Can't recall, will search for references I suppose. Curious myself now.

[ESPImperium]

The next thing for the SECU to be interffaced with is a standard telemetry system. It was being developed by Honda at the time of the standardised telemetry system being mooted, but Honda pull out and the Brawn takeover had put paid to that as Brawn couldnt spend the $20 million last year to get system bettered.

I think the Standard telemetry system and SECU will be where F1 goes to eventually, but back OT. Telemetry systems are generally developed over time, generally the bigger teams have specialist systems. Theese take years of investment and time, something that the smaller teams have over the new entries, the time factor, that cannot be bought or sold on a telemetry system.

[WhiteBlue]

At the FiA spec document for the ECU tender you can find a schematic of the data connections of an F1 car.



It shows that the teams have individual telemetry systems that are supplied with sensor and actor information by the ECU. There are also private sensors which are exclusive to the teams. Obviously all the commands have to go through the ECU but info can be gathered privately.

Teams do have their own radio transmission according to this schematic and one has to assume that it is encrypted. I don't believe that satellite links are normally included. The radio will work pretty much like a 3G mobile phone radio system with a main data dump when cars pass the pits. But some teams will also have continuous data traffic to their radio towers which they erect for telemetry.

McLaren are known for a live satellite feed of the telemetry to Woking during race weekends. They have an additional telemetry and strategy crew there to back up decisions in their pit lane command center.

[Ciro Pabón]

In regards to frequency of sampling Belatti mentions, the ECU specification that WB mentios provides the sampling rates and resolutions for many (if not all) gadgets.

So, I said, let´s spend a few minutes reviewing the tender, surely I can check the transfer rates.

The devices that transmit information to the ECU are these, according to the tender document:



The ECU tender document states the sampling rates and precisions for each type of device connector. I tried to estimate the bandwidth, and I got this:



Total bandwith of sensors: 5.7 Mbit/s


I suppose that the figure of 500 Hz Belatti gives is based in some kind of link he has used, so I wonder what's the difference. The most logical explanation is that you don't transmit every bit that runs through the ECU, as the architecture seems to indicate, and, secondly, that there is much more info flowing around the car that the one I naively thought I could check in 10 minutes. Sigh. Here I repost the figure WB just posted:



First, top left, notice that the Steering Wheel and the dashboard use two CAN 2.0 buses. Those buses receive the info from the switches actuated by the driver and feed information to the dashboard display.

A CAN bus is a connector that is specifically designed for vehicles. It's mandatory in US vehicles since the 90's and in European vehicles since 2001.

It allows vehicle microcontrollers and devices to communicate without using a host. You can get 1 Mb/s on those buses under optimum conditions, so the display and switches on the steering wheel would add 2 Mb/s more, on top of the 5.7 Mb/s I estimated for the sensors and actuators, for 8 Mb/s approximately.

FIA Marshalls use another CAN bus to connect to the ECU, so we have 9 Mb/s up to this moment.

The ECU uses two CAN 2.0 buses, as physical interfaces with the "Team Data Acquisition System". So, you have to assume that, of those 9 Mb/s I estimated, only 2 Mb/s are trasmitted to the telemetry unit.

When you're in the pits, the two connectors, at the left, allows you to receive full info at top rates, using a 100 Mb/s BaseTx connection to a computer; more than enough for the 9 Mb/s I estimated.

[Giblet]

I would assume lag is not the biggest problem, but packet loss in general. Lag can be accounted for, but retransmission takes a lot more overhead.

It's hard to know if the stream is a TCP or UDP 'style' of stream. A TCP stream had all kinds of header information, and packet sequencing, where UDP style packets do not. They are usually of less critical data, like an audio stream, that a missed or out of sequence packet might just affect the quality slightly.

I have no idea what kind of encryption, but the teams will use it, as any open data is able to be intercepted by myriad of packet filters and grabbers on the internet.

If the teams were to use minimum 128bit encryption, it will take a long time to get enough packets to be able to even start a forced entry. Plus, without context, telemetry might not mean very much. A team knows what is on channel 1, channel 2, etc, but intercepting a throttle map might get confused with a fuel pressure map, as they will have similar peaks and valleys.

Just 2 cents. Securing data should not be hard for any team, with some of the partners they have. I'm starting an internet security course in a few weeks, and I am quite amazed at the complexity already as I read my text to get a head start. You have to learn the hacks to secure the holes.

[Ciro Pabón]

The ECU communicates with external PCs using TCP.

"Internal" connections with other devices in the car, including the telemetry unit, use CAN as I patiently and fruitlessly explained.

CAN uses 29 bits as identifier (header) of the device receiving the packet, 10 bits also in the header for several functions and 25 bits at the end as CRC check, ACK signals and frame delimiters for a total of 64 bits of "extraneous" data.

Data transmitted per packet is only 8 bits.

So, you have packet control information that is 8 times the amount of "effective" data in the packet. This is common in protocols where there is no host computer redirecting the flow (hence the name controller area network: those connected are no computers but micro-controllers).

CAN standard has not application layer protocols, Giblet, so there is no flow control nor device addressing: it only transports data packets of just one message, there is no flow (you cannot hear music in pure CAN).

Of course, CAN is not encrypted. Any encryption has to be carried on by the telemetry unit before transmitting.

[majicmeow]

Not sure what you mean by a CAN bus, but "typically" in the automotive world (at least in BMW land where I live a CAN bus is a twisted pair (Can LO and Can HI) network between control modules which runs on a 5V (combined) signal. Redundancy built into the systems allows the bus to function on a single wire (2.5v)

AFAIK, there is no "generic" CAN bus connector to "plug into" a bus to read the signals... all modern vehicles I've worked on pull CAN into the 16pin OBDII connector in order to pull data into a reader or tester.

Or am I completely off base here?

-Aaron

[Giblet]

It wasn't fruitless, it was actually very informative. Unless I am misunderstanding, I was speaking of the live broadcast to the pits, after the CAN bus has sent it's data to the telemetry unit.

I thought the original poster was talking about intercepting transmissions of telemetry to the pits. If I understand, the ECU, uses two CAN connections to pump the data to the Team Data Acquisition System where it is combined with the sesnsors of choice the team is running, and that proprietary (or off the shelf?) unit has it's own set of protocols. I assume that the wheel has not been reinvented.

I find this all very interesting, and the flowchart is quite simple and concise really, but considering the trouble I have getting a damn Linksys card to not drop packets from my room to the router 25 feet away, I wonder how that teams do this part of the transfer.

[Giblet]

Not sure what you mean by a CAN bus, but "typically" in the automotive world (at least in BMW land where I live a CAN bus is a twisted pair (Can LO and Can HI) network between control modules which runs on a 5V (combined) signal. Redundancy built into the systems allows the bus to function on a single wire (2.5v)

AFAIK, there is no "generic" CAN bus connector to "plug into" a bus to read the signals... all modern vehicles I've worked on pull CAN into the 16pin OBDII connector in order to pull data into a reader or tester.

Or am I completely off base here?

-Aaron

I think you are just combining the physical medium with the concept of a bus in your head. A twisted pair can exist within a circuit logically, or physically. One 'wire' on a circuit board can do the job of a pair, if there is proper decoding on both ends, much like how a glass fiber connection is physically one 'wire' but acts as many due how each end is processed.

I hope I am not too off base here, in both of these posts. That however is quite possible. I barely have the 7 layer burrito of networking in my head.

[majicmeow]

Giblet,

Yea, I was only trying to determine what "CAN" the previous poster was talking about, even though I suspect he's got his terms mixed up

When it comes down to it, a single wire CAN (not the network) do the job of 2 in a bus system. Considering the speed at which a CAN bus runs at (not really that fast) and considering that an F1 car has potentially (I'd bet many) less sensors to monitor and account for than a modern road-going car, a twisted pair may be over complicating the network.

The 2 wire setup is only really used in road cars to provide a degree of shielding from interference that would otherwise cause problems to the data steam and to provide redundancy should a CAN controller or a wire become faulty.

Regarding encryption, even though CAN signals are not inherently or natively encrypted, there may not be any reason to encrypt said transmissions.
Perhaps I'm a bit rusty on the FIA requirements for software on the SECU, but my guess is that all the teams are running different styles of code on each box anyways. I mean, Toyota probably programmed code in a way that would be different than McLarens version of engine management code.

If thats the case, then although all the data is going to be unencrypted, how's one team supposed to understand another's telemetry without understanding the code? I mean, CAN on an OBD compliant road-car must meet an industry standard for "right to repair". Manufactures all have a base set of instructions and codes that must be able to be read from any scan tool. That doesn't mean the engine management all runs the same style of code, it just means that the interpretation on the user end is the same once it passes through the processors.

In F1, I'm not sure that would be the case. CAN would be handled the same by the controllers based on the standard CAN headers and checks, but the code would be different.

Too much rambling? ok, I'm done... just my thoughts on the matter, I welcome your thoughts (and corrections )

-Aaron

[WhiteBlue]

considering that an F1 car has potentially (I'd bet many) less sensors to monitor and account for than a modern road-going car, a twisted pair may be over complicating the network

An F1 car has more sensors than an average road car. AFAIK we are talking several hundreds. On top you get the digital cameras FOM is stuffing on the cars. There can be up to seven cameras on a car I believe. Sensors which are uncommon in road cars are tyre temp and pressure of all wheels, wheel rpm and angular location, brake temps, pressures, wear indication, physical data of the dampers and so on. Steering angle, six axis acceleration, GPS signals and a pleithora of signals from the engine. I believe they measure pressure in each cylinder, several temps per cylinder. It goes on with the gearbox which is also plastered with sensors to allow computer control. All the ancillary systems are also heavily monitored for physical data, the hydraulic system, the pneumatic, the fuel system and so on.

Road cars have more environmental functions like heating, AC, lights, safeties (air bags), entertainment, windows and seat control, wipers/washing but I believe they still need fewer signals than an F1 car unless you take a fully loaded premium car which nowadays is almost self controlled and so stuffed with electronics that 40% of the value is in electronic systems.

[carvetia]

@Ciro

Thank you for taking all the time to post that, was very interesting, just learned a lot about the ECU in a very short space of time.

Still, I guess details of the car-pit transmission systems themselves are hard to come by. I imagine if the bandwidth of the system was a concern, teams might opt to use a live stream for the most critical data feeds, and a pit pass dump for everything else. I was just wondering whether the teams would bother with the overhead of encryption, knowing that the packets pumped out by their proprietary systems are probably already so indecipherable anyway. If not, an over-enthusiastic amateur with the right radio equipment and skills might be able to spot some patterns

@WB

Thanks for the link. Do you think teams still use a satellite feed? For me it would seem somewhat redundant as surely high speed internet connections must permeate all F1 paddocks by now (ok maybe not Spa ). A pit-base VPN would be ever so easy, most likely faster and definitely cheaper.