With race series such as 24 hrs of Lemons, Champcar, and World Racing League, there are lots of opportunities to participate in the sport of endurance car racing at an "entry level" cost. However, this so called crap-can racing can be quite the resource management problem with lots of data to be parsed in real time for the driver and the team.

I built and raced an in-expensive endurance race car 15 years ago. I loved being in the car and dicing with other drivers. But, I also enjoyed the challenge of running a race team all weekend. This included the task of monitoring the race car in real time so we could anticipate problems and address them before they ended our race weekend.

In endurance racing, the task of monitoring the race car is complicated by the fact that the driver has other important things to do. Also, there is more than one driver in a race weekend. So, the perception of the data presented can change. I learned this at about 9 pm one long race weekend. I had just stepped out of the car, put a new driver in, and sent him out. Per our process at the time, someone in the paddock had a stop watch and a radio with direct communication with the driver. Our process was for the "crew chief" to clock lap times and report them to the driver. The driver would respond with the values they read from the gauges (oil pressure, oil temp, water temp, fuel pressure, and voltage). In our first car, we had cheap analog gauges. So, when the driver reported the water temp on his first lap, we got a reading of 225-230 degrees. This was a little concerning because I had been reporting 210 degrees for the previous 90 minutes. We instructed the driver to continue but watch the water temp. This continued for several more laps and we decided to bring the car in to check if there was debris stuck in the radiator. Upon inspecting the cat, there was nothing out of the usual. So, I poked my head in the car to check the temp gauge and to my surprise it was reporting exactly the same temp I had seen for the previous stint. It turned out that the new driver was shorter and often reading the value while in the first turn. From his angle the gauge read 225 degrees.

This is a picture of a later race car I built, Note, the gauges are rotated and appear to be askew. This was intentional. It's an old trick to simplify reading the gauges. If everything is operating in a reasonable range, all the needles should be pointing straight up. In fact, my drivers got in the habit of reporting "needles up". This meant that everything was operating in expected ranges. It wasn't terribly precise, but it worked. Keep in mind that in the time I owned and raced that car, I had at least dozen different people drive that car. Most of them had no idea what the appropriate range was for all the parameters. And, they didn't have extra brain cells to commit to the problem while they were dicing with other cars on the track.

I eventually installed digital gauges to minimize the perception problem. But, they seemed to confuse my drivers even more in the long run. So we just simplified and asked the drivers to read off the oil pressure and temperature only. This worked for the most part. But, it would have been nice to have more data.

That's where this project comes in. It's goal is to simplify the task of monitoring the operating parameters for the driver, significantly increase the resolution of the monitoring, add additional parameters to be monitored, add data logging, nullify the need for a vigilant crew chief manning a stop watch, reduce the chance of human error, and keep me busy evenings and weekends for the next 6-12 months.

Concept

As previously mentioned, I have a background in embedded systems and process control systems. Looking back at how my team managed the problem of driver feedback and system operation parameters, it highlights many problems process control systems deal with. These systems that control large chemical and petrochemical plants monitor a significant number of sensors. Too many for the operators to track and filter the high priority information at any given time. So, systems are designed with low low, low, high, and high high alarms. You can think of these as warning and critical operating levels. The system also implements an alarm manager that presents informative, warning, and critical alerts that are displayed on a dedicated alarm manager screen. This manager filters the alerts and presents them in a predetermined priority order. The operators must acknowledge most of the messages to document when the issue was brought to the operator's attention.

Another goal of process control systems is to filter the incoming data and only present the data that is important in that moment. The alarm manager is part of that strategy. But there are other design details that help achieve that goal. For instance, the monitoring screens in the control room only display sensor information that is applicable to the current process. In addition, the screens use color and possibly sound to highlight important information.

These concepts will be integrated into the race computer. For instance, it will have a simple 12 character single line alphanumeric display with a status indicator LED (red, yellow, or green) and a color coded bar graph indicating engine RPM. The small alphanumeric display will be too small to present all of the tracked data at one time. Doing so would certainly overwhelm the driver. So, the display will be context aware and only display what is relevant in the current context. In addition, user input will be kept very simple as well. The driver will select what is to be displayed or acknowledge alarms using the steering wheel mounted cruise control switch. It has three different inputs, up, down, and pulled back towards the driver. This is easy to operate while steering a vehicle. The driver won't even have to take there hand off the wheel.

High Level Requirements

Real-Time Monitoring

In standard operation, the driver will be able to select a specific operating parameter(s) to monitor on the screen in real time. The options will be:

  1. Oil pressure and temperature
  2. Oil pressure
  3. Oil temperature
  4. Coolant temperature
  5. Fuel Pressure
  6. Fuel Tank Level
  7. Battery/Alternator voltage
  8. Battery charge level (only when the motor is not turning)
  9. Engine RPMs
  10. Vehicle Speed
  11. Acceleration in the x and y axis
  12. Resetable odometer
  13. Lap counter
  14. Time of day

In this mode, the status LED will be off.

Alarm Manager

When an operating parameter goes out of safe range or a predetermined event occurs, an info, warning, or critical alert will be displayed on the screen. If it's an info event, the status led will be green. If it's a warning, the status led will be yellow. If it's a critical alert, the status led will be red.

Once an alert is on the display, the driver will have to acknowledge it by pulling back on the steering wheel stalk (previously the cruise control stalk cancel function). There will be an option to timeout alerts by level. Once an alert has been acknowledged or timed out, the computer will return to the prior real-time parameter tracking and the status led will turn off.

If another alert comes in while an unacknowledged alert is still being displayed, the response will be dependent on the priority of the alerts. If the current alert is higher priority than the new alert (priorities being critical, warning, and info in that order highest to lowest), then nothing will change on the screen. But when the driver acknowledges the current alert, the new alert will be displayed and must be acknowledged. There can be a queue of active alerts awaiting acknowledgement. If the new alert is the same or higher priority, it will replace the current alert on the screen and it will have to be acknowledged before the prior alert can be acknowledged. It's possible that a new alert will automatically acknowledge the prior alert. For instance, if an oil pressure warning pops up and is unacknowledged, when an oil pressure critical alert pops up it will replace and automatically acknowledge the original warning.

If more than one alert at the current displayed alerts priority is unacknowledged, the status light will blink in the color associated with that priority.

Alerts will have hysteresis and time delays to prevent a flurry of alarms generated by an operating parameter that is marginal. 

Examples of info events:

1. Report time in the car every 15 minutes. This can be automatically determined using the driver door ajar switch and vehicle speed sensor to figure out the exact time of the last driver change. This can also be used to report the time spent in the hot pits of paddock

2. Previous lap time. This will be displayed whenever the computer detects the start/finish line has been crossed

Logging

The system will update all the tracked parameters approximately 10 times a second. If logging is enabled, each new update cause the previous values will be logged. It will be possible to set the frequency data is logged.

Logs will be organized by the driver stint. When a new driver stint is detected, a new log will be created.

Real-Time Reporting to the paddock

When the start finish line is detected, the system will wirelessly transmit a summary of the prior lap data. This will include current, average, minimum, and maximum values for the tracked engine parameters. It will also include all of the new alerts (acknowledged or unacknowledged, displayed to the driver or not). This will be a one way transmission with no acknowledge. It is considered a best effort transmission.

Unacknowledged alerts will be provided each lap. Even if that unacknowledged alert was reported on the prior lap. Acknowledged alerts will be reported only on the lap they were acknowledged. Doing so will enable the team to determine which alerts have been acknowledged by the driver.

The paddock will be equipped with a workstation that will receive these updates and display them in an organized fashion. This workstation is solely intended to monitor the summary of the previous lap and unacknowledged alarms. It will not log data. Logging is local to the in car system.

Since the start finish line is usually closest to the hot pit and paddock with reasonable line of sight, this wireless connection can use an unlicensed frequency band at the restricted power levels. It will likely be implemented with LORA and high gain antennas.