Objectives

Below is a list of the objectives set out for this project.

Project Objectives	Importance
Literature review into automotive network architectures and protocols.	Major
Develop a network to allow all data acquisition components on the car to communicate and share data.	Major
Develop nodes to interface sensors on the car with the on-board network.	Minor
Literature review into on-board to off-board wireless communication technologies.	Major
Design, implement and test a wireless channel for communication.	Major
Development of nodes to interface on-board network and off-board systems.	Major
Development of on-board data logger.	Optional
Literature review into existing analysis systems.	Major
Development of software and/or integration of 3rd party software package(s).	Major
Development of nodes to interface on-board network and off-board systems.	Minor
Development of on-board data logger.	Optional
Literature review into current video solutions.	Major
Integration of video into off-board software system, to view alongside the acquired data.	Major
Implementation of wireless transmission of video stream(s).	Optional
Package the solution as a marketable product for potential customers.	Optional

Technical Risks

Below is a table that lists all the technical risks associated with the project proposal. Risk in this context is taken to mean any event or action (or inaction) that would jeopardise any project outcomes or significantly impede project progress. Along with the risk, actions have been provided that would be taken to mitigate the effects of the risk.

	Possible Risk:	Mitigating Action:
1	Component of project not delivered by group member.	Regular meetings to check progress. Management of deadlines.
2	Extended learning curve with on-board network.	Simplify the network.
3	Loss/damage of borrowed equipment from USM (car, ECU, sensors etc.).	Simulate data outputs.
4	Car unavailable to test system components.	Simulate testing environment e.g. using a road car.
5	Wireless communication not feasible.	Use on-car storage to transfer data to off-board systems
6	Wireless range not high enough to cover track.	Multiple base stations/burst transmission every lap.
7	Customer requirements change during the course of the project.	Formal specification agreed upon at start of project. All changes discussed with customer and approved before implementation.
8	Loss of software code.	SVN repositories used and adhered to throughout project.
9	Loss of documentation (reports etc.).	Make sure everything is saved to cloud storage.
10	Damage/loss to equipment (soldering etc.).	Where possible, multiple components to be bought within same order. Alternative equipment to be identified.
11	Budget constraints.	Research alternative components or discuss other sources of funding (i.e. USM).
12	Lead times.	Project management to take into account deadlines for orders, alternative suppliers to be used if required.
13	PCB complexity too high to be manufactured in house.	Outsource manufacture, taking into account extended lead times.
14	Lab space becomes inaccessible due to fire/flood etc.	Re-evaluate project objectives in discussions with mentor and customer. Video/photos/logbooks to be taken throughout to show progress.
15	Off-board software implementation too complex to develop within timescales.	Simplify software objectives.
16	Complexity of project under or over estimated.	Revise objectives.

Project Description

Formula Student is an international design competition challenging students at university to design, build and manufacture a single seat race-car. The University of Strathclyde Motorsport (USM) team competes against other universities from across the world every summer at Silverstone and Hockenheim. It is important that design decisions throughout the process are justified and data driven. Therefore there is a need for data acquisition while running the car to allow simulated values to be compared with real-life values to validate designs.  The high performance nature of a racing car often means that components are operating at the limits of their design, requiring values to be monitored in real time while the car is running to keep them within safe limits.

The current team uses a DTA S80 Pro Engine Control Unit (ECU) to sense and control engine parameters such as oil and water temperature, a Race Technology DL1 Data Acquisition Unit (DAQ) to log analysis parameters such as suspension travel, steering angle and brake temperatures, and a smartphone to display some of these parameters.  The ECU outputs various data parameters onto a Controller Area Network (CAN) bus, which the smartphone is connected to via a Bluetooth device.  A CAN adapter has been purchased for the DAQ but it has not been possible to make it function correctly.  This has meant that all data on the CAN bus is not available to the DAQ to log.  Some CAN data logging functionality is available on the smartphone however this is limited and not easy to access.  Data is logged internally on the ECU, but again requires specialist software to access.

Concerns have been raised within the team that there are three different places that data is logged on the car, all with differing software packages to access and analyse the information.  This makes it difficult to compare values that have been recorded in different places, for example GPS information and oil temperature (DAQ/smartphone and ECU).  Team members are also unable to invest the time required to learn the different software packages.

Traditionally critical values (such as oil/water temperature etc.) have been displayed on the dashboard alongside RPM lights and current gear to allow the driver to monitor and act on while the car is running.  However most Formula Student tracks are very tight and test the driver’s skill and concentration.  Consequently the driver does not have time to accurately assess these values and drive to the best of their ability.  If the critical values could be monitored off the car in real time by other members of the team at the pits/side of the track, the driver could be warned and take action, without them having to constantly be checking the warning lights.

We propose to integrate all the data logging functionality on the car into one system, where all data is available everywhere. For example it would be possible to display accelerometer data on the dash or log RPM and gear position against GPS data, something that is not possible with the current system.  This would be done by developing an onboard embedded network that all devices on the car communicate through.  Sensor ‘nodes’ will be developed to directly convert analogue voltages to the network protocol, therefore also reducing the amount of wiring on the car as currently individual cables are run for every single sensor on the car.  This would also make the data acquisition set up a lot more flexible, allowing sensors to be added and removed as required.

In addition, it is proposed to develop a communication link between the on-board network and an off-board software system, allowing the sensed data to be monitored in real time by the pit crew.  The off-board system would allow team members to analyse the gathered data in a manner that is easy to use by an untrained engineer.

Finally, video systems are to be integrated into the project, enabling team members to see external factors that cause fluctuations in recorded telemetry. An example of this would be a driver taking a slightly different racing line in a corner.  This could also be used to assist in driver training and gain significant improvements in overall lap times.

The system is to be modular in design, allowing for it to be integrated into any other racing car in amateur racing series. The end product should also be lower in cost than other racing data acquisition/telemetry/video analysis systems, making it more affordable and accessible to amateur racers/Formula Student teams.