Vanderbilt Senior Design Project:

FSAE INSTRUMENTATION

Semester 1 Report

System Overview...........................................................................................................3

Overview of Formula SAE............................................................................................3The FSAE Car................................................................................................................4Stakeholder Identification.............................................................................................4Operational Concept.....................................................................................................5Budgetary Concerns......................................................................................................6System Context...............................................................................................................6

System Requirements..................................................................................................7Measurable System Requirements...............................................................................7

Required:.....................................................................................................................7Optional:......................................................................................................................9

Data Logging..................................................................................................................9Environmental System Requirements.......................................................................10Operational Requirements..........................................................................................11Graphical User Interface............................................................................................12

Discussion of Options................................................................................................15MoTec Data Acquisition System................................................................................15AIM Sports Data Acquisition System........................................................................16National Instruments cRIO........................................................................................16

System Definition........................................................................................................17Analysis of Option Choice...........................................................................................17Operational Definition.................................................................................................17

Methods of Measurement.........................................................................................17System Diagrams.......................................................................................................17cRIO Programming.................................................................................................18

Component Definition.................................................................................................18Instantiated Sensor List............................................................................................18cRIO Module Selection.............................................................................................18

Verification and Validation of System Design..........................................................18

System Overview

Overview of Formula SAEFormula SAE is a student design competition sponsored by the Society of

Automotive Engineers. Starting in 1979 as an annual event hosted in Michigan, the event has grown into an international series, sponsoring competitions in 8 competitions in 5 countries around the world. Despite event growth, the event in Michigan remains the most competitive event in the world, drawing over 120 teams from around the world. This year, event registration filled up all 120 available entries in less than 10 minutes.

The Formula SAE competition is split into two major sections. The first section, called the static events, is comprised of the cost analysis, business presentation, and design event. The cost analysis requires teams to document and report a full cost makeup for the prototype vehicle brought to competition. This includes discussion of manufacturing techniques, assembly labor and purchased components cost. The business presentation requires teams to develop and present a business plan to a group of potential investors, explaining mass manufacturing plans, marketing strategies, and financial expectations. The design presentation requires teams to present the design and engineering from which the vehicle was designed. This includes discussion of modeling and simulation, as well as testing and validation. A critical part of the validation of the engineering behind the vehicle will come through the addition of data collected by an instrumentation system.

Each event in the competition is given a different weight, shown for the static events in figure-1.

Figure-1. Static Events Weights

The SAE event is scored out of a total possible 1000 points between the static and dynamic events. As it can be seen in figure-1, the static events only comprise a total 325 points in the competition, and the design part of those points has the highest weight.

The dynamic events included in the FSAE event are comprised of the acceleration event, the skidpad event, the autocross event, a fuel economy competition and the endurance event. The acceleration event is a drag run designed to test the straight line acceleration of the car. The skidpad event is designed to test the cornering ability of the car. The autocross is a single lap run with varying radius corners and straights of varying length. The fuel economy event is run in conjunction with the endurance event and tests the fuel consumption rate of the car. The endurance event runs on a similar course to the autocross event, however the track is lengthened and the cars run for a half hour on average. This tests the durability of the car and also is the place where a majority of teams lose points as the rate of teams which complete the event is usually under 40%.

The dynamic events are also assigned point values, shown against the 1000 point total in figure-2.

7550

150

50

350

Cost & Mfg.

Presentation

Design

Acceleration

Skid Pad

Autocross

Fuel Economy

EnduranceFigure-2. Dynamic Events Weights

It can be seen by the above chart that the endurance event carries a majority of the total available points in the competition. It can also be seen that the dynamic events as a group comprise 675 out of the total 1000 points. This shows that the performance of the car is a major factor in the overall performance of the team at competition.

The FSAE CarFSAE cars are required to be compliant with a fairly loose set of restrictions

which form the Formula SAE Rules. Major restrictions include:- a 20 mm restrictor in the intake manifold, decreasing overall engine output power- a 610 cc engine displacement limit, causing many teams to use motorcycle engines- independent four wheel suspension- structural safety requirements, which keep the students who design and build the cars safe while they are driving them

Stakeholder IdentificationStakeholders for the project are separated into 5 major groups: FSAE Design

Team, FSAE Competition Team, Data Analysis Team, FSAE Cost Team, and the Senior Design Team.

FSAE Design Team – This stakeholder represents the Vanderbilt FSAE student members who participate in the design of the car. As the design of the car is an iterative process which allows the team to build on and perfect designs implemented in previous years cars, quantitative data is needed by this group so that more informed and effective design decisions can be made from year to year. Quantitative measurements of the cars performance are also useful for validation of design decisions and are an essential part of improving performance in the design event at competition.

FSAE Competition Team – This stakeholder represents the Vanderbilt FSAE student members who prepare the car and drivers for the dynamic events at the FSAE competition. As the dynamic events such a highly weighted part of the competition, maximizing the performance of the car and its drivers is a very important part of preparation for competition. The ability to collect data which will allow the car to be quantitatively tuned is a very important requirement for this group.

Data Analysis Team – This stakeholder represents the individuals who will be directly interacting with the system through the user interface. These users require an interface which is easy to use and is simple enough that it can be used by a variety of users on the FSAE team.

FSAE Cost Team – There are specific requirements which allow the system to not be considered in the overall cost metric of the car. This stakeholder requires that those requirements are met so that the cost analysis of the car will not be affected.

Senior Design Team – This stakeholder represents the individuals who will be designing, constructing and implementing the data acquisition system. So that the system can be effectively developed and implement within the time constraints of the academic calendar, they drive requirements limited scope and ease of completion.

Definition of ProblemCurrently, there are no quantitative performance measurements which are

available for validation or performance development. All performance feedback comes through driver feedback, which extremely limits the performance tuning abilities of the team.

Operational ConceptThe end result of this project is to develop a data acquisition (DAQ) system which

can be implemented onto any Formula SAE car operating in varying weather conditions, which will measure a variety of channels through a network of commercial sensors. The sensors will be connected to a device which will read the sensor outputs, convert the outputs to digital signals, and then process and store the signals. The system will have

some method which will allow the data to be downloaded to a personal computer. As a part of the system, a graphical interface will be developed which will allow the data to be further manipulated and analyzed by the user.

Budgetary ConcernsSome consideration within the system design process must be made to system

cost. Although cost will not be included in the cost analysis of the vehicle itself, the FSAE team operates on a limited budget of roughly $25,000 a year. It is thus necessary to balance system performance and cost, and to develop a system which is cost effective, yet durable and reliable, so that it can be developed and utilized by future years’ teams.

System ContextThere are a variety of context variables which affect the DAQ system. These have

been separated into two major categories. First are context variables. These variables, including the car itself and the way in which the car will be operated, are variables which drive the operational requirements and performance requirements of the car.

The other set of context variables identified for the DAQ system were defined as environmental context variables. These included electro-magnetic interference, vibration, and local heat sources encountered within the operating environment of the system (on the car). Other environmental variables defined included the weather based environments incurred through system operation, including rain, cold and hot ambient temperature environments.

System Requirements

Measurable System RequirementsAs in any data acquisition environment there are many signals that could

potentially be measured. Thus, we divide the potentially measurable signals into three categories: required, optional, and extraneous. The signals and measurements laid out under the required category are those that will contribute most to improving and validating vehicle performance. They constitute the true measurable requirements of this project and will be the primary focus of our efforts. Those items falling under the optional category will be pursued only if the project runs considerably ahead of schedule and far enough under budget to justify the added costs. It is noted that these items could potentially be the focus of any subsequent follow up projects. Lastly, we note that the measurables that fall under the final, extraneous, category do not add any information regarding vehicle performance or validation and would only be monitored out of convenience. Table-1 lays out the measurable signals into their respective categories, an in depth discussion of the signals in the first two categories follows.

REQUIRED OPTIONAL EXTRANEOUSShock Position & Velocity* Tire Temperature Fuel Level

Lateral & Longitudinal Accel. Ambient Temperature Fuel Consumption Rate*Wheel Speed* Water Temperature Oil LevelEngine RPM Exhaust Temperature Coolant LevelOil Pressure Oil Temperature Tire Pressure

Throttle Position Wheel Load Ride HeightSteering Position Chassis Slip AngleBrake Pressure

Table-1. – Measurables *-- indicates derived measurements

Required: Shock Position/Velocity – Is fundamentally a measure of shock position as a function of time. Four are needed, one for each shock. A linear potentiometer can be used to can be used to measure the expansion and contraction of an 8” shock. Data obtained shows how the car’s suspension reacts especially while cornering. It was decided that the resolution should be 400 Hz which is equivalent to every about 3 inches on the track. The potentiometer’s range needs to be 2.5” max distance with a maximum velocity of 400mm/sec. 4 channels will be required with a bit resolution of 16 and a bit rate of 3200 bytes/sec. To record 60 min of data 10.99 MB’s of memory will be needed for all 4 shocks.

Latitudinal and Longitudinal Acceleration - Is a measure of the car’s acceleration. A dual or tri axial accelerometer can be used to measure both accelerations. Data obtained shows the amount of acceleration both laterally and forward/backward that the car experiences while racing. The data can be used to compare how hard two different drivers can push a car in a corner or how quick they get on the throttle. It was decided that the resolution should be 200 Hz which is equivalent to every about 6 inches on the track. The accelerometer’s range needs to be +/- 4g. 2 channels will be required with a

bit resolution of 16 and a bit rate of 800 bytes/sec. To record 60 min of data 2.75 MB’s of memory will be needed.

Wheel Speed – Is a measure of how fast the car’s wheels are spinning, i.e. how fast the car is going. A Proximity or Hall Effect sensor can be used to measure wheel speed. Two wheels, one front one back will be measured and averaged in order to determine the car’s speed. It was decided that the resolution should be 200 Hz which is equivalent to every about 6 inches on the track. The sensor’s range needs to be able to handle up to 60 rpm. 2 channels will be required with a bit resolution of 16 and a bit rate of 800 bytes/sec. To record 60 min of data 2.75 MB’s of memory will be needed.

Engine RPM   – Is a measure of how many RPMs the engine is turning. This can be measured directly from the current Honda CRB600F4 motorcycle engine. It was decided that the resolution should be 200 Hz which is equivalent to every about 6 inches on the track. The range needs to be from 0 to 13,000 RPM. 1 channel will be required with a bit resolution of 16 and a bit rate of 400 bytes/sec. To record 60 min of data 1.37 MB’s of memory will be needed.

Oil Pressure   – Is a measure of the pressure in the engine where the oil is located. A pressure transducer will be used to measure oil pressure. Oil pressure is extremely important to measure in the SAE engine in particular because it is a motorcycle engine. Because it is a motorcycle engine, it is designed to operate while tilting side to side; keeping it flat when cornering like in the SAE car may negatively affect the oil pressure in the engine. It was decided that the resolution should be 20 Hz which is equivalent to every about 60 inches on the track. The oil transducer needs a minimum range of 0 to 150 psi. 1 channel will be required with a bit resolution of 16 and a bit rate of 40 bytes/sec. To record 60 min of data 0.14 MB’s of memory will be needed.    Throttle Position   – Is a measure of the position of the throttle. A rotary or string potentiometer can be used to measure the throttle position. It was decided that the resolution should be 200 Hz which is equivalent to every about 6 inches on the track. The potentiometer needs a minimum range 100 degrees. 1 channel will be required with a bit resolution of 16 and a bit rate of 400 bytes/sec. To record 60 min of data 1.37 MB’s of memory will be needed.

Steering Position   – Is a measure of the position of the steering wheel as the driver turns it. A rotary or string potentiometer can also be used to measure the steering position.  Data collected can be used to determine oversteer and understeer in the car. It was decided that the resolution should be 400 Hz which is equivalent to every about 3 inches on the track. The potentiometer needs a minimum range 540 degrees. 1 channel will be required with a bit resolution of 16 and a bit rate of 800 bytes/sec. To record 60 min of data 2.75 MB’s of memory will be needed.

Brake Pressure – Is a measure of the pressure in the break lines when the breaks are applied. A pressure transducer can be used to measure the pressure in the break line. Data collected can be used to determine an optimal front-to-rear break ratio to optimize

traction while cornering. It was decided that the resolution should be 200 Hz which is equivalent to every about 6 inches on the track. The pressure transducer needs a range from 0 to 2500 psi.. 1 or 2 channels will be required (to be determined) with a bit resolution of 16 and a bit rate of 800 bytes/sec. To record 60 min of data 2.75 MB’s of memory will be needed (for 2 transducers).

*Note: At this time the team has deemed only the Required measurements are necessary and will not proceed with Optional, or Extraneous during the project.

Optional: Tire, Ambient, Water Temperature – Is a measure of the temperature in the tires, outside air, and water in the engine. An IR Thermocouple with a range from 50 to 250 degrees F can be used. This data can be recorded with fair accuracy by measuring it manually during pit stops. Exhaust and Oil Temperature - Is a measure of the temperature out the exhaust pipe and oil in the engine. An IR Thermocouple with a range from 0 to 1000 degrees F can be used.

Wheel Load – Is a measure of the force applied to the wheels. A strain gauge can be used to measure wheel load. Wheel load is especially important in cornering as excessive or unbalanced loads can lead to uneven tire wear and poor traction.

Data LoggingBased upon the signals we wish to monitor, there are several system requirements

relating to data acquisition that we must define. These include bit resolution, sampling rate, and storage capacity. In order to obtain a consistent and high precision in our measurements, we choose a 16-bit resolution. The sampling rates are derived based upon analyzing the desired positional granularity of measurements on track. For example, if we want oil pressure measurements at every five-feet on track (at top speed), then we can determine what the sampling rate must be for the oil pressure channel must be to obtain this level of on track granularity. The table below computes these sampling rates based upon desired granularity. Referring to data logging literature as well as conferring with our project advisor confirms the selected sampling rates. Table-2 overviews the desired granularity on track, sampling rate, and expected dynamic range for each sensor. Note: top speed assumed to be 100 ft/sec.

Measured Resolution Sampling Dynamic RangeSignal On track (in) (Samples/Sec)  Shock Position/Velocity 3 400 2.5";Vmax = 400mm/secLat./Long. Accel 6 200 +/- 4gWheel Speed 6 200 60 rpm maxEngine RPM 6 200 0-13,000 rpmOil Pressure 60 20 0-150 psiThrottle Position 6 200 100 degree rangeSteering Position 3 400 540 degree rangeBrake Pressure 6 200 0-12500 psi

Table-2. – Sampling Rates and Dynamic Range Requirements

An extended version of the above table, including number of channels and the calculation deriving the data storage requirement, can be found in the appendix. The calculation shows that our system will require 25MB of data capacity in order to store sixty-minutes of logged data.

Environmental System RequirementsNow that we have determined all the requirements that we want to measure, we

must determine the requirements of the system based on the environment that it will be operating in. Since the data acquisition system will be operating on the Formula SAE car, most of these requirements are based on the external forces that can affect both the car and the data acquisition system (DAQ).

Electromagnetic Interference (EMI): A motor vehicle inherently has a large amount of electromagnetic interference, due to the combination of the engine and all other electronic systems required for the operation of the car. At this time, the actual amount of EMI is not easily quantifiable. However, the data acquisition system must be capable of operating under conditions with a large amount of EMI, along the lines of other industry-standard automotive applications. To accomplish this, either the DAQ itself must be immune to such interference, or a suitable shield must be built around it to minimize the amount of interference. This applies to not only the DAQ system, but the whole wiring system as well (i.e. cables must be electronically shielded).

Water Exposure: The FSAE car may be operated in a variety of weather conditions, including rain. Since the car has an open body and is so close to the road, water may inevitably splash up and come in contact with various parts of the car, including the DAQ. As a result, the whole DAQ system (including all cabling and connections) must be suitably waterproof. If this is not possible, the DAQ must be placed in a location and/or enclosure that prevents any water exposure.

Vibration: All parts of the car being built must be suitably durable to withstand all sorts of constant vibration. The DAQ is not excluded from this requirement. Vibrations encountered may include not only major bumps that may be along the track, but also constant shaking simply due to road noise and vibrations of the car.

Temperature: The DAQ will be submitted to a wide range of temperatures. This includes not only a wide range of external ambient temperatures (40-90 degrees F), but also local heat sources in the car well in excess of 100 F.

Weight: The weight of the FSAE car is an important characteristic that can potentially have a profound effect on the performance of the vehicle. To minimize the possible negative effects, it has been decided that the total weight of the entire DAQ system not exceed 20 pounds.

Physical Size: Based on an analysis of the previous year's FSAE car design, it has been determined that the optimal location for the DAQ system will be right in front of the driver, underneath his/her bent legs while in the seated driving position. This location prevents an uneven weight load because it is along the centerline of the car, and with a proper enclosure, should not be accidentally dislodged by the driver during a normal test run or competition. This space can accommodate a DAQ system with a maximum size of 10"x12"x5".

Other: A few other minor forces may exist that can adversely affect the performance of the data acquisition system. The system must be designed in such a way that the impact of these extraneous forces be minimized. For example, the location of the DAQ when mounted on the car must be chosen properly so as to minimize any air resistance, as well as prevent the driver from accidentally dislodging the system or any connections. Similarly, the whole wiring harness system must be mounted properly to withstand all normal operating conditions in addition to being out of the way when the driver is entering, exiting, and operating the vehicle.

The FSAE car is a motor vehicle operated in an outdoor environment and as such is subject to a wide barrage of external forces including electromagnetic, acts of nature, and the physical surface of asphalt. The car itself is designed and built to be able to withstand such an onslaught; the data acquisition system must be able to do the same. Not only must the DAQ survive taking such a beating, it must be able to continuously log and relay real-time data during the whole process without skipping a beat.

Operational RequirementsTriggering: The system must have a manual triggering mechanism if the system memory limit is less than the minimum requirement in order to collect the most important data that occurs after the vehicle warms up.  However, if there is ample system memory the triggering should be automatic, so that the data collected has a buffer between warm up operation and prime operation. 

Filtering: As in any data acquisition environment, some form of filtering must be implemented in order to maintain a high level of precision. Our system shall contain low pass filters to remove high frequency noise and distortions from our signals. The actual form of the filter depends on the exact signal and the sampling rate being filtered. The passband of each low pass filter should extend up to half the signal sampling rate. Note:

some sensors may already include sufficient backend filtering. Typical low pass filter implementation can be wired with a resistor and capacitor.

Data Transfer: As far as data transfer is concerned, the data collected from the racecar must be uploaded to a computer for analysis and interpretation.  This transfer must be done by using the ports of Universal Serial Bus (USB) or Ethernet Cable (Category 5e).  The aforementioned data must be stored within the system for the duration of testing. Based on standard FSAE testing, a minimum of 40 minutes will be required in order to collect sufficient data. 

SAE Compliance: To exclude the cost of the system from the FSAE competition report, the entire instrumentation system must conform to the SAE stand-alone rules.  According to the FSAE competition guidelines, the stand-alone data acquisition system must only monitor and record the vehicle data during operation.  This system must not have a control or display function that would interact with the driver.  Lastly, the entire system must be removable without affecting the performance of the vehicle in any way. 

Final Display: For the Graphical User Interface (GUI) the system requires accessibility, filtering, various math channels, a visual display, and specific data collection rates which are detailed in the Appendix.  For accessibility, the GUI must have standard graphing tools that have the ability to transpose multiple data sets.  Moreover, the interface of the data sets must have multiple speed playback ability so as to precisely focus or zoom into a particular section.  The only filter requirement for the types of data that will be collected is the Fast Fourier Transform (FFT).  For math channels, the interface must have transform and analog function capabilities.  As far as the Visual Display is concerned, the goal is to have the interface with various options to represent data by graphs, gauge levels, scatter plots, channel history, FFT output, channel reports, and section times with the adaptability of real-time playback.

Graphical User Interface RequirementsThe Graphical User Interface (GUI) for VU FSAE Instrumentation is a vital part

of the project because the raw data collected from the sensors are useless unless they are converted to a format that is readable and useful to the user. These data are Shock Position/Rate, Latitudinal or Longitudinal Acceleration, Wheel Speed, Engine RPM, Oil and Brake Pressure, Throttle Position and Steering Position. Below is an example of how the datasets can be displayed for various channels:

Figure-3. Signal Channels and Analysis*

Figure 1, above, shows the Speed (mph) of the car followed by the Throttle position, Brake Pedal, Gear and Engine RPM. (*MoTec Systems USA, http://www.motec.com/)

The speed graph shows how fast the car is traveling and whether it is accelerating or decelerating. The peaks show the fastest point on each straight while the troughs are the slowest point at each corner/run.

The throttle position shows what the drive is doing at specific time. The aim of this graph is to help the user (driver) to be always either accelerating or braking in order to achieve the quickest lap time.

The Brake Pedal Position trace will be replaced with Brake Pressure Developed. This shows when the brake is being applied. 100% means the brake is fully applied while 0% means no brake is being used. This trace is often used alongside the wheel speed traces to make sure the car is slowing as quickly as possible with no brake lock ups.

The Engine RPM trace shows how fast the engine is revving and how well the driver’s gear choice matches the demands of the circuit. The first gear ratio should be low enough to drive well out of the slowest gear on the circuit while the final gear ratio should see it reaching max rpm at the end of the longest straight.

In addition to the graph representations of the data, the user also requires that the data be represented in a way that a regular car driver would see them. A virtual dashboard that displays all the information required will be created. An example of a virtual

dashboard supplied by the maker of the racing game GTR2 is displayed in figure 2, below:

Figure-4. Virtual Dashboard and Playback Display*

This provides a real time representation of what happens over the lap. It’s useful for giving an overview and can provide an insight into the cars responses. (*MoTec Systems USA, http://www.motec.com/)

The steering in the middle of the virtual dashboard simulates the actual steering during the entire course of the race in real-time. The data that are read from the rotary or string potentiometer on the steering are translated here so that the user can determine oversteer or understeer when it happens.

The virtual dashboard must also have four horizontal bars that reflect the data collected from the linear potentiometer attached to each of the four shocks. Data from shocks on the left side of the car will be placed on the left side while data from the right shocks on the right side. Front and rear shock position data are distinguished by putting the bars in top and bottom arrangement. Below is an example of how they could be positioned on the virtual dashboard.

Figure-5. Possible shock representation

Discussion of Options

There are about 10 to 20 major manufactures of data acquisition systems that have products that could be appropriate for Formula SAE racecar data acquisition. Of those companies, MoTec and AIM Sports offer the best turnkey systems in the industry in terms of performance and price. The final option we will discuss is using the National Instruments cRIO platform.

MoTec Data Acquisition SystemMoTec is one of the leading manufacturers of Engine Management and data

acquisition systems for performance racing around the world. In order to use MoTec hardware and software for data acquisition, the following complete package would need to be ordered. M4 ECU with Advanced Tuning & Logging (See picture in Appendix I), MoTec SDL Data Logger, M4 10 foot unterminated Harness, Clockwise rotation Throttle Sensor, Harness Termination Kit, Communications Cable, USB Communications cable, MoTec Data Analysis Software, and a 1000 Channel Beacon Receiver. Additionally all sensors would need to be purchased and of MoTec brand.

There are many advantages of using the MoTec system. The system is an easy to install and use. The hardware and software equipment has been proven based on its high use in the motor sports world. Additionally the graphical user interface that works with the MoTec hardware/sensors is extremely user friendly and high quality (See picture appendix II). Furthermore, ordering the system from a major company like MoTec provides product support incase of failure or troubleshooting.

The two primary disadvantages of this system are its price and system constraints. The price of the entire MoTec data acquisition system including an ECU is $5059.59. That is before the purchasing of sensors (Christiansen). This is out of the SAE/Senior Design team’s budget. Furthermore the MoTec system would require the purchasing of only MoTec sensors which are inflated in price by 25% to 150% over competitors, likely another $2,000 to $3,000. Another drawback is that the code used to interpret data in MoTec software is proprietary. This creates a problem because if the team ever wanted to record and interpret data from a sensor not supported by MoTec it would not be possible. Although the MoTec system is great in terms of performance, its price is a major deterrent making it obsolete as an option for a Data Acquisition System. The system is of very high quality in both design and performance. The team will likely

attempt to mimic certain aspects of this well designed system with whatever design is chosen.

AIM Sports Data Acquisition SystemAIM Sports also offer data acquisition systems similar to MoTec. DaVid is the

video and data logging system for race cars offered by AIM (AIM Sports). The AIM system is very similar to the MoTec system both in terms of hardware and software. See AIM specs in Appendix III. The AIM system is slightly cheaper than MoTec starting at $2000; it does not include an ECU (ranging form $500 to $10,000) or sensors (AIM Sports). The same problem that affected the MoTec system where that the software’s code cannot be modified to support additional sensors and data input also is a problem for the AIM software. The AIM system is better than the MoTec system in that a broader set of less expensive sensors can be used, but its overall performance and user interface and performance appears to be worse. Although the AIM data acquisition system is slightly better than the MoTec system in terms of price, it is still far too expensive costing at least $2500 more than other alternatives.

National Instruments cRIONational Instruments provides a wide range of products in the data acquisition

system market. Of these, the NI CompactRIO (cRIO) is the most suitable to operating in a harsh yet mobile environment.

The cRIO (in combination with National Instruments' LabVIEW software suite) is a very capable data logging and analysis system. The cRIO-9012, in combination with the cRIO-9103, has a 400MHz internal processor, 64 MB of DRAM (and 128 MB of internal storage), and 4 modular slots of input & output. There are (at least) two modules that are applicable to the applications in this project: the NI 9205 has 32 channels at 16 bits resolution with up to 250,000 samples per second, and the NI 9215 has 4 additional channels at 16 bits resolution and up to 100,000 samples per second per channel. With both of these modules loaded into the chassis, the total system weighs 3.082 pounds and measures approximately 7"x4.5"x3.5". The cRIO supports both Ethernet and USB connections for to integrate with the LabVIEW software on a computer. In terms of durability, the cRIO system is rated to withstand temperatures from -40 to 148 degrees F, and shock up to 50g.

Using the National Instruments cRIO system has several distinct advantages. First of all, unlike the other two DAQ choices, the choice of sensors is very open and not limited by the National Instruments system. Not only does this allow for more options in terms of the type of sensors used, it allows for sensors of different brands to be purchased, possibly decreasing costs. Besides reducing sensor cost, using the cRIO system is essentially free for the senior design group. Not only is the cRIO already in our possession (donated by NI), Vanderbilt also has a site license to the LabVIEW software suite, making it free of charge to the senior design team. Going along with this, Vanderbilt also has many contacts with National Instruments, ensuring that technical support will always be accessible and assisting. In addition to being a low-cost solution, the modular design of the cRIO allows the system to be interchangeable and expandable. If in the future it is decided that components or requirements need to be changed, added, or removed, the whole system does not need to be scrapped – instead, modifications just need to be made to the LabVIEW FPGA code.

There are two possible disadvantages that come up when discussing the NI cRIO. First, since it is not a turnkey system, installing and managing the hardware (and software) will require more troubleshooting. Similarly, LabVIEW is reputed to be a complicated development environment with a steep learning curve. However, with a plethora of technical support in a wide variety of forms available, these obstacles will surely be overcome.

System Definition

Analysis of Option Choice

Every aspect of all three system options was carefully considered. After an analysis of all advantages and disadvantages and the system requirements, the senior design team elected to use the National Instruments CompactRIO system. In addition to the major cost benefits of using the cRIO and LabVIEW, table-3 below demonstrates how the NI system (cRIO-9103 in combination with NI-9205 & NI-9215 modules) meets or exceeds all the system requirements.

Category Requirement CapabilitySampling Rate ~3.5k Samples/sec 650k Samples/sec# Channels 14 36Memory 25MB 64MB DRAMData Transfer 0.4 MB/s USB: 1.5 MB/sOperating Temp. 20 – 105 F -40 – 148 FShock/vibration automotive industry standard 50gWeight <20 lbs 3.082 lbsPhysical Size 10"x12"x5" max 7"x4.5"x3.5"

Table-3. Requirements vs. Capabilities

Operational Definition

LabVIEW FPGA

The programming platform of LabVIEW FPGA (Field-programmable Gate Array) and the cRIO is the perfect combination for the system.  The most important advantage is that the technology allows for custom hardware alterations when the testing requirements change in order to avoid having to build new hardware.  The LabVIEW FPGA allows the creation of custom Input/Outputs (I/O) and control hardware using the easy-to-use graphical development.  Furthermore, LabVIEW FPGA has built-in interface functions that integrate the cRIO hardware onto the Windows environment.

Figure-7.

cRIO Programming

Component Definition

Instantiated Sensor ListAfter careful review and product comparisons, sensors were selected. Quality, price, durability, and ease of installation in that order were the primary factors considered in choosing between sensors.

Measurement Sensor Brand Part Number CostShock Position/Rate Rotary Potentiometer P3 MP20IP  Latitudinal and Longitudinal Acceleration Accelerometer Crossbow GP Series tri axis $315

Wheel Speed Proximity Sensor Omega PRX-102-8n $85

Engine RPM Direct**Data can be taken directly from engine - Honda CBR600F4

Oil Pressure Pressure Transducer Omega PX32B1-250GV Already own

Throttle Position Rotary or String Pot      

Steering Position Rotary or String Pot      Break Pressure Pressure Transducer Omega PX305-3KGI $285

Table-4. Instantiated Sensor List

Note: Sensors for ‘Optional’ and ‘Extraneous’ measurement items were not selected because the team decided not to proceed with those measurements. Note however that the Omega OS36-2-J-80F IR Thermocouple is recommended for tire and ambient air ‘Optional’ measurements.

cRIO Module Selection

Verification and Validation of System Design

APPENDIX

A.1 – Data Logging Requirement

A.2 – NI - cRIO Industrial & Environmental Certifications