Team 2 University Of Pennsylvania School of Engineering and Applied Science Department of Electrical and Systems Engineering ESE 450/451

Senior Design AutoPlug: Open Architecture for Automotive Services Ross Boczar boczar@seas.upenn.edu Gabriel Torres gtorres@seas.upenn.edu Jason Suapengco (CIS) jasonns@seas.upenn.edu

6 May 2011

Advisor: Dr. Rahul Mangharam, mLab, University of Pennsylvania

Phase 2 Report

Abstract: The modern automobile features more software components and electronics than ever before. These electronics are prone to error, however, and vehicle recalls in the U.S. in 2009 crossed over 16 million, with several million due to software bugs [1]. Unfortunately, many of these components (known as ECUs - Electronic Control Units) are black boxestheir internal states are difficult to determine. This creates a dilemma for car manufacturers, as knowing the state of the electronics and software of a car could enable them to make better decisions regarding recalls and warranty management. There is a need to remotely diagnose, update and certify automotive software for efficient warranty and safety management. AutoPlug is an automotive ECU testbed to develop mechanisms and protocols for remote diagnosis, programming and testing of future vehicles. The goal of AutoPlug is to allow car manufacturers to better identify, characterize, and predict automobile software errors. AutoPlug consists of three layers: the vehicle simulation layer, the ECU network layer, and the middleware layer. The vehicle simulation layer, implemented in the open-source racing engine TORCS, provides realistic data to the ECU network. The ECU network layer, which models individual car systems, such as steering or anti-lock brakes, receives this data and applies to typical control algorithms. The middleware layer controls the interconnections of the ECU network and is responsible for acting as a gateway (via a user interface) between the manufacturer and the ECU network. This layer provides the interface for re-flashing software, diagnosing software errors, and gathering vehicle statistics.

Table of Contents 1. PURPOSE AND SCOPE .......................................................................................................... 4 2. INTRODUCTION..................................................................................................................... 6 3. DISCUSSION OF PREVIOUS WORK .................................................................................. 8 4. STRATEGIC PLAN/STRUCTURE ..................................................................................... 10 4.1 SYSTEMS APPROACH..................................................................................................... 10 4.2 SYSTEM SPECIFICATIONS ............................................................................................ 17 4.3 HARDWARE AND SOFTWARE REQUIREMENTS ...................................................... 22 4.4 TEST AND DEMONSTRATION ...................................................................................... 26 4.5 SCHEDULE ........................................................................................................................ 29 5. RESULTS ................................................................................................................................ 33 5.1 SIMULATION .................................................................................................................... 33 5.2 ECU NETWORK ................................................................................................................ 34 5.3 MIDDLEWARE ................................................................................................................. 42 5.4 OVERALL SYSTEM ......................................................................................................... 44 6. LESSONS LEARNED ............................................................................................................ 47 7. EQUIPMENT NEEDS ........................................................................................................... 48 8. CONCLUSIONS AND RECOMMENDATIONS................................................................ 49 9. NOMENCLATURE ................................................................................................................ 50 10. REFERENCES ...................................................................................................................... 51 11. BIBLIOGRAPHY ................................................................................................................. 53 12. FINANCIAL INFORMATION ........................................................................................... 54 13. ETHICS ................................................................................................................................. 55 13.1 DESCRIPTION OF LARGER CONTEXT ....................................................................... 55 13.2 ANALYSIS OF ETHICAL ISSUES ................................................................................. 55 13.3 ETHICAL RECOMMENDATIONS ................................................................................ 55 14. SOFTWARE DOCUMENTATION .................................................................................... 56 15. APPENDICES ....................................................................................................................... 57 A1 CODE FOR SOFTWARE MODULE PEDALS ............................................................ 58 A2 HARDWARE DIAGRAMS ............................................................................................... 107 A3 CONTROL DIAGRAMS ................................................................................................... 116 A4 ADDITIONAL GRAPHS ................................................................................................... 119

A4.1 EXAMPLE ABS/BRAKES OPERATION .................................................................... 119 A4.2 PATHOLOGICAL ABS/BRAKES OPERATION ........................................................ 121 A4.3 CABIN COMFORT CONTROLLER ............................................................................ 124 A5 DATASHEETS .................................................................................................................... 125 A6 MATHEMATICAL EQUATIONS ................................................................................... 126 A7 ADDITIONAL SCREENSHOTS ...................................................................................... 127

1. PURPOSE AND SCOPE Modern automobiles have become reliant on electronics in order to operate. Traditionally, the typical car did not employ the use of complex electronics in order to operate, making most of its operations completely mechanical. Today, as electronic components become ubiquitous in automobiles, manufacturers must take into account faults of design and operation in both the electronics and mechanical aspects of the car. What this project addresses is the need for manufacturers to efficiently identify and resolve both software and hardware errors across an existing customer base. In order to achieve this, the project scope was to design and implement the following: A basic network of ECUs (Electronic Control Units), connected together using the CAN (Controller Area Network) protocol. While each ECU controls a specific function of a car, the network itself represents the basic components of a car, such as: Throttle Anti-Lock Brakes Steering Transmission Cruise Control Integration of the ECU network into an automobile simulation model. This was accomplished using the TORCS open-source car simulation engine. The TORCS car model was used to feedback simulated data to the ECU network. A middleware layer for both the verification of ECU network design as well as a user interface to achieve the necessary goals. With the use of these systems, the project achieves the following goals: Remote Diagnostics: Manufacturers are able to interface with a vehicle remotely and analyze ECU data to determine what is wrong with the car. Bad sensor data can point towards a mechanical malfunction and the on-board diagnostic system can warn the driver about errors with more accuracy and specificity. Data Logging: Historical data gathered from vehicles using AutoPlug can be used to predict whether errors will occur in the future. An example of which could be degraded performance of a certain component that could lead to more serious issues. ECU Firmware Upgrades: Software errors can be fixed by deploying new firmware, in the event of software bugs. This can be done remotely (for non-critical components), or at a dealership (for critical components). ECUs are currently replaced instead of reprogrammed in the event of a software malfunction. Recall Management: a manufacturer is able to tell which cars are affected by a recall by simply accessing the CAN data that the middleware layer stores. Using this data, a manufacturer can both identify the parts that are in each vehicle and alert the consumer in the event of a recall.

This project did not consist of designing the electronic bare-bones of a car accurately. Such a design would take years to complete, and it was not necessary for our project goals. The system did need to maintain the characteristics of a modern vehicle electronic system, such as the use of the CAN protocol and individual ECU hardware. Without the use of standard real world components in our design, the project would be useless to our audience, as manufacturers would have to redesign the whole automobile in order to take advantage of our results. Another distinction that needs to be made is that some of the components that were represented in the project design deal with safety-critical applications. We recognize that there are both safety and privacy concerns associated with the final implementation of such a system, but the project focus remained on the implementation of a functioning product, and not on privacy and security concerns. In order to verify the success of the project, we replicated a series of scenarios in which each of our design goals was tested. A bug (software error) was introduced into the system that the middleware layer detected. This bug was in the form of incorrect operation of certain ECUs that was corrected using the ECU upgrades capabilities of the system. In order to verify the validity of the ECU network, the middleware layer provided visualizations that corresponded to the behavior of the simulations. This proved that the ECU network was behaving correctly and reporting the correct information.

2. INTRODUCTION Due to the increase of electronic sub-systems within a modern vehicle, the amount of repairs due to errors in both design and operation of those sub-systems has been increasing in an alarming rate. Most new vehicles in the market are advertised to use drive-by-wire technology for operation, which means that there is no longer any mechanical control from the users input to the actual operation of the car [2]. Modern vehicles are mostly controlled by computers, who in turn take inputs from a driver. A typical modern car will include 70-100 ECUs (Electronic Control Units), each controlling a specific function of the vehicle. These ECUs contain a total estimate of over 100 million lines of code [3]. As a point of reference, Microsofts Windows XP contained about 40 million lines of code, when it was released in 2001 [4]. Due to this reliance on electronics, automobile repairs are no longer limited to mechanical problems, with repairs due to electronic or software bugs becoming more widespread. Since virtually all software contains bugs, the automotive industry has had to adapt to this increase by employing more rigorous tests and design paradigms. Nevertheless, software bugs are unavoidable. Some of the software written by NASAs Software Assurance Technology Center, which is some of the best in the industry, contains about one error per 10,000 lines of code. In the software industry, the number of software bugs is closer to 20 per 1,000 lines [4]. By extrapolating this number it is easy to see that car manufacturers have a daunting task to deal with when addressing automobile software functions. The AutoPlug system assists manufacturers in this area, by providing an efficient way to correct software problems after release. In 2009, vehicle recalls in the US crossed the 15 million mark, representing a large cost to manufacturers [1]. While the exact number of recalls due to software errors is not available, some individual data from specific manufacturers is, with the total number of recalls due to software errors in several millions. AutoPlug consists of three layers: simulation, ECU, and middleware. The simulation layer models a real automobile (1999-2001 Mitsubishi Lancer EVO VI), which provides a form of verification for the ECU network. The ECU network consists of several micro-controllers, each of which performs a specific function (e.g. steering, locking/unlocking doors, changing gears). These micro-controllers are networked together using the industry standard CAN protocol. The CAN protocol is used in virtually all modern automobiles as a means of communication between ECUs [5]. Some functions of vehicles, such as Anti-Lock Braking System, require several ECUs to work together in order to perform the necessary tasks, thus there is a need for them to communicate. The middleware layer consists of a small computer that provides a gateway for the vehicle manufacturers to interface with the ECU network. These three systems allowed us to implement the features outlined in the previous section: Remote Diagnostics: Manufacturers are able to interface with a vehicle remotely and analyze ECU data to determine what is wrong with the car. Bad sensor data can point towards a mechanical malfunction and the on-board diagnostic system can warn the driver about errors with more accuracy and specificity.

 Data Logging: Historical data gathered from other vehicles using AutoPlug can be used to predict whether errors will occur in the future. An example of which could be degraded performance of a certain component that could lead to more serious issues. ECU Firmware Upgrades: Software errors can be fixed by deploying new firmware, in the event of software bugs. This can be done remotely (for non-critical components), or at a dealership (for critical components). ECUs are currently replaced instead of reprogrammed in the event of a software malfunction. Recall Management: a manufacturer is able to tell which cars are affected by a recall by simply accessing the CAN data that the middleware layer stores. Using this data, a manufacturer can both identify the parts that are in each vehicle and alert the consumer in the event of a recall. Remote diagnostics is an important step in the evolution of vehicle repair. The current paradigm consists of the user detecting unusual behavior, taking the vehicle in to the mechanic, being quoted an amount for the repair and finally paying the mechanic for work done. A system of remote diagnostics allows a consumer to get up to date reports on the state of their car, avoiding an unnecessary trip to the mechanic and additional costs. Even more useful is the ability for car manufacturers to accurately detect which cars are affected by a problem in the event of a recall. As it stands now, automotive companies frequently recall more cars than they need to because they have no way of knowing which cars happen to be affected by a problem[6]. This results in large costs and unnecessary trips to a dealership. Preemptive maintenance goes hand in hand with remote diagnostics. Major vehicle faults are sometimes due to negligence and improper maintenance at the hands of the user, be it due to ignorance or other causes. The manufacturer can remotely analyze the data provided by the ECUs and alert the consumer before a minor issue becomes more serious. Firmware upgrading is also an important feature of AutoPlug, allowing car manufacturers to deploy new firmware for ECUs without the need to replace the units. The current method of repairing electronic control units consists of replacing them with a new one. Mechanics simply have no other way to do so [3]. This costs car manufacturers and users large amount of money due to unnecessary replacement parts.

3. DISCUSSION OF PREVIOUS WORK The motivation behind creating an automotive ECU test-bed with mechanisms for remote diagnosis and software management is based on the idea of the car as a platform referenced in [7] as well as other sources. We will first examine projects whose goals are similar to that of this report. A paper on AutoSar, a project dedicated to creating a standard for an automotive architecture, states how the introduction of an industry wide standard is necessary and will open new and different business opportunities for OEMs (Original Equipment Manufacturers) and their suppliers [8]. As a collaboration of many different manufacturers (BMW, Bosch, Continental AG, Chrysler, Ford, GM, Toyota, and Volkswagen), the goals of this paper can be seen as profitable for these companies. With the completion of an architectural standard (AutoSar), said companies can potentially purchase hardware from different vendors. On the surface, AutoSar appears to be very similar to what we aim to do in this project. However, the focus of our project is not to standardize the electronic hardware of a vehicle, but rather to implement a system in which our goals are feasible. The ECU test-bed is simply a means to demonstrate that the features described are possible and should be implemented in future automobiles. Since an automotive electronic test bed standard has not yet been developed, relevant work will be examined for each component of the project. Vehicle Simulation Layer Vehicle dynamics simulation could be considered its own industry within automobile design. Many commercial off-the-shelf packages exist for simulating real-time motion of automobiles. CarSim, rFactor, and ADAMS/Car are some of the vehicle simulation suites that have the ability to integrate with controller models for real-time simulation. Initially, the focus of this layer was to design a simulator in Simulink, a control systems design suite. Though attempts were made using literature on different approaches to vehicle dynamics simulation, including multi-body [9] and analytical models [10], the decision was made to instead use the open-source racing and simulation engine TORCS. The TORCS program includes a physics simulation engine to model car dynamics, although it is not as nearly as accurate or detailed as commercial packages as CarSim. However, its opensource architecture and price (free) made it the most sensible option for this project. Models of additional vehicle components and ECU controllers (such as the engine, Anti-lock braking system, or steering control) will need to be integrated into the TORCS engine. There exist many examples of these systems, such as the system described in [11], and these will be pieced together and possibly modified to fit into the overall automobile model. However, these controllers would most likely need to be modified in order to work in our system.

Middleware Layer There are implementations of existing systems, such as GMs OnStar, that perform similar functions to what we aim to achieve, such as remote servicing [11]. These systems do not perform firmware upgrades nor allow for direct remote management of the firmware. In contrast, these programs are company specific and do not adhere to a standard across manufacturers. The diagnostic and upgrade system of this project would be available for cars not outfitted with an OnStar type system. Although OBD-II (OnBoard Diagnostics) ports are not installed in all cars, they have become federally mandated in the U.S. and as new vehicles replace older ones, the OBD-II port will be available in most vehicles. There has also been development concerning high-level systems in a car, such as Microsofts Blue&Me in-car entertainment system which integrates several high-level media units of the car like a cell-phone and speaker system. AutoPlug is at a lower-level than systems such as Microsofts Blue&Me. Therefore, Microsofts and other systems can still operate within the electronic test-bed. Research has also been done that proposes a method of updating the software on the ECU in C++ [12]. Although these proposals have been made, they have yet to be carried out. With an electronic test-bed in place, it is more efficient to update ECU software as the system for updating would be specified to the test-bed and would not be vehicle-specific. ECU-CAN Network Several papers have discussed the implementation of an ECU network using the standard CAN protocol, some have even gone as far as showing how the security of such a network is compromised. As [7] has shown the ease at which the modern vehicle can be controlled and attacked (successfully) using remote tools is quite high. Although, they did not create an ECU test bed, but used an actually vehicle in their security attacks, their setup is similar to what we are implementing. By connecting to the OBD-II port, they were able to obtain read/write access to the ECU network of the vehicle. Although security considerations are out of the scope of this project, it may be possible to upload firmware on the car with better security in the future. In terms of the automotive electronic test bed, there has been much research concerning each individual ECU. Such examples are research that looks into the software architecture for the ECU controlling the manual transmission [13] and research concerning the ECU controlling the rear wheel steering system [14]. Although this research focuses on the individual unit, it does not encompass than entire ECU network. Research has been done concerning optimizing CPU usage across ECUs while meeting time-constraints [15].This paper reveals that it may be possible to use fewer processors to run jobs while matching the required time constraints by utilizing the processors in an effective manner. It is important to keep in mind this idea of a time constraint in the ECU test bed in order to ensure safe functioning of the car. In addition to research about job scheduling across CAN, there can be job scheduling in an ECU [16]. This research uses ECUs ported to an OSEK real time operating system (RTOS) - similar to this projects. Using OSEK, job speeds are reported and the time it takes to switch tasks are recorded. The results show that the OSEK RTOS was able to complete the many tasks required of an ECU in an automobile in an efficient manner.

4. STRATEGIC PLAN/STRUCTURE Section 4 outlines the specifications and operation of both the abstract high-level system and its individual subsystems. 4.1 SYSTEMS APPROACH At the most abstract level, AutoPlug can be viewed as the interconnection of three different layers: the simulation layer, the ECU network layer, and the middleware layer. Figure 4.1-1 illustrates the connections between the three layers. Simulated control inputs are passed to the car simulation model. The model then outputs simulated sensor data about the car to a network of microcontrollers representing the ECU network. The ECU network and the middleware layer then work together to process data and make decisions about the car's operation, which are then sent back to the running simulation (Figure 4.1-2). As Figure 4.1-1 shows, both the simulation and middleware layers interface with the ECU network, which in turn takes input from a user.

Figure 4.1-1 High-Level Overall System Diagram

10

Figure 4.1-2 Mid-Level System Diagram

11

4.1.1 Simulation Subsystem The core of the simulation subsystem was a real-time simulation of an automobile using the racing/simulation engine TORCS (Figure 4.1.1-1). Since our project by nature was the development of an open-source architecture, we needed to use an open car simulation model, as having to reverse-engineer an actual car in order to interface it with the other components of our architecture was the exact problem we were trying to avoid.

TO ECU
Figure 4.1.1-1 Simulation Subsystem The TORCS model simulated car dynamics through physics-based modeling, as well as individual car subsystem components (engine, suspension, steering system). However, additional code needed to be added in order to support some ECU network functions. This code included modeling additional vehicle components, as well as integrating the data acquisition board into the simulation in order to provide real-time inputs and outputs. Since TORCS was a free open-source program, we were at the mercy of the developers in terms of model accuracy.

12

The TORCS online community was solely responsible for the fidelity of the simulation. However, for the purposes of our project, we believed that the TORCS model was sufficient to show feasibility of the overall system. The TORCS simulator provided the following features that we deemed essential to the feasibility of our project (including but not limited to): Realistic tire dynamics based on the Pacejka tire model, an industry-standard empirical tire model Variable road conditions Accessible physics engine outputs for use in ECU network (e.g. yaw rate, wheel speeds, later acceleration) Suspension and differential modeling

The main alternative to TORCS was the industry-standard CarSim, a high-fidelity simulator. However, the cost of CarSim was prohibitively high (upwards of $8,000 for an academic license) and was a closed-source program, which would not have afforded us the flexibility to make the previously mentioned changes in the code. Using the open-source TORCS model allowed the design focus to be placed on the ECU network-middleware interaction, which was the central focus of AutoPlug. The parameters defining the TORCS car model were based on the 1999-2001 Mitsubishi Lancer EVO VI. This car was chosen as the representative model for our project as its real-life counterpart included many of the software-based systems we intended to model (ABS, stability control, active differential control). Also included in the simulation subsystem was a block representing a visualization of the simulation data. This represents the TORCS visualization screen (Fig. 4.1.1-3), which aided in model verification and demonstrated correlation between simulated real-world data involving the car and the processed data displayed by the middleware layer visualization.

13

Figure 4.1.1-3 TORCS Visualization

4.1.2 Simulation - ECU Network Connection: The interface between the TORCS car simulation and the microcontroller ECU network was implemented using a data acquisition card (DAQ) on the host computer. This card provided both analog and digital I/O for transmission of data between the two layers. We used two National Instruments cards (model NI-6229-M) with four connector blocks.

4.1.3 ECU Network Subsystem The ECU network subsystem consisted of individual Freescale MC9S12 micro-controllers that perform each specific function within a vehicle. Figure 4.1.3-1 shows a general interface between the ECUs and the CAN network. As can be seen from the figure, each ECU connected the network in parallel, with every ECU able to receive the messages that are passed through the circuit. CAN-HIGH and CAN-LOW are the two rails that make up the CAN bus. The ECUs had

14

built in CAN transceivers and thus could connect directly to the CAN bus. The inputs/outputs on the figure are not exhaustive and only make up the CAN interface connections.

120 Ohms

120 Ohms

Figure 4.1.3-1 ECU Network Subsystem Individual ECUs varied by design depending on their function, but most of them consisted of a connection to the CAN network, inputs from the DAQ board and the corresponding output back to the DAQ. Inputs were generally analog, which had to be converted into digital signals for processing. The outputs of the ECU refer to both the interface to the CAN and the outputs to the actuators, which were simulated using TORCS. An example, Figure 4.1.3-2 shows the hardware diagram for the transmission ECU. In this example, all inputs and outputs are digital. For more specific designs, please refer to the diagrams in the result section.

15

5V
CAN_H RAIL CAN_L RAIL Pin 1 Vaux CAN HIGH Pin 45 PB5 CAN LOW Pin 47 PB4 Pin 49 PB3 Pin 51 PB2 Pin 53 PB1 Pin 55 PB0 GEAR_2 FROM TORCS GEAR_1 FROM TORCS GEAR_0 FROM TORCS GEAR_2 TO TORCS GEAR_1 TO TORCS GEAR_0 TO TORCS

HCS12

Pin 3 GND

Figure 4.1.3-2 ECU Design Model (Transmission) 4.1.4 ECU Network Middleware Connection: The individual ECUs only interfaced with the middleware through the CAN bus. Refer to section 4.2.2 for how they were connected. 4.1.5 Middleware Subsystem The middleware subsystem consisted of standard computer running Linux. At the design stage of this project, we planned on using a small single board computer called the BeagleBoard to perform all of our middleware functions. Due to speed and power constraints, we fell back on this plan and used a standard laptop instead. All of the design and code would work on any computer that supports the Linux OS and has a USB port, so a faster and more expensive version of the BeagleBoard could work in the future. The middleware computer listened to the CAN bus to store and process relevant information, and acted as a gateway for the vehicle manufacturers to take advantage of the following features:

Vehicle Visualizations: Acts as a dashboard to display vehicle state. This corroborates the simulation as well as the ECU network. Remote Diagnostics: Contains routines that perform diagnostics for each ECU. It simply uses the CAN messages that are received and analyzes them. This could be done locally or remotely by the manufacturer. ECU Upgrades: ECU upgrade interface for remote upgrades through the CAN bus.

16

4.2 SYSTEM SPECIFICATIONS The overall system consisted of a combination of the three subsystems that have been previously described. The final system interfaced the ECU Network with both the simulation layer and middleware layer to create a virtual car in which the user (an individual who the project is being presented to) could actively drive and input different settings to a simulated car. In other words, the overall system behaved as if it were a car, only in simulation interfaced with the ECU network. The system is best described the Table 4.2-1. Table 4.2-1 Inputs Simulation Response Middleware Response Steering Car Turning Steering Angle Reported Brakes Car Braking, Brake Lights On Brake Alert Accelerator Car Acceleration Increased Speed, Fuel consumption Shifter Transmission Shift Gear change reported Cruise Control Constant Velocity Report Cruise Control Mode Trans Mode (Man. To Auto) None (Dependent on ECU) Report Transmission Mode Lights Turn Headlights on Report Light status Engine Mode (Sport v. Econ) Different shift points Report Engine mode The user can also use the middleware layer to interface with the vehicle. The middleware layer will allow the running of diagnostic functions, data logging as well as reprogramming an ECU through the CAN bus. Through the middleware layer, the user is able to explore the different features that were implemented in the project, such as: Table 4.2-2 Middleware Function Description Displays Speed, RPMs, Fuel level. Car state information should match up with simulation characteristics. ECU data used for identifying possible malfunctions. An ECU can be reprogramed without removal. An interface in the middleware layer allows for this. Info on past trips is available. Data logging can be enabled at will and can store all information that is being transferred in the CAN bus.

Middleware Function Car State Information

Remote Diagnostics Remote ECU Flashing

Data Aggregation (Statistics Gathering)

4.2.1 Simulation Subsystem

Open-source car model provided in TORCS racing/simulation engine (Linux); will be modified in order to support ECU network functions 17

Model type: 1999-2001 Mitsubishi Lancer EVO VI (in order to capture high-end ECU features) Mixed continuous/discrete model (hybrid system); simulation timestep: 0.002s Simulated using TORCS engine, interfaced with the DAQ board Uses C API (Application Programming Interface) for the DAQ, using the NI DAQmx driver NI DAQ board (PCI 6229 M Series, SCB 628 Connector Block)- interfaced with TORCS Max sample rate: ~50kHz (1 channel) 2 boards running in parallel Provides analog and digital I/O, as well as counter I/O (for Pulse Width Modulation [PWM] signals) Simulation visualization TORCS racing visualization Used to show correlation with dashboard visualization running with the BeagleBoard Data outputs included: accelerometer data, cabin control data, engine, user controls, steering input, gas pedal/brake input (see Section 4.3.3 for complete list)

4.2.2 ECU Network Subsystem Each ECU was implemented using an HCS12 microcontroller (MC9S12C128 variant). The controllers were supplied by the University and were manufactured by Axiom Manufacturing (internal model: APS12C128). Implemented ECUS:

Steering o Provided steering input through electronic wheel, as well as buttons for manual shifting and cruise control Pedals o Provided input for accelerating/braking by analog pedals Cruise Control o Controlled car speed when enabled to match set speed Transmission o Changed gears automatically or manually depending on user selection Anti-Lock Brake System (ABS)/Brakes o Reduced skidding when brakes were applied quickly Cabin Comfort o Allowed user to maintain virtual cabin temperature Engine o Reported RPM and fuel level data Differential Control

18

Reduced oversteer/understeer (turning rate or yaw rate instability) Console o Provided switches for virtual car lights as well as switching between transmission and engine modes

Table 4.2.2-1 and Table 4.2.2-2 describe the physical and electronic inputs and outputs for each ECU in the ECU network. The CAN messages are the internal software names for the signals being sent over the CAN network, detailed in Section 4.3.3. Table 4.2.2-1 ECU Signal Specifications MIDDLE -WARE ID 0x0D INPUTS FROM OUTPUTS TO TORCS DAQ TORCS DAQ Vehicle speed Linear wheel speeds x 4 Transmission gear Individual brake commands x 4 Transmission gear command Accelerator commands Accelerator pedal, brake pedal Shift buttons, cruise control set/reset buttons, steering wheel angle

ECU NAME Cruise Control

A/D INPUTS (OTHER)

ABS/Brakes Transmission Pedals

0x0E 0x06 0x04

Steering Engine Cabin Control Differential

0x05 0x03 0x0A 0x0C

Steering angle Engine RPM Cabin temperature Yaw rate error

Fan power Headlight,brakelight Headlight command, Headlight switch, brake light transmission mode switch, command engine mode switch

Console

0x0B

19

Table 4.2.2-2 ECU CAN Specifications ECU NAME Cruise Control ABS/Brakes CAN INPUTS cruiseModeMsg vehicleSpeedMsg, pedalMsg vehicleSpeedMsg, shiftMsg, transMsg, engineMsg cruiseAccelMsg, cruiseModeMsg, TracMsg CAN OUTPUTS cruiseAccelMsg, vehicleSpeedMsg wheelSpeedMsg, ABSMsg, TracMsg, brakesAppliedMsg

Transmission

transMsg

Pedals Steering Engine Cabin Control

pedalMsg, cruiseModeMsg cruiseModeMsg, shiftMsg, steeringMsg engineMsg tempMsg, tempRefMsg

accMsg

Differential Console

ABSMsg, vehicleSpeedMsg, steeringMsg pedalMsg

diffMsg, yawErrorMsg accMsg, transMode, engineMsg

Design Decisions: For individual ECU implementations, we chose to use an HCS12 variant (MC9S12C128). The reason of us choosing the HCS12 is due to the fact that Freescale is a leading manufacturer of microcontrollers for vehicle electronics [17]. Most cars employ the use of two or more CAN buses in order to operate. For our purposes, we chose to only use one CAN bus. The HCS12 microcontroller variant that we have does not support more than one CAN bus. If we were to use two CAN buses for our design, some ECUs would be isolated from others, preventing them from communicating with each other.

20

Figure 4.3.2-1 ECU Network Spec

CAN Network: The CAN network itself consisted of two rails, which were terminated at both ends using 120 Ohm resistors. The onboard CAN controllers on the HCS12 are PCA82C25 physical interfaces. While this controller is rated to support up to 110 nodes, we hit a limit of 10 nodes due to some undetermined characteristic of our implementation. Increasing the resistance of the CAN bus helped with the problem but it was more of a quick fix than a solution. The CAN bus that we ended up using for the system consisted of a single 500Kbits bus that connected with all of the ECUs as well as the middleware layer.

4.2.3 Middleware Layer Subsystem The middleware layer consisted of a standard computer running Ubuntu Linux. As was mentioned earlier, we implemented most of the system on a single board computer but due to performance limitations chose to use a standard laptop for the middleware layer. In order to communicate with the CAN bus, the middleware used a PEAK CAN-USB adapter. Using APIs supplied by PEAK, the CAN-USB adapter converts CAN bus data into a format that is easy to work with.

21

4.3 HARDWARE AND SOFTWARE REQUIREMENTS 4.3.1 Hardware Requirements and Design Approach 4.3.1.1 Simulation Hardware The TORCS simulation required a data I/O method for communicating with the ECU network. The NI DAQ board provided ample digital and analog I/O for this task. Using appropriate send/receive/pack/unpackcode in the TORCS model, the simulated car communicated through the DAQ board. The analog sample rate, 1 kHz, was determined by the complexity of the TORCS model modifications and the amount of ECUs interfaced with the model. The simulation computer needed to be relatively fast (3 GHz, 64-bit, 2GB RAM) in order to effectively compute a car model while sampling from the DAQ board. It also required empty PCI Express slots in order to facilitate the NI DAQ board. 4.3.1.2 ECU Hardware Each ECU was represented by an HCS12 microcontroller (MC9S12C128 variant). The datasheet can be found in the bibliography section, but a short description is included here: 16-bit HCS12 CORE HCS12 CPU MMC (memory map and interface) INT (interrupt control) BDM (background debug mode) DBG12 (enhanced debug12 module including breakpoints and change-of-flow trace buffer) Multiplexed Expansion Bus (available only in 80 pin package version) 16-bit HCS12 CPU Upward compatible with M68HC11 instruction set Interrupt stacking and programmers model identical to M68HC11 Instruction queue Enhanced indexed addressing Wake-up interrupt inputs Up to 10-port bits available for wake up interrupt function Memory options 16K, 32K, 64K, 96K and 128K Byte Flash EEPROM (erasable in 512-byte sectors) or 16K, 32K, 64K, 96K and 128K Byte ROM 2K and 4K Byte RAM Analog-to-Digital Converters One 8-channel module with 10-bit resolution. External conversion trigger capability Up to one 1M bit per second, CAN 2.0 A, B software compatible modules Five receive and three transmit buffers

22

 Flexible identifier filter programmable as 2 x 32 bit, 4 x 16 bit or 8 x 8 bit Four separate interrupt channels for receive, transmit, error and wake-up Low-pass filter wake-up function Loop-back for self test operation Timer Module (TIM) 16-bit Counter with 7-bit Prescaler 8 programmable input capture or output compare channels Simple PWM Mode Modulo Reset of Timer Counter 16-Bit Pulse Accumulator External Event Counting Gated Time Accumulation 6 PWM channels Programmable period and duty cycle 8-bit 6-channel or 16-bit 3-channel Separate control for each pulse width and duty cycle Center-aligned or left-aligned outputs Programmable clock select logic with a wide range of frequencies Fast emergency shutdown input Serial interfaces One asynchronous serial communications interface (SCI) One synchronous serial peripheral interface (SPI)

Communication via CAN was achieved using an onboard PCA82C25 CAN Transceiver. This device supported speeds of up to 1Mbps and supported up to 110 nodes. 4.3.1.3 Middleware Hardware The middleware consisted of a standard computer running Ubuntu Linux as well as a USB to CAN interface: HP Envy 14 PEAK CAN-USB (IPEH-002021) USB to CAN adapter for interfacing with the CAN network

4.3.2 Software Requirements and Design Approach 4.3.2.1 Simulation Software The car simulation required TORCS and appropriate Linux libraries. The NI DAQ board requires the installation of the NI DAQmx driver software.

23

4.3.2.2 ECU Software The individual ECUs ran C code created using the Codewarrior IDE 4.7. The compiler included in the Codewarrior suite was the in-house compiler created by Freescale. 4.3.2.3 Middleware Software The middleware ran on Ubuntu 9.10 (Karmic Koala). Most of the codebase for the middleware was coded in C, using the following APIs: -GTK+ For Dashboard visualization -PEAK CAN for CAN bus communication -Glib2 -Loudmouth API -GNU Plot -Standard C libraries 4.3.3 Interface Control Documents Table 4.3.3-1 details the messages sent between the ECU network and the middleware layer. All messages were unsigned 8-bit integers, unless otherwise noted. The unit TORCS corresponds to TORCS commands being normalized to 1.0, scaled to 100 in our code (e.g. accelCmd=100 corresponds to accel=1.0 in the TORCS code, which is full acceleration).

24

Table 4.3.3-1 CAN Message Descriptions

CAN Message vehicleSpeedMsg pedalMsg.brakeCmd steeringMsg engineMsg.engineRPM engineMsg.fuel engineMsg.fuelmode pedalMsg.accelCmd cruiseModeMsg cruiseAccelMsg shiftMsg transMsg.gear transMsg.shiftmode wheelSpeedMsg.wheelSpeedFL wheelSpeedMsg.wheelSpeedFR wheelSpeedMsg.wheelSpeedRL wheelSpeedMsg.wheelSpeedRR brakesAppliedMsg.FR brakesAppliedMsg.FL brakesAppliedMsg.RR brakesAppliedMsg.RL ABSMsg.FR ABSMsg.FL ABSMsg.RR ABSMsg.RL TracMsg AccMsg Description Vehicle speed Brake pedal Steering angle Engine RPM Engine fuel level Engine mode Accelerator pedal Cruise control mode Cruise control acceleration Manual shift command Transmission gear Transmission Mode Linear wheel speed (FR) Linear wheel speed (FL) Linear wheel speed (RR) Linear wheel speed (RL) Applied brake cmd. (FR) Applied brake cmd. (FL) Applied brake cmd. (RR) Applied brake cmd. (RL) ABS cmd. (FR) ABS cmd. (FL) ABS cmd. (RR) ABS cmd. (RL) Traction control message Console settings CAN ID (.byte) 0x03 0x04 0x05 0x06.1 0x06.2 0x06.3 0x07 0x08 0x09 0x0A 0x0B.1 0x0B.2 0x0C.1 0x0C.2 0x0C.3 0x0C.4 0x0E.1 0x0E.2 0x0E.3 0x0E.4 0x0E.5 0x0E.6 0x0E.7 0x0E.8 0x0F 0x18 Units km/h TORCS proportional proportional L*10 sport/econ TORCS on/off TORCS up/down gear auto/manual km/h km/h km/h km/h TORCS TORCS TORCS TORCS TORCS TORCS TORCS TORCS TORCS Range (Integer) [0,255] [0,100] [10,90] [0,255] [0,255] [0,1] [0,100] [0,1] [0,100] [0,2] [0,7] [0,1] [0,255] [0,255] [0,255] [0,255] [0,100] [0,100] [0,100] [0,100] [0,100] [0,100] [0,100] [0,100] [0,100] Not fully tested bits: b00000(fuel)(brklight)(headlight) fuelmode: 0=sport, 1=economy lights: 0=off, 1=on signed 8 bit signed 8 bit [-127,128] = +/- 2.5 rad/s Notes

[10,90] = +/- 135 degrees [0,255] = 0-9000 RPM 0=sport, 1=economy 1=enabled

0=downshift, 2=upshift Value is current gear +1 0=automatic, 1=manual

DiffMsg YawErrorMsg tempMsg tempRefMsg

Torque split command Yaw rate error Cabin temperature Desired (set) temperature

0x20 0x21 0x22 0x23

N*m proportional deg F * 2 deg F * 2

[-50,50] [-127,128] [0,255] [0,255]

25

4.4 TEST AND DEMONSTRATION While our complete system was modular, with subsystems designed and developed in parallel, many of the test setups consisted of collaboration between two sections, particularly the ECU network and simulation layers. Section 4.4.1 outlines our test paradigms for each of the three layers as well as the interfacing between them. Each layer had a subset of features that were tested. 4.4.1 Test 4.4.1.1 Simulation Subsystem To test the simulation subsystem, we provided input to the TORCS simulation via the ECU network. This was accomplished using an electronic steering wheel and pedal, which were routed to the appropriate ECUs. Oscilloscope measurements of DAQ input/output signals were made in order to ensure: 1. Correlation of TORCS model behavior to user input. 2. Correlation of TORCS model to middleware output (dashboard visualization). Each individual ECU subsystem was first tested (at system rest), followed by testing small subsets of related systems, followed by running a normal simulation attempting to model typical ECU usage. 4.4.1.2 Simulation ECU Network Connection There was an inherent connection between the design and testing of each ECU and its simulated counterpart. Each ECU took inputs from the simulation layer and processed them, after which it sent its own outputs back to the simulation layer for the simulation. The DAQ I/O signals listed in Section 4.2 were measured to ensure they corresponded with the desired input or output. 4.4.1.3 ECU Network All ECUs were tested for common operations, such as CAN send/receive and analog signal I/O. Each ECU had more complex functions that were tested using oscilloscope measurements or verification of CAN data: Pedals ECU: Read pedal signals correctly Report pedal signals correctly

26

Steering ECU: Read steering wheel correctly Report angle correctly Correct button operation ABS/Brakes ECU: Read wheel speed signals correctly Report brake command signals correctly Correct PID controller operation Differential ECU: Read yaw rate error signals correctly Report differential command signals correctly Correct PID controller operation Cruise Control ECU: Read vehicle speed signals correctly Report cruise acceleration signals correctly Correct PID controller operation Cabin Comfort ECU: Read temperature signals correctly Report fan power signals correctly Correct PID controller operation Transmission ECU: Read gear signals correctly Report gear command signals correctly Correct shifting controller operation Console ECU: Read switches correctly Report console signals correctly Engine ECU Read and report fuel and RPM signals correctly

4.4.1.4 ECU-Middleware Connection This interface relied on a functioning CAN protocol. Once this was verified to be working, the rest of the connections between the ECUs and the middleware connectionwere able to be realized realized through CAN messages that can be reliably read.

27

4.4.1.5 Middleware Subsystem The middleware subsystem served to verify the operation of the ECU network and implemented the more complex functions of our system, which are essentially the main goals of the project. Remote Diagnostics The middleware layer was verified to be able to relay messages to the ECUs and receive diagnostic data by checking the data sent over CAN with the data shown on the diagnostics screen. Statistics Gathering The middleware layer was verified to be able to maintain a database locally that stores CAN data for the potential application of analysis by vehicle manufacturers. In order to test this, sample CAN data was sent on the network and verified with data saved in the database. 4.4.2 Demonstration The demonstration consisted of presenting system as it functions as a whole. The different features of AutoPlug were demoed independently to illustrate their functionality. Additionally, real-world scenarios illustrating the use of AutoPlug were demonstrated. These scenarios are detailed in Section 5.4: Overall System.

28

4.5 SCHEDULE

29

30

31

4.5.1 Schedule Discussion Most of the first semester was spent researching about the project and attempting to create proofof-concepts for each of the three subsystems. Once a final design was agreed upon, implementation began at the end of the first semester and continued to the end of the year. Most tasks were completed on schedule. However, there was slip on some tasks due to the expansive nature of this system: some extraneous features needed to be scaled back or removed if time did not permit for their completion. Nevertheless, the main design and implementation goals of AutoPlug were successfully completed by Demo Day.

32

5. RESULTS 5.1 SIMULATION 5.1.1 DAQ/TORCS Integration: The NI DAQ board was integrated into the code base of the TORCS simulation engine. We created the ability in TORCS to query the DAQ board for inputs in order to receive data from the ECU network, as well as to output simulation data to the appropriate ECUs. This was accomplished through the use of the NI DAQmx driver, which is a C API containing functions that control the DAQ board. The TORCS engine was modified in order to support the NI DAQmx libraries.

Figure 5.1.1-1 DAQ/TORCS Integration Software Flow TORCS updates each car state by means of a robot, a segment of code that controls each car (Fig. 5.1.1-1). We modified the robot to use the DAQ board to read and write data to and from the ECU network. We could then provide real-time I/O between TORCS and each ECU. 5.1.2 TORCS Modifications The following modifications to the TORCS code base were implemented in order to increase the functionality of the TORCS simulation: Added support for ECU-controlled active differential Added engine hard shutoff switch for ignition simulation Added support for individual brake commands for ABS (credit to Utsav Drolia, mLab) Modified car visualization model for headlights and brake lights

33

5.2 ECU NETWORK 5.2.1 Controller Implementation Each controller was implemented on a Freescale HSC12 microcontroller. The following sections briefly describe their operations. 5.2.1.1 Cruise Control ECU Pseudocode: 1. Read analog vehicle speed signal. 2. If we have enabled cruise control via the steering wheel: a. Compare to Vref, which corresponds to reference speed. b. Compute output commands using PI feedback. c. Send cruise control signals over CAN. 5.2.1.2 ABS/Brakes ECU Pseudocode: 1. Read analog linear wheel speed signals. 2. If the car is are braking and ABS is enabled: a. Check to see if wheels are slipping. b. If at least one wheel is slipping: i. Compute ABS command using PID feedback. ii. If the ABS has saturated the brake on at least one wheel: 1. Reset all PID controllers (pulsing). c. Else, make sure the PID output is zero. 3. Else, make sure the PID output is zero. 4. Subtract ABS commands off of brake commands and limit to [0,100]. 5. ABS Timeout: a. If we have not enabled ABS in a while: i. Make sure the PID output is zero. 6. Set output brake command PWM signals to corresponding duty cycle. 7. Send all brake data over CAN. 5.2.1.3 Cabin Control ECU Pseudocode: 1. 2. 3. 4. 5. 6. Read analog cabin temperature signal. Read analog desired cabin temperature setting. Calculate temperature error. Compute output commands using PID feedback. Set fan power PWM signal to corresponding duty cycle. Send fan power signal over CAN.

34

5.2.1.4 Console ECU Pseudocode: 1. Read headlight, engine mode, and transmission mode switches. 2. Output headlights and brake lights signals on digital port. 3. Send console signals over CAN. 5.2.1.5 Differential ECU Pseudocode: 1. Read analog yaw rate error signals. 2. If the car is moving fast enough and is turning enough: a. If yaw rate error is large: i. Compute ABS command using PID feedback. b. Else, make sure the PID output is zero. 3. Limit differential message to [0,100] (corresponding to [-50 50]). 4. Set output torque split PWM signal to corresponding duty cycle. 5. Send differential data over CAN. 5.2.1.6 Engine ECU Pseudocode: 1. 2. 3. 4. Read analog engine RPM signal. Read digital fuel level signal on digital port. Echo engine mode signal over CAN. Send engine signals over CAN.

5.2.1.7 Pedals ECU Pseudocode: 1. 2. 3. 4. Read analog pedal signals. If pedals are engaged and cruise control is active, kill cruise control. Else, set cruise control as per CAN message. If cruise control is on: a. Accelerator command = cruise accel. message. b. Brake command = -(cruise accel.) if (cruise accel)<0; 5. Else, accel. and brake commands are pedal signals. 6. Set accelerator pedal PWM signal to corresponding duty cycle. 7. Send pedal signals over CAN. 5.2.1.8 Steering ECU Pseudocode: 1. 2. 3. 4. Read analog steering angle signal. Parse buttons for shift and/or cruise control signals. Set steering PWM signal to corresponding duty cycle. Send steering shift, and cruise enable signals over CAN.

35

5.2.1.9 Transmission ECU Pseudocode: 1. 2. 3. 4. 5. Read digital gear signals on digital port. Update shift points depending on sport/economy mode. Update transmission mode as per CAN message. Wait for timeout (used to regulate shifting speed). If a shift message has been received and the car is either in manual transmission, in neutral/reverse, or is shifting down from first gear: a. Update gear with shift message. 6. Else, compute gear based on vehicle speed and car parameters. 7. Set gear command signal on digital output port. 8. Send transmission signals over CAN. 5.2.2 Controller Results The following sections give examples of controller operation using data logged by the middleware layer, for the following ECUs which implemented controls algorithms: Cruise Control ABS/Brakes Differential Control Transmission Control Cabin Comfort 5.2.2.1 Cruise Control Results
Cruise Control Operation Speed Cruise Accel. 75 30

50

20

25

10

6 Time (s)

10

12

Figure 5.2.2.1-1 Example Cruise Control Operation 36

Cruise Control Acceleration Command (normalized to 100)

100

Vehicle Speed (km/h)

5.2.2.2 ABS/Brakes Results

ABS/Brake Operation: Vehicle vs. Wheel Speed 200 100 0 Vehicle Wheel (FR)

Speed (km/h)

200 100 0 200 100 0 200 100 0 3 3.5 4 4.5 5 Time (s) 5.5 6 Vehicle Wheel (RL) 6.5 7 Vehicle Wheel (RR) Vehicle Wheel (FL)

Figure 5.2.2.2-1 Example ABS/Brakes Operation: Speed Comparison

ABS/Brakes Operation: Wheel Speed vs. Brake Command

150

75

100

50

50 Wheel Speed (FR) Brake Cmd. (FR) 0 3 3.5 4 4.5 5 Time (s) 5.5 6 6.5

25

0 7

Figure 5.2.2.2-1 Example ABS/Brakes Operation: Brake Pulsing (FR Wheel)

37

Applied Brake Command (normalized to 100)

200

100

Wheel Speed (km/h)

The remaining wheels for this example are given in the Appendix A4-1 5.2.2.3 Differential Control Results
Differential Control Operation

-20

-1

-40

-2

-60

Yaw Rate Error Torque Split 3 4 5 6 Time (s) 7 8

-3

Figure 5.2.2.3-1 Example Differential Control Operation

5.2.2.4 Transmission Control Results

Automatic Transmission Operation Gear Speed

150

6 5

Vehicle Speed (km/h)

100

4 3

50

2 1

6 Time (s)

10

12

Figure 5.2.2.4-1 Example Transmission Operation

38

Transmission Gear

Yaw Rate Error ( rad/s)

Torque Split (N*m)

5.2.2.5 Cabin Control Results Due to limitations of the CAN transceivers regarding maximum node count, we were not able to retrieve the cabin control ECU data over the CAN network without error. However, we implemented a model of the controller in Simulink, the results of which are shown in Appendix A4-3. 5.2.3 CAN Boot-loader The CAN boot-loader was implemented for the purpose of reprogramming ECU firmware through the CAN bus. This allows the middleware to re-flash an ECU after it has been installed on the vehicle. Figure 5.2.3-1 contains the program flow for the bootloader. The bootloader itself sits in high memory (0xF000 and above). The boot loader accepts the following messages: JMP to Boot message: LEN:2 ID:2 MSG: [ECUID 0x03] Instruction message: LEN: 8 ID:1 MSG: [ADDRH ADDRL INS1 INS2 INS3 INS4 INS5 INS6] Jump out of Boot message: LEN 8 ID:1 MSG: [0 0 0 0 0 0 0 0]

The ECU code is reprogrammed starting at 0xC000. The program also rewrites the interrupt table which is at the last block of memory 0xFDFF and above.

39

Boot-Loader Starts at 0xF300 Initialize CAN, Disable Interrupts

Check to see if code already written (Flag at 0xEFFE)

Y e s

N O

Erase Flash Blocks (0xC000 0xEF00) Erase Interrupt Block: (0xFDFF)

Send middleware ACK message

Wait for message from Middleware

Is message all 0s?

Yes

Jump to Program (JMP 0xC000)

N O
Write to Flash. Bytes 0-1 = Address Bytes 2-7 = Instructions

Figure 5.2.3-1 CAN Bootloader Flow 5.2.4 Hardware Diagrams The complete system can be rebuilt by putting together the blocks found in the appendix. Please refer to appendix A2 for all of the diagrams, including the auxiliary circuit diagrams as well as a diagram of the whole system in figure A2-14. The whole system diagram is meant to be a high

40

level description of the system, meaning that the wires do not represent single wires but simply directions of communication. Refer to the individual blocks for all of the connections. For brevity, only one controller is discussed here. Figure 5.2.4 -1 shows the hardware diagram of the differential controller:

5V
Pin 1 Vaux CAN_H RAIL CAN_L RAIL

CAN HIGH CAN LOW

Pin 18 A/D 0

YAW_ERR FROM TORCS

10 uF

Pin 30 PWM2

DIFF OUT (RC_IN) TO TORCS

HCS12
Pin 3 GND

5.2.4-1 Differential ECU The ECUs can get two types of inputs from TORCS, analog or digital. Analog inputs are filtered using a 10 uF capacitor in order to smooth out the signal. These can be read directly into the A/D port of the microcontroller. Digital inputs can be read directly into any of the digital ports of the HCS12. In order to output back to TORCS, there can be either digital outputs or PWM outputs. Digital outputs need no conversion, but PWM outputs need to be converted to analog in order to be read it by the DAQ. The conversion is performed by an RC filter and a voltage follower. The schematics for these can be found in Appendix A2. Virtually all of our PWM outputs need to be processed through the RC filter for TORCS to read them. The actual peripherals we use are simple enough that we could interface them with the ECUs without much conversion, with the exception of the steering wheel. The pedals were two 100K Ohm potentiometers that allowed us to read a variable voltage as the individual pedal was pressed. This is read in by the ECU through an A/D port. The steering wheel is a similar circuit, but instead of giving out variable voltage, it gave out variable current. This meant that we had to interface it though a 555 timer in order to read it in to the ECU. The 555 timer outputs a PWM signal with a variable duty cycle that depends on the time it takes a capacitor attached to the steering wheel to charge. The way this works is that a reset signal is sent by the ECU every 41

700Hz, discharging the capacitor. The variable current from the steering wheel then charges the capacitor and the 555 timer outputs a square wave the displays this time, once the capacitor discharges, the process starts again. This allows us to read in the steering angle by reading in the duty cycle of the square wave. 5.3 MIDDLEWARE 5.3.1 Visualizations In order to verify the operation of the ECU network as well as provide some visual feedback for the middleware layer, a dashboard was implemented that displayed the vital information of the vehicle. The data could be visualized through gauges and figures, or it could be displayed in its raw form. This aided us in debugging our system. Figure 5.3.1-1 shows a screenshot of the data visualization of the middleware layer. For other screenshots, please refer to appendix A7 for any additional screenshots.

Figure 5.3.1-1 Visualization 5.3.2 Data Logging Data logging is an option that can be enabled through the diagnostics pane of the Middleware GUI. By enabling this feature, the system will begin storing all of CAN data to a file. This data can later be used to run the same features that middleware provides, such as remote diagnostics and trip visualizations. This is one of the major features of our system as it gives the vehicle manufacturers a wealth of information regarding the vehicles on the road. By analyzing historical data, the manufacturer can alert the user of upcoming tune ups and check-ups, as well as warn the user then there is a problem with the vehicle before anything major happens.

42

Data logs also have the potential to be used to improve future iterations of vehicles. For example, if the vehicle manufacturer determines that the tire pressure sensors in the current line of vehicles seems to fail too often, they can make sure to address this issue in their next model. 5.3.3 ECU Upgrades This feature consists of being able to upgrade an ECU through the CAN bus without having to physically access the ECU. The ECU side of ECU upgrades was described in the CAN Boot loader section (Section 5.2.3). For completeness, the middleware code flow is described here: Control Flow: Send jump to boot loader message LEN:2 ID:2 MSG: [ECUID 0x03] Wait for ACK message: LEN:2 ID:2 MSG:[ECUID 0x01] Send instruction data from BIN file Send Finish (Jump to code) message The middleware reads from a BIN file, which can be extracted from the compiled data that the Codewarrior IDE creates. Figure 5.3.3-1 shows the middleware upgrading the ECU.

Figure 5.3.3-1 Upgrading ABS ECU

43

5.3.4 Diagnostics We implemented diagnostic routines for the ECUs to verify their operation. Through the diagnostics pane, the middleware can run these routines and determine whether an ECU is working correct and incorrectly. For example, the diagnostic routine for the cruise control ECU saves the reference speed, and then compares it to the actual speed. If the actual speed deviates too much from the reference speed, then the ECU is labeled as working incorrectly. Refer to Figure 5.4.1-2 for an example of the cruise control diagnostics window. 5.3.5 Android Application As an additional feature, we also implemented an Android application that shows the data from the vehicle using similar visualizations as can be found in the dashboard pane of the middleware layer. The mobile application also has a small demonstration of how it appear if manufacturers were to push updates to vehicles through users mobile phones. While the upgrade process is simply for demonstration and does not upgrade any ECU in our system, we thought it would illustrate our concept well. Please refer to Appendix A7 for additional screenshots of the Android application. 5.4 OVERALL SYSTEM In addition to completing the individual goals of implementing each of the three layers of AutoPlug, we also accomplished the overall goal of being able to develop and demonstrate applicable scenarios for AutoPlug. 5.4.1 Scenario 1: Broken Cruise Control In this scenario we intentionally flashed the cruise control ECU with pathological software that gave undesired operation. This demonstrated the potential for software errors to be diagnosed and corrected through AutoPlug. When cruise control was enabled, the vehicle erratically attempted to match the desired speed, which was seen in simulation and recorded by the middleware layer (Fig. 5.4.1-1).

44

Speed Cruise Control Command. 100 100

75

50

50

25

-50

-100

6 Time (s)

10

Figure 5.4.1-1 Pathological Cruise Control Operation We were then able to run diagnostics on the middleware layer in order to quantitatively recognize the error (Fig 5.4.1-2).

Figure 5.4.1-2 ECU Diagnostic Info

45

Cruise Control Accel./Brake Command (normalized to +/- 100)

Pathological Cruise Control Operation

Vehicle Speed (km/h)

The user was then able to upgrade the ECU with the correct version of the software. After flashing the new software, the user was able to verify that the cruise control was working correctly (previously shown in Fig. 5.2.2.1-1). 5.4.2 Scenario 2: Broken ABS/Brakes In this scenario we intentionally flashed the ABS/Brakes ECU with pathological software that gave undesired operation. This demonstrated the ability of AutoPlug to diagnose any node on the ECU network. When the user quickly engaged brakes at high speed, the vehicle applied the brakes incorrectly, causing the wheels to lock and the car to violently spin around, which was seen in simulation and recorded by the middleware layer (Fig. 5.4.2-1).
Pathological ABS/Brakes Operation: Vehicle Vs. Wheel Speed 100 50 0 Vehicle Wheel (FR)

Speed (km/h)

100 50 0 100 50 0 100 50 0 2 2.5 3 3.5 Time (s) 4 4.5 Vehicle Wheel(RL) 5 Vehicle Wheel (RR) Vehicle Wheel (FL)

Figure 5.4.2-1 Pathological ABS/Brakes Operation

More graphs of pathological ECU operation can be found in Appendix A4.2. We were then able to run diagnostics on the middleware layer in order to quantitatively recognize the error, similar to Fig 5.4.1-2. The user then upgraded the ECU with the correct version of the software. After flashing the new software, the user was able to verify that the ABS/Brakes ECU was working correctly (previously shown in Fig. 5.2.2.2-1).

46

6. LESSONS LEARNED It is very important to know the limitations of hardware and software tools that one may use to complete a project, particularly before any designs are finalized. During our implementation of the ECU network as well as the simulation, we ran into a few problems that were caused by our ignorance of the limitations of our devices. The DAQ boards we used only had a set number of analog inputs, so we were not able to export as many physics outputs from TORCS as we had hoped. Another instance of this came with the onboard CAN transceivers that we used with our HCS12 variant. Due to the quality of the transceivers, coupled with the inexpensive components we were using, the CAN bus that we implemented had a limit of about 10 nodes before the signals attenuated too much for the nodes to send messages. When working in an inter-disciplinary team, make sure that interface documents are in a language that everyone can understand. Describing details that two parties need to be aware of in vague terms leads to confusion and sometimes leads to perform tasks over again. This is also true when working with people that have differing work methodology. Interface documents serve to not only keep different parts of a project consistent with the overall system, but to also allow different members of the team to work independently without constant collaboration. This lets every member work at their own pace. Address the difficult problems early. If a feature is the cornerstone of the whole project (such as ECU Firmware Upgrades was for ours), it should be approached with enough time implement or allow for alternative solutions. We waited way too long to address this feature and we were fortunate to have completed it in time.

47

7. EQUIPMENT NEEDS Most of the equipment we needed was available from our advisors lab (the mLab) as well as the Detkin Lab. A few items were purchased from different vendors for a better user experience and practicality. Please refer to section 12 (Financial Information) for a full list of items.

48

8. CONCLUSIONS AND RECOMMENDATIONS Overall, we felt the project was successful and that the goals that we met were accomplished thoroughly. However, removing some of our limitations could have made our project even better. For example, we wanted the automobile model to be more robust and support more features, but due to time constraints and limitations of our simulation and hardware, we could not meet this goal. We did meet the goals that we set out to complete in our first proposal. If the project were to be redone, we would not have done it any differently, as we feel our system met the specifications we set out to meet. 1. We learned how to work in a team of different disciplines and work styles. 2. Vehicle electronics are complex systems. The amount of electronic states increases drastically for each ECU that is added. This makes ECU design very difficult and hard to debug. 3. Our system was mostly limited hardware and our simulation. A more extensive and specific simulator would have allowed us to create more realistic systems, but due to price constraints, this was not possible. 4. Issues of privacy and security are big problems that need to be addressed for a project such as this. This is the reason projects like AutoPlug havent come to fruition in a corporate setting. 5. For the future, the backend that the manufacturers could use to access AutoPlug could be implemented. 6. Fleet management is a big issue. We were not concerned with how AutoPlug would scale in a realistic setting. More work could be done in implementing a way for vehicle manufacturers to deploy AutoPlug to the market. If this project were to continue, we recommend that the people work working on this project focus on these areas: Security/privacy Real-time systems and control Higher-fidelity simulation

49

9. NOMENCLATURE ABS Anti-lock Braking System API Application Programming Interface BeagleBoard a small, single board computer C Programming Language CAN Controller Area Network DAQ Data Acquisition ECU Electronic Control Unit ESC Electronic Stability Control GUI Graphical User Interface MATLAB Matrix Laboratory; numerical linear algebra computation suite OBD On-Board Diagnostics OEM Original Equipment Manufacturer OMAP3- Open Multimedia Platform, a computer architecture for mobile and low powered devices. Open Source A software paradigm that promotes openness and transparency in code. OSEK a real-time operating system used in car electronics PID Proportional + Integral + Derivative PWM Pulse Width Modulation RTOS Real-Time Operating System Simulink control systems/signal processing simulation and design suite Ubuntu Linux distribution

50

10. REFERENCES [1] (2010, March 2). Ford, GM lead in U.S. auto recalls 2005-2009, p.1. Retrieved from http://www.reuters.com/article/idUSN0218660120100303 [2] J. Erjavec, Automotive Technology: A Systems Approach. United States: Thompson Delmar Learning, 2004. [3] R. Charette. (2010, Feb. 5). This Car Runs on Code. Discovery News, p.1. Retrieved November 5, 2010, from http://news.discovery.com/tech/toyota-recall-software-code.html [4] N.V. (2010, May 16). Tech.View: Cars and software bugs. The Economist, p. 1. Retrieved November 3, 2010, from http://www.economist.com/blogs/babbage/2010/05/techview_cars_and_software_bugs [5] W. Voss, A Comprehensible Guide to Controller Area Network. Greenfield, MA: Copperhil Media, 2005. [6] (2010, June 8). Chrysler recalls more than half a million vehicles. Newsome Law Firm, p.1. Retrieved from http://www.newsomelaw.com/blog/2010/06/08/chrysler-recalls-more-halfmillion-vehicles [7] K. Koscher, et al., Experimental security analysis of a modern automobile, in Symposium on Security and Privacy, Oakland, California, 2010. [8] H. Heinecke, Automotive Open System Architecture An Industry-wide Initiative to Manage the Complexity of Emerging Automotive E/E-Architectures, Society of Automotive Engineers World Congress, Detroit, Michigan, 2004. [9] I.J.M. Besselink, Vehicle dynamics analysis using SimMechanics and TNO Delft-Tyre, TNO Automotive - Eindhoven University of Technology, The Netherlands, 2006. [10] A. R. W. Huang and C. Chen, A Low-Cost Driving Simulator for Full Vehicle Dynamics Simulation. IEEE Transactions on Vechicular Technology, vol. 52, no. 1, January 2003, pp. 162-172. [11] T. Kinjawadekar, Model-based Design of Electronic Stability Control System for Passenger Cars Using CarSim and Matlab-Simulink, Masters Thesis in Mechanical Engineering at Ohio State University, 2009. [12] M. Chunyang, S. Lining, D. Zhijiang, and C.Yanchun, Research and Development of Device for Downloading and Updating Software of Product ECU based on Extended CCP, Robot Research Institute, Harbin, China, May 2007. [13] D. Xue, X. Yin, and L. Li, Software Architecture for the ECU of Automated Manual

51

Transmission, College of Mechanical and Automotive Engineering, Hunan University, Chengdu, China, June 2010. [14] H. Bischof, B. Donhauser, and K. Meder, The ECU of a Rear Wheel Steering System, London, UK, Oct. 1991. [15] G. Raravi, K. Ramamritham, and N. Sharma, Real-time Data Services for Automotive Applications,, Bombay, India, June 2007. [16] S. Seo, S. Lee, S. Hwang, and J.W. Jeon, Analysis of Task Switching Time of ECU Embedded System Ported to OSEK(RTOS), Suwon, Korea, Oct. 2006. [17] Corporate Overview. Retrieved from http://www.freescale.com/webapp/sps/site/overview.jsp?code=CORPORATE_OVERVIEW

52

11. BIBLIOGRAPHY D. Assanis et al., Validation and Use of SIMULINK Integrated, High Fidelity, Engine-InVehicle Siimulation of the International Class VI Truck, Automotive Research Center, University of Michigan, Tech. Rep. 2000-01-0288, March 2000. M. Burress, Torque vectoring, Lotus International. BeagleBoard Datasheet. Retrieved from www.beagleboard.org C. Lin et al., Integrated, Feed-Forward Hybrid Electric Vehicle Simulation in SIMULINK and its Use or Power Management Studies, Automotive Research Center, University of Michigan, Tech. Rep. 2001-01-1334, January 2001. MC9S12C128 Datasheet. Retrieved from http://www.datasheetpro.com/7054_view_MC9S12C128_datasheet.html MCP2551 Datasheet. Retrieved from http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf K. Sawase et.al, Development of Central-Differential Control Sytem for High-Performance Four-Wheel-Drive Vehicles, Mitsubishi Motors Technical Review (2001, no. 13). G. Smid, K. Cheok and K. Kobayashi, Modeling of Vehicle Dynamics using Matrix-Vector Oriented Calculation in Matlab, in CAINE 1996 ( ISCA, Orlando FL, Dec. 1996, pp 115-120). B. Wall, Development and analysis of a vehicle model in SimMechanics for Formula Student, Eindhoven University of Technology, The Netherlands, Tech Rep. 2005.68, May 2005.

53

12. FINANCIAL INFORMATION As stated earlier, most components that are necessary for this project are available in the mLab. We purchased a steering wheel and a set of pedals to improve the usability of our system. We also purchased some generic printed circuit boards to set up our circuits for demonstration. All of the HCS12s used as ECUs were provided to us by the Detkin Lab and the computers we used were either personal computers or Professor Mangharams. At the beginning of the project, we also purchased several CAN transceivers that we did not end up using due to the usability of the CAN transceivers already available on the HCS12 boards. Interact V3 Racing Wheel and Pedals $27 JAMECO PCBs $24 MCP2551 CAN Transceivers $28 Total: $79

54

13. ETHICS The concept behind AutoPlug consisted of aiding vehicle manufacturers in their ability to deal with recalls as well as unavoidable software errors. AutoPlug is a platform that could be used for designing automobiles in the future and therefore it inherited most ethical issues of automotive design. Most of the issues have already been addressed due to the existence and availability of vehicles today and thus they do not need to be addressed by our system. 13.1 DESCRIPTION OF LARGER CONTEXT Assuming that AutoPlug is adopted and adapted by the vehicle manufacturers in order to design new vehicles, the major ethical components that were not addressed by our system design were that of privacy and security in our system. Because our system was an open architecture and gave access to the software manufacturer to analyze and alter the internal operation of the vehicle, certain precautions need to be taken into account to address the problems of abuse of this data as well as the possibility of unwanted tampering of the vehicle by an intruder. 13.2 ANALYSIS OF ETHICAL ISSUES A user of AutoPlug would have to be protected against privacy intrusions such as the use of their automobile data in advertising, personal data mining or even government issues. The user must be informed of the full extent of what their vehicle data will be used for. On the same note, the user should be protected against unwanted intrusions by other parties that are not the vehicle manufacturer. Things such as software viruses and hacking become real threats when systems such as ours are adopted. A system like AutoPlug opens up the modern car to dangers that are found in most home computers today, and the final design needs to take these problems into consideration. 13.3 ETHICAL RECOMMENDATIONS For the issue of privacy, we envisioned a subscriber model in which the user could themselves choose to upload data to the manufacturer, and they should be given the ability to classify which data gets uploaded. Personal information, including vehicle location should only be uploaded to the manufacturer by user consent. Security is another problem altogether, and it should be addressed carefully by using accepted methods of security found in critical systems today. High level encryption algorithms as well as secure connections should be used between the vehicles out on the road and the car manufacturers. There should also be security measures built into the ECUs to prevent unwanted attacks on the control units themselves.

55

14. SOFTWARE DOCUMENTATION Please refer to Appendix A1 for our revisions of the pedals ECU.

56

15. APPENDICES
A1 CODE FOR SOFTWARE MODULE PEDALS ..................................................................................................... 58 A2 HARDWARE DIAGRAMS ................................................................................................................................ 107 A3 CONTROL DIAGRAMS ................................................................................................................................... 116 A4 ADDITIONAL GRAPHS ................................................................................................................................... 119 A4.1 EXAMPLE ABS/BRAKES OPERATION ..............................................................................................................119 A4.2 PATHOLOGICAL ABS/BRAKES OPERATION ....................................................................................................121 A4.3 CABIN COMFORT CONTROLLER ....................................................................................................................124 A5 DATASHEETS ................................................................................................................................................. 125 A6 MATHEMATICAL EQUATIONS ....................................................................................................................... 126 A7 ADDITIONAL SCREENSHOTS .......................................................................................................................... 127

57

A1 CODE FOR SOFTWARE MODULE PEDALS /* Title: Pedals - Revision 9 Author: Gabriel Torres and Ross Boczar Date: 4-20-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 4-20-2011 Revision List: Added an output compare to send CAN messages at a set interval - Gabriel Torres Different CAN implementation, slowed down messages - Gabriel Torres Added new CAN functions and bug fixes - Gabriel Torres Bug Fixes on A/D code - Gabriel Torres Bug fixes on Cruise Control - Ross Boczar Added Cruise Control support - Ross Boczar Added CAN code - Gabriel Torres Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres */

#include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128" #include "can.h" #include "autoplug_types.h" #define IDENTIFIER 0x04 #define limit(x,a,b) ((x < a) ? (a) : ((x > b) ? (b) : (x))) unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; int control; int cruiseModeMsg;//receives and sends cruiseMode msg int TracMsg;//receives tracmsg signed int cruiseAccelMsg;//receives cruiseAccel msg PedalMsg pedalMsg;//sends pedalmsg

58

int cruiseEn;//intermediate variable int oldbrake, oldaccel; int FIRMWARE;

//must put in a rountine in CAN to update these void interrupt 38 canrx(void){ short int message[8]; int i =0; int len = CANRXDLR; unsigned int id = 0; id = ((CANRXIDR0) << 3) | ((CANRXIDR1) >> 5); //ID of received message for (i = 0; i < len; i++){ CANMSG[i]= *(&CANRXDSR0+i); } if (id == 0x08){ cruiseModeMsg =CANMSG[0]; } if (id == 0x09){ cruiseAccelMsg = (signed int)(CANMSG[0] -100); } if (id == 0x0F){ TracMsg = CANMSG[0]; } if (id == 0x02){ if (CANMSG[0] == IDENTIFIER){ if (CANMSG[1] == 0x03){ DisableInterrupts; CANRFLG |=1; asm("JMP 0xF300"); } else if (CANMSG[1] == 0x02){ message[0] = IDENTIFIER; message[1] = (FIRMWARE & 0xFF00) >> 8; message[2] = (FIRMWARE & 0x00FF); send_msg(message, 0x02, 3); } } }

59

CANRFLG |= 1; //reset flag }

void interrupt 13 can_control(){ /* SEND CAN MESSAGES HERE */

if (oldbrake != pedalMsg.brakeCmd){ send_msg(&pedalMsg.brakeCmd, 0x0004, 1); oldbrake = pedalMsg.brakeCmd;

} if (oldaccel != pedalMsg.accelCmd){ send_msg(&pedalMsg.accelCmd, 0x0007, 1); oldaccel = pedalMsg.accelCmd; }

TC5 = TCNT + 50000; TFLG1 |= 0x20; }

void can_control_init(void){ TSCR1 |= 0x80; TSCR2 = 0x01; //prescale the timer by 2 TFLG1 |=0x20; TIE |= 0x20; TIOS |= 0x20;//Enable output compare on TC5 TC5 = TCNT + 50000; }

60

void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; } void adc_init(void){ int wait1=10000; int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x10; //1 conversions ATDCTL4=0x00; ATDCTL5=0xB0; }

61

//takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; }

void main( ){ int accel=0; int brake=0; cruiseModeMsg=0;//receives and sends cruiseMode msg cruiseAccelMsg=0;//receives cruiseAccel msg oldaccel = 0; oldbrake =0; TracMsg=0;//traction control pedalMsg.accelCmd=0; pedalMsg.brakeCmd=0;//sends pedalmsg cruiseEn=0;//intermediate variable //Init Functions maxval = 1023; init_CAN(0x0008,0x0009,0x002,0xF); //Accepting cc_mode and cc_accel pwm_init(); adc_init();

62

can_control_init(); FIRMWARE = 0x0101; EnableInterrupts; while(1){

while(!(ATDSTAT0 & 0x80)); //Get Input pedal data accel = ATDDR0/10; brake = ATDDR1/10; //Priority: kill message if (accel>15 || brake>15){ if (cruiseModeMsg || cruiseEn){//If cruise is on and should be killed cruiseModeMsg=0; //KILL cruise cruiseEn=0; send_msg(&cruiseModeMsg, 0x0008, 1); } } else{ //Else, set as normal cruiseEn=cruiseModeMsg; } if(cruiseEn) { //If cruise is on if (cruiseAccelMsg>=0){ accel=cruiseAccelMsg; brake=0; } else { accel=0; brake=-cruiseAccelMsg; } } //Alwys add traction //accel=limit(accel-TracMsg, 0, 100);

63

pedalMsg.brakeCmd = brake; pedalMsg.accelCmd = accel; set_duty(pedalMsg.accelCmd,pedalMsg.brakeCmd);

ATDSTAT0|=0xF0; }

64

/* Title: Pedals - Revision 8 Author: Gabriel Torres and Ross Boczar Date: 4-18-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 4-18-2011 Revision List: Different CAN implementation, slowed down messages - Gabriel Torres Added new CAN functions and bug fixes - Gabriel Torres Bug Fixes on A/D code - Gabriel Torres Bug fixes on Cruise Control - Ross Boczar Added Cruise Control support - Ross Boczar Added CAN code - Gabriel Torres Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres */

#include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128" #include "can.h" #include "autoplug_types.h" #define IDENTIFIER 0x04 #define limit(x,a,b) ((x < a) ? (a) : ((x > b) ? (b) : (x))) unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; int control; int cruiseModeMsg;//receives and sends cruiseMode msg int TracMsg;//receives tracmsg signed int cruiseAccelMsg;//receives cruiseAccel msg PedalMsg pedalMsg;//sends pedalmsg int cruiseEn;//intermediate variable int FIRMWARE;

65

//must put in a rountine in CAN to update these void interrupt 38 canrx(void){ short int message[8]; int i =0; int len = CANRXDLR; unsigned int id = 0; id = ((CANRXIDR0) << 3) | ((CANRXIDR1) >> 5); //ID of received message for (i = 0; i < len; i++){ CANMSG[i]= *(&CANRXDSR0+i); } if (id == 0x08){ cruiseModeMsg =CANMSG[0]; } if (id == 0x09){ cruiseAccelMsg = (signed int)(CANMSG[0] -100); } if (id == 0x0F){ TracMsg = CANMSG[0]; } if (id == 0x02){ if (CANMSG[0] == IDENTIFIER){ if (CANMSG[1] == 0x03){ DisableInterrupts; CANRFLG |=1; asm("JMP 0xF300"); } else if (CANMSG[1] == 0x02){ message[0] = IDENTIFIER; message[1] = (FIRMWARE & 0xFF00) >> 8; message[2] = (FIRMWARE & 0x00FF); send_msg(message, 0x02, 3); } } }

CANRFLG |= 1; //reset flag }

66

void interrupt 8 OC(){ TFLG1 = 0x01; TC0 = TCNT + 10000; control = 1; }

void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; } void adc_init(void){ int wait1=10000;

67

int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x10; //1 conversions ATDCTL4=0x00; ATDCTL5=0xB0; }

//takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; } void timer_init(void){ TSCR1 = 0x80; //Enable Timer TSCR2 = 0x01; //Prescale clock by 2; TIOS = 0x01; TIE = 0x01; TFLG1 = 0x01; TC0 = TCNT + 50000;

68

void main( ){ int accel=0; int brake=0; cruiseModeMsg=0;//receives and sends cruiseMode msg cruiseAccelMsg=0;//receives cruiseAccel msg TracMsg=0;//traction control pedalMsg.accelCmd=0; pedalMsg.brakeCmd=0;//sends pedalmsg cruiseEn=0;//intermediate variable //Init Functions maxval = 1023; init_CAN(0x0008,0x0009,0x002,0xF); //Accepting cc_mode and cc_accel pwm_init(); adc_init(); timer_init(); control = 0; FIRMWARE = 0x0101; EnableInterrupts; while(1){ while(!control){}; control = 0; while(!(ATDSTAT0 & 0x80)); //Get Input pedal data accel = ATDDR0/10; brake = ATDDR1/10; //Priority: kill message if (accel>15 || brake>15){ if (cruiseModeMsg || cruiseEn){//If cruise is on and should be killed cruiseModeMsg=0; //KILL cruise cruiseEn=0; send_msg(&cruiseModeMsg, 0x0008, 1); }

69

} else{ //Else, set as normal cruiseEn=cruiseModeMsg; } if(cruiseEn) { //If cruise is on if (cruiseAccelMsg>=0){ accel=cruiseAccelMsg; brake=0; } else { accel=0; brake=-cruiseAccelMsg; } } //Alwys add traction //accel=limit(accel-TracMsg, 0, 100);

if (pedalMsg.accelCmd != accel || pedalMsg.brakeCmd != brake){ set_duty(accel,brake); if (pedalMsg.accelCmd != accel) { send_msg(&accel, 0x0007, 1); } if (pedalMsg.brakeCmd != brake){ send_msg(&brake, 0x0004, 1); } pedalMsg.brakeCmd = brake; pedalMsg.accelCmd = accel; } ATDSTAT0|=0xF0; }

70

/* Title: Pedals - Revision 7 Author: Gabriel Torres and Ross Boczar Date: 4-10-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 4-10-2011 Revision List: Added new CAN functions and bug fixes - Gabriel Torres Bug Fixes on A/D code - Gabriel Torres Bug fixes on Cruise Control - Ross Boczar Added Cruise Control support - Ross Boczar Added CAN code - Gabriel Torres Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres */ #include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128" #include "autoplug_types.h" #define limit(x,a,b) ((x < a) ? (a) : ((x > b) ? (b) : (x))) unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; int cruiseModeMsg=0;//receives and sends cruiseMode msg signed int cruiseAccelMsg=0;//receives cruiseAccel msg PedalMsg pedalMsg={0,0};//sends pedalmsg

//must put in a rountine in CAN to update these void interrupt 38 canrx(void){ unsigned int received = 0; unsigned long id = 0; id = ((CANRXIDR0) << 3) | ((CANRXIDR1) >> 5); //ID of received message

71

received = CANRXDSR0; //Received message, only one byte at the moment. if (id == 0x08){ cruiseModeMsg = received; } if (id == 0x09){ cruiseAccelMsg = (signed int)(received -100); }

CANRFLG |= 1; //reset flag } int cruiseEn=0;//intermediate variable

//init_CAN function, specify 4 IDs to accept, if less than 4, replace with 0. void init_CAN(long int id1, long int id2, long int id3, long int id4){ CANCTL1_CANE = 1; // Enable CAN module CANCTL0_INITRQ = 1; // Request initialization mode while(!CANCTL1_INITAK) ; // Wait until initialization mode is entered CANCTL1 = 0x80; CANBTR0 = 0xC0; CANBTR1 = 0x23; CANIDAC = 0x10; // Enable CAN, OSCCLK as CAN clock // SJW = 4, Prescaler = 4 // Tseg1 = 4, Tseg2 = 3 can rate: 500kbits // 16-bit filter mode 4 acceptance IDs

//Filter 1 CANIDAR0 = (id1 & 0xFFF8) >> 3; CANIDAR1 = (id1 & 0x0007) << 5; //Filter 2 CANIDAR2 = (id2 & 0xFFF8) >> 3; CANIDAR3 = (id2 & 0x0007) << 5; //Filter 3 CANIDAR4 = (id3 & 0xFFF8) >> 3; CANIDAR5 = (id3 & 0x0007) << 5; //Filter 4 CANIDAR6 = (id4 & 0xFFF8) >> 3; CANIDAR7 = (id4 & 0x0007) << 5;

72

CANIDMR0 = 0x00; CANIDMR1 = 0x00; CANIDMR2 = 0x00; CANIDMR3 = 0x00; CANIDMR4 = 0x00; CANIDMR5 = 0x00; CANIDMR6 = 0x00; CANIDMR7 = 0x00;

// Set all bits to care

//CANCTL1_LOOPB = 1; // Enable loopback (ONLY FOR TESTING) CANCTL0_INITRQ = 0; // Exit initialization mode while(CANCTL1_INITAK) ; CANRIER |= 1; //enable CAN interrupt } void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; }

73

void adc_init(void){ int wait1=10000; int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x10; //2 conversions ATDCTL4=0x00; ATDCTL5=0xB0; } void send_msg(int msg, long int id){ unsigned char nextcan; nextcan = CANTFLG; CANTBSEL = nextcan;

CANTXIDR0 = (id & 0xFFF8) >> 3; CANTXIDR1 = (id & 0x0007) << 5; CANTXIDR2 = 0x00; CANTXIDR3 = 0x00; CANTXDSR0 = msg; CANTXDLR = 0x01; CANTFLG = CANTBSEL; while( (CANTFLG & nextcan) != nextcan); } //takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10;

74

a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; } void main( ){ int accel=0; int brake=0; //Init Functions maxval = 1023; //init_CAN(0x0008,0x0009,0,0); //Accepting cc_mode and cc_accel pwm_init(); adc_init(); DDRA=0xFF; EnableInterrupts; while(1){

while(!(ATDSTAT0 & 0x80)); //Get Input pedal data accel = ATDDR0/10; brake = ATDDR1/10; //Priority: kill message if (accel>15 || brake>15){ if (cruiseModeMsg || cruiseEn){//If cruise is on and should be killed cruiseModeMsg=0; //KILL cruise cruiseEn=0; send_msg(cruiseModeMsg, 0x0008);

75

} } else{ //Else, set as normal cruiseEn=cruiseModeMsg; } if(cruiseEn) { //If cruise is on if (cruiseAccelMsg>=0){ accel=cruiseAccelMsg; brake=0; } else { accel=0; brake=-cruiseAccelMsg; } }

if (pedalMsg.accelCmd != accel || pedalMsg.brakeCmd != brake){ set_duty(accel,brake); send_msg(accel, 0x0007); send_msg(brake, 0x0004); pedalMsg.brakeCmd = brake; pedalMsg.accelCmd = accel; } ATDSTAT0|=0xF0; }

76

/* Title: Pedals - Revision 6 Author: Gabriel Torres and Ross Boczar Date: 3-30-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 3-30-2011 Revision List: Bug Fixes on A/D code - Gabriel Torres Bug fixes on Cruise Control - Ross Boczar Added Cruise Control support - Ross Boczar Added CAN code - Gabriel Torres Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres */ #include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128" #include "autoplug_types.h" #define limit(x,a,b) ((x < a) ? (a) : ((x > b) ? (b) : (x))) unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; int cruiseModeMsg=0;//receives and sends cruiseMode msg signed int cruiseAccelMsg=0;//receives cruiseAccel msg PedalMsg pedalMsg={0,0};//sends pedalmsg

//must put in a rountine in CAN to update these void interrupt 38 canrx(void){ unsigned int received = 0; unsigned long id = 0; id = ((CANRXIDR0) << 3) | ((CANRXIDR1) >> 5); //ID of received message received = CANRXDSR0; //Received message, only one byte at the moment.

77

if (id == 0x08){ cruiseModeMsg = received; } if (id == 0x09){ cruiseAccelMsg = (signed int)(received -100); }

CANRFLG |= 1; //reset flag } int cruiseEn=0;//intermediate variable

//init_CAN function, specify 4 IDs to accept, if less than 4, replace with 0. void init_CAN(long int id1, long int id2, long int id3, long int id4){ CANCTL1_CANE = 1; // Enable CAN module CANCTL0_INITRQ = 1; // Request initialization mode while(!CANCTL1_INITAK) ; // Wait until initialization mode is entered CANCTL1 = 0x80; CANBTR0 = 0xC0; CANBTR1 = 0x23; CANIDAC = 0x10; // Enable CAN, OSCCLK as CAN clock // SJW = 4, Prescaler = 4 // Tseg1 = 4, Tseg2 = 3 can rate: 500kbits // 16-bit filter mode 4 acceptance IDs

//Filter 1 CANIDAR0 = (id1 & 0xFFF8) >> 3; CANIDAR1 = (id1 & 0x0007) << 5; //Filter 2 CANIDAR2 = (id2 & 0xFFF8) >> 3; CANIDAR3 = (id2 & 0x0007) << 5; //Filter 3 CANIDAR4 = (id3 & 0xFFF8) >> 3; CANIDAR5 = (id3 & 0x0007) << 5; //Filter 4 CANIDAR6 = (id4 & 0xFFF8) >> 3; CANIDAR7 = (id4 & 0x0007) << 5;

78

CANIDMR0 = 0x00; CANIDMR1 = 0x00; CANIDMR2 = 0x00; CANIDMR3 = 0x00; CANIDMR4 = 0x00; CANIDMR5 = 0x00; CANIDMR6 = 0x00; CANIDMR7 = 0x00;

// Set all bits to care

//CANCTL1_LOOPB = 1; // Enable loopback (ONLY FOR TESTING) CANCTL0_INITRQ = 0; // Exit initialization mode while(CANCTL1_INITAK) ; CANRIER |= 1; //enable CAN interrupt } void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; }

79

void adc_init(void){ int wait1=10000; int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x20; //2 conversions ATDCTL4=0x00; ATDCTL5=0xB0; } void send_msg(int msg, long int id){ unsigned char nextcan; nextcan = CANTFLG; CANTBSEL = nextcan;

CANTXIDR0 = (id & 0xFFF8) >> 3; CANTXIDR1 = (id & 0x0007) << 5; CANTXIDR2 = 0x00; CANTXIDR3 = 0x00; CANTXDSR0 = msg; CANTXDLR = 0x01; CANTFLG = CANTBSEL; while( (CANTFLG & nextcan) != nextcan); } //takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10;

80

PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; } void main( ){ int accel=0; int brake=0; //Init Functions maxval = 1023; init_CAN(0x0008,0x0009,0,0); //Accepting cc_mode and cc_accel pwm_init(); adc_init(); EnableInterrupts; while(1){

while(!(ATDSTAT0 & 0x80)); //Get Input pedal data accel = ATDDR0/10; brake = ATDDR1/10; //Priority: kill message if (accel>15 || brake>15){ if (cruiseModeMsg || cruiseEn){//If cruise is on and should be killed cruiseModeMsg=0; //KILL cruise cruiseEn=0; send_msg(cruiseModeMsg, 0x0008); }

81

} else{ //Else, set as normal cruiseEn=cruiseModeMsg; } if(cruiseEn) { //If cruise is on if (cruiseAccelMsg>=0){ accel=cruiseAccelMsg; brake=0; } else { accel=0; brake=-cruiseAccelMsg; } }

if (pedalMsg.accelCmd != accel || pedalMsg.brakeCmd != brake){ set_duty(accel,brake); send_msg(accel, 0x0007); send_msg(brake, 0x0004); pedalMsg.brakeCmd = brake; pedalMsg.accelCmd = accel; } ATDSTAT0|=0xF0; }

82

/* Title: Pedals - Revision 5 Author: Gabriel Torres and Ross Boczar Date: 3-15-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 3-15-2011 Revision List: Bug fixes on Cruise Control - Ross Boczar Added Cruise Control support - Ross Boczar Added CAN code - Gabriel Torres Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres */ #include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128" #include "autoplug_types.h" #define limit(x,a,b) ((x < a) ? (a) : ((x > b) ? (b) : (x))) unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; int cruiseModeMsg=0;//receives and sends cruiseMode msg signed int cruiseAccelMsg=0;//receives cruiseAccel msg PedalMsg pedalMsg={0,0};//sends pedalmsg

//must put in a rountine in CAN to update these void interrupt 38 canrx(void){ unsigned int received = 0; unsigned long id = 0; id = ((CANRXIDR0) << 3) | ((CANRXIDR1) >> 5); //ID of received message received = CANRXDSR0; //Received message, only one byte at the moment.

83

if (id == 0x08){ cruiseModeMsg = received; } if (id == 0x09){ cruiseAccelMsg = (signed int)(received -100); }

CANRFLG |= 1; //reset flag } int cruiseEn=0;//intermediate variable

//init_CAN function, specify 4 IDs to accept, if less than 4, replace with 0. void init_CAN(long int id1, long int id2, long int id3, long int id4){ CANCTL1_CANE = 1; // Enable CAN module CANCTL0_INITRQ = 1; // Request initialization mode while(!CANCTL1_INITAK) ; // Wait until initialization mode is entered CANCTL1 = 0x80; CANBTR0 = 0xC0; CANBTR1 = 0x23; CANIDAC = 0x10; // Enable CAN, OSCCLK as CAN clock // SJW = 4, Prescaler = 4 // Tseg1 = 4, Tseg2 = 3 can rate: 500kbits // 16-bit filter mode 4 acceptance IDs

//Filter 1 CANIDAR0 = (id1 & 0xFFF8) >> 3; CANIDAR1 = (id1 & 0x0007) << 5; //Filter 2 CANIDAR2 = (id2 & 0xFFF8) >> 3; CANIDAR3 = (id2 & 0x0007) << 5; //Filter 3 CANIDAR4 = (id3 & 0xFFF8) >> 3; CANIDAR5 = (id3 & 0x0007) << 5; //Filter 4 CANIDAR6 = (id4 & 0xFFF8) >> 3; CANIDAR7 = (id4 & 0x0007) << 5;

CANIDMR0 = 0x00;

// Set all bits to care

84

CANIDMR1 = 0x00; CANIDMR2 = 0x00; CANIDMR3 = 0x00; CANIDMR4 = 0x00; CANIDMR5 = 0x00; CANIDMR6 = 0x00; CANIDMR7 = 0x00; //CANCTL1_LOOPB = 1; // Enable loopback (ONLY FOR TESTING) CANCTL0_INITRQ = 0; // Exit initialization mode while(CANCTL1_INITAK) ; CANRIER |= 1; //enable CAN interrupt } void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; } void adc_init(void){

85

int wait1=10000; int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x10; //1 conversions ATDCTL4=0x00; ATDCTL5=0xB0; } void send_msg(int msg, long int id){ unsigned char nextcan; nextcan = CANTFLG; CANTBSEL = nextcan;

CANTXIDR0 = (id & 0xFFF8) >> 3; CANTXIDR1 = (id & 0x0007) << 5; CANTXIDR2 = 0x00; CANTXIDR3 = 0x00; CANTXDSR0 = msg; CANTXDLR = 0x01; CANTFLG = CANTBSEL; while( (CANTFLG & nextcan) != nextcan); } //takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8;

86

PWMDTY3 = a_temp & 0x00FF;

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; } void main( ){ int accel=0; int brake=0; //Init Functions maxval = 1023; init_CAN(0x0008,0x0009,0,0); //Accepting cc_mode and cc_accel pwm_init(); adc_init(); EnableInterrupts; while(1){

while(!(ATDSTAT0 & 0x80)); //Get Input pedal data accel = ATDDR0/10; brake = ATDDR1/10; //Priority: kill message if (accel>15 || brake>15){ if (cruiseModeMsg || cruiseEn){//If cruise is on and should be killed cruiseModeMsg=0; //KILL cruise cruiseEn=0; send_msg(cruiseModeMsg, 0x0008); } }

87

else{ //Else, set as normal cruiseEn=cruiseModeMsg; } if(cruiseEn) { //If cruise is on if (cruiseAccelMsg>=0){ accel=cruiseAccelMsg; brake=0; } else { accel=0; brake=-cruiseAccelMsg; } }

if (pedalMsg.accelCmd != accel || pedalMsg.brakeCmd != brake){ set_duty(accel,brake); send_msg(accel, 0x0007); send_msg(brake, 0x0004); pedalMsg.brakeCmd = brake; pedalMsg.accelCmd = accel; } ATDSTAT0|=0xF0; }

88

/* Title: Pedals - Revision 4 Author: Gabriel Torres and Ross Boczar Date: 2-16-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 2-16-2011 Revision List: Added Cruise Control support - Ross Boczar Added CAN code - Gabriel Torres Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres */

#include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128" #include "autoplug_types.h" unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; int cruiseModeMsg=0;//receives and sends cruiseMode msg signed int cruiseAccelMsg=0;//receives cruiseAccel msg PedalMsg pedalMsg={0,0};//sends pedalmsg //must put in a rountine in CAN to update these void interrupt 38 canrx(void){ unsigned int received = 0; unsigned long id = 0; id = ((CANRXIDR0) << 3) | ((CANRXIDR1) >> 5); //ID of received message received = CANRXDSR0; //Received message, only one byte at the moment. if (id == 0x08){ cruiseModeMsg = received;

89

} if (id == 0x09){ cruiseAccelMsg = (signed int)(received -100); }

CANRFLG |= 1; //reset flag } int cruiseEn=0;//intermediate variable

//init_CAN function, specify 4 IDs to accept, if less than 4, replace with 0. void init_CAN(long int id1, long int id2, long int id3, long int id4){ CANCTL1_CANE = 1; // Enable CAN module CANCTL0_INITRQ = 1; // Request initialization mode while(!CANCTL1_INITAK) ; // Wait until initialization mode is entered CANCTL1 = 0x80; CANBTR0 = 0xC0; CANBTR1 = 0x23; CANIDAC = 0x10; // Enable CAN, OSCCLK as CAN clock // SJW = 4, Prescaler = 4 // Tseg1 = 4, Tseg2 = 3 can rate: 500kbits // 16-bit filter mode 4 acceptance IDs

//Filter 1 CANIDAR0 = (id1 & 0xFFF8) >> 3; CANIDAR1 = (id1 & 0x0007) << 5; //Filter 2 CANIDAR2 = (id2 & 0xFFF8) >> 3; CANIDAR3 = (id2 & 0x0007) << 5; //Filter 3 CANIDAR4 = (id3 & 0xFFF8) >> 3; CANIDAR5 = (id3 & 0x0007) << 5; //Filter 4 CANIDAR6 = (id4 & 0xFFF8) >> 3; CANIDAR7 = (id4 & 0x0007) << 5;

CANIDMR0 = 0x00; CANIDMR1 = 0x00; CANIDMR2 = 0x00; CANIDMR3 = 0x00;

// Set all bits to care

90

CANIDMR4 = 0x00; CANIDMR5 = 0x00; CANIDMR6 = 0x00; CANIDMR7 = 0x00; //CANCTL1_LOOPB = 1; // Enable loopback (ONLY FOR TESTING) CANCTL0_INITRQ = 0; // Exit initialization mode while(CANCTL1_INITAK) ; CANRIER |= 1; //enable CAN interrupt } void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; } void adc_init(void){ int wait1=10000; int wait2=1000; ATDCTL2=0x80;

91

while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x10; //1 conversions ATDCTL4=0x00; ATDCTL5=0xB0; } void send_msg(int msg, long int id){ unsigned char nextcan; nextcan = CANTFLG; CANTBSEL = nextcan;

CANTXIDR0 = (id & 0xFFF8) >> 3; CANTXIDR1 = (id & 0x0007) << 5; CANTXIDR2 = 0x00; CANTXIDR3 = 0x00; CANTXDSR0 = msg; CANTXDLR = 0x01; CANTFLG = CANTBSEL; while( (CANTFLG & nextcan) != nextcan); } //takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

92

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; } void main( ){ int accel=0; int brake=0; //Init Functions maxval = 1023; init_CAN(0x0008,0x0009,0,0); //Accepting cc_mode and cc_accel pwm_init(); adc_init(); EnableInterrupts; while(1){

while(!(ATDSTAT0 & 0x80)); //Get Input pedal data accel = ATDDR0/10; brake = ATDDR1/10; //Priority: kill message if (accel>15 || brake>15){ if (cruiseModeMsg || cruiseEn){//If cruise is on and should be killed cruiseModeMsg=0; //KILL cruise cruiseEn=0; send_msg(cruiseModeMsg, 0x0008); } } else{ //Else, set as normal cruiseEn=cruiseModeMsg; }

93

if(cruiseEn) { //If cruise is on if (cruiseAccelMsg>=0){ accel=cruiseAccelMsg; brake=0; } else { accel=0; brake=-cruiseAccelMsg; } }

if (pedalMsg.accelCmd != accel || pedalMsg.brakeCmd != brake){ set_duty(accel,brake); send_msg(accel, 0x0007); send_msg(brake, 0x0004); pedalMsg.brakeCmd = brake; pedalMsg.accelCmd = accel; } ATDSTAT0|=0xF0; } } /* Title: Pedals - Revision 3 Author: Gabriel Torres and Ross Boczar Date: 1-30-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 1-30-2011 Revision List: Added CAN code - Gabriel Torres Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres */

#include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */

94

#pragma LINK_INFO DERIVATIVE "mc9s12c128"

unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; unsigned long int carspeed; int accel; int oldaccel; int oldbrake; int controlOutput; int error; int errInteg; int brake; int carSpeed=0; int cc_set=0; //0 for pedal, 1 for CAN via cc int cc_acc=0; //cruise control acc int cc_kill=0; //kill cruise control void init_CAN(void){ CANCTL1_CANE = 1; // Enable CAN module CANCTL0_INITRQ = 1; // Request initialization mode while(!CANCTL1_INITAK) ; // Wait until initialization mode is entered CANCTL1 = 0x80; CANBTR0 = 0xC0; CANBTR1 = 0x23; CANIDAC = 0x10; CANIDMR0 = 0xFF; CANIDMR1 = 0xFF; CANIDMR2 = 0xFF; CANIDMR3 = 0xFF; CANIDMR4 = 0xFF; CANIDMR5 = 0xFF; CANIDMR6 = 0xFF; CANIDMR7 = 0xFF; // Enable CAN, OSCCLK as CAN clock // SJW = 4, Prescaler = 4 // Tseg1 = 4, Tseg2 = 3 can rate: 500kbits // 16-bit filter mode // All bits "don't care" (accept all messages)

//CANCTL1_LOOPB = 1; // Enable loopback (ONLY FOR TESTING)

95

CANCTL0_INITRQ = 0; // Exit initialization mode while(CANCTL1_INITAK) ; }

void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; } void adc_init(void){ int wait1=10000; int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x10; //1 conversions ATDCTL4=0x00;

96

ATDCTL5=0xB0; } void send_msg(int msg, long int id){ unsigned char nextcan; nextcan = CANTFLG; CANTBSEL = nextcan;

CANTXIDR0 = (id & 0xFFF8) >> 3; CANTXIDR1 = (id & 0x0007) << 5; CANTXIDR2 = 0x00; CANTXIDR3 = 0x00; CANTXDSR0 = msg; CANTXDLR = 0x01; CANTFLG = CANTBSEL; while( (CANTFLG & nextcan) != nextcan); }

/* int receive_msg(long int *identifier, int *buffer) { unsigned int i; unsigned int length; unsigned int *rxPtr; if(!CANRFLG_RXF) // If data received return -1;

//CAN RECEIVE FUNCTION

*identifier = (CANRXIDR0 << 3) + (CANRXIDR1 >> 5); length = CANRXDLR & 0x0F; rxPtr = &CANRXDSR0; for(i = 0; i < length; i++) { buffer[i] = *rxPtr; rxPtr++;

97

} CANRFLG_RXF = 1; // Reset the flag return length; } */ //takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; } void main( ){ maxval = 1023; init_CAN(); pwm_init(); adc_init(); DDRA= 0xFF; oldaccel = 10; oldbrake = 10; EnableInterrupts;

while(1){

98

while(!(ATDSTAT0 & 0x80));

//Input pedal data accel=ATDDR0/10; brake = ATDDR1/10;

if (oldaccel != accel || oldbrake != brake){ set_duty(accel,brake); send_msg(accel, 0x0007); send_msg(brake, 0x0004); oldbrake = brake; oldaccel = accel; } ATDSTAT0|=0xF0; }

99

/* Title: Pedals - Revision 2 Author: Gabriel Torres and Ross Boczar Date: 1-17-2011 Description: Generate a PWM signal based on a potentiometer input from pedals

Backed Up to Dropbox, 1-17-2011 Revision List: Added Brake - Gabriel Torres Initial Implementation - Gabriel Torres

*/

#include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128"

unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval; unsigned long int data; unsigned long int carspeed; int accel; int oldaccel; int oldbrake; int controlOutput; int error; int errInteg; int brake; int carSpeed=0;

void pwm_init(void){

100

TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; PWMDTY4=(brk_duty & 0xFF00)>>8; PWMDTY5=brk_duty & 0x00FF; PWMPER4=(period & 0xFF00)>>8; PWMPER5=period & 0x00FF; PWME=0xFF; } void adc_init(void){ int wait1=10000; int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; } ATDCTL3=0x10; //1 conversions ATDCTL4=0x00; ATDCTL5=0xB0; }

//takes 1-100 void set_duty(unsigned int a_dty, unsigned int b_dty){

101

unsigned long int a_temp = period; unsigned long int b_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

//Output range b_dty=b_dty*80/100+10; b_temp = b_dty*(period/10)/10; PWMDTY4 = (b_temp & 0xFF00) >>8; PWMDTY5 = b_temp & 0x00FF; } void main( ){ maxval = 1023; init_CAN(); pwm_init(); adc_init(); DDRA= 0xFF; oldaccel = 10; oldbrake = 10; EnableInterrupts;

while(1){ while(!(ATDSTAT0 & 0x80));

//Input pedal data accel=ATDDR0/10; brake = ATDDR1/10;

102

if (oldaccel != accel || oldbrake != brake){ set_duty(accel,brake); oldbrake = brake; oldaccel = accel; } ATDSTAT0|=0xF0; }

} /* Title: Pedals - Revision 1 Author: Gabriel Torres and Ross Boczar Date: 12-17-2010 Description: Generate a PWM signal based on a potentiometer input

Backed Up to Dropbox, 12-17-2010 Revision List: Initial Implementation - Gabriel Torres

*/

#include <hidef.h> /* common defines and macros */ #include <MC9S12C128.h> /* derivative information */ #pragma LINK_INFO DERIVATIVE "mc9s12c128"

unsigned int period; unsigned int acc_duty; unsigned int brk_duty; unsigned int maxval;

103

unsigned long int data; unsigned long int carspeed; int accel; int oldaccel; int oldbrake; int controlOutput; int error; int errInteg; int brake; int carSpeed=0;

void pwm_init(void){ TSCR1=0x80;//enable timer DDRP=0xFF; //output pwm PWMCTL=0x60; //concatenate channels 2&3, 4&5 PWMPRCLK=0x00;//prescale by 64 PWMCLK=0x00;//use clock A/B PWMPOL=0xFF;// polarity PWMCAE=0xFF;//align period=1000; //1 khz acc_duty=50; //5% brk_duty=50; //5% //Set initial pwm and period PWMDTY2=(acc_duty & 0xFF00)>>8; PWMDTY3=acc_duty & 0x00FF; PWMPER2=(period & 0xFF00)>>8; PWMPER3=period & 0x00FF; } void adc_init(void){ int wait1=10000; int wait2=1000; ATDCTL2=0x80; while(wait1--){ while(wait2--); wait2=10; }

104

ATDCTL3=0x10; //1 conversions ATDCTL4=0x00; ATDCTL5=0xB0; }

//takes 1-100 void set_duty(unsigned int a_dty){

unsigned long int a_temp = period; //Output range a_dty=a_dty*80/100+10; a_temp = a_dty*(period/10)/10; PWMDTY2 = (a_temp & 0xFF00) >>8; PWMDTY3 = a_temp & 0x00FF;

} void main( ){ maxval = 1023; pwm_init(); adc_init(); DDRA= 0xFF; oldaccel = 10; EnableInterrupts;

while(1){ while(!(ATDSTAT0 & 0x80));

105

//Input pedal data accel=ATDDR0/10;

if (oldaccel != accel){ set_duty(accel); oldaccel = accel; } ATDSTAT0|=0xF0; }

106

A2 HARDWARE DIAGRAMS

5V
Pin 1 Vaux CAN_H RAIL CAN_L RAIL CAN HIGH CAN LOW
Pin 13 PT0 Pin 15 PT1 Pin 30 PWM2 555 TMR OUT CC_ON (BTN1) 555 TMR RESET STEERING OUT (RC_IN) TO TORCS CC_OFF (BTN2) SHIFT_UP (BTN3) SHIFT_DN (BTN4)

HCS12

Pin 36 PWM5 Pin 50 PT2 Pin 52 PT3 Pin 54 PT4

Pin 3 GND

Figure A2-1 STEERING ECU

5V
Pin 1 Vaux CAN_H RAIL CAN_L RAIL CAN HIGH CAN LOW Pin 18 A/D0 SPEED FROM TORCS 10 uF

HCS12

Pin 3 GND

Figure A2-2 CRUISE CONTROL ECU

107

5V
Pin 1 Vaux CAN_H RAIL CAN_L RAIL

CAN HIGH CAN LOW

Pin 18 A/D 0

10 uF

YAW_ERR FROM TORCS

Pin 30 PWM2

HCS12
Pin 3 GND

DIFF OUT (RC_IN) TO TORCS

Figure A2-3 DIFFERENTIAL CONTROL ECU

5V
Pin 1 Vaux
CAN_H RAIL CAN_L RAIL
CAN HIGH CAN LOW Pin 18 A/D 0 ACC_OUT (FROM PEDALS)

10 uF

Pin 20 A/D 1

BRK_OUT (FROM PEDALS)

HCS12
Pin 32 PWM3

10 uF
ACC TO TORCS

Pin 3 GND

Figure A2-4 PEDALS ECU

108

5V
Pin 1 Vaux CAN_H RAIL CAN_L RAIL CAN HIGH CAN LOW Pin 18 A/D 0 TEMP FROM 10 uF TORCS

Pin 20 A/D 1

HCS12
Pin 30 PWM2 Pin 3 GND

TEMP_REF FROM 10 uF POT FAN_OUT (RC_IN) TO TORCS

Figure A2-5 CABIN COMFORT ECU 5V

Pin 1 Vaux CAN_H RAIL CAN_L RAIL CAN HIGH CAN LOW Pin 43 PB6 Pin 45 PB5 Pin 47 PB4 Pin 49 PB3 Pin 51 PB2 Pin 53 PB1 Pin 55 PB0 Pin 3 GND

Pin 18 A/D 0 10 uF

RPM FROM TORCS

FUEL_6 FROM TORCS FUEL_5 FROM TORCS FUEL_4 FROM TORCS FUEL_3 FROM TORCS FUEL_2 FROM TORCS FUEL_1 FROM TORCS FUEL_0 FROM TORCS

HCS12

Figure A2-5 ENGINE ECU

109

5V

Pin 1 Vaux Pin 18 A/D 0 10 uF Pin 20 A/D 1 10 uF CAN_H RAIL CAN_L RAIL CAN HIGH Pin 22 A/D 2 CAN LOW Pin 24 A/D 3 10 uF WHEEL_4 FROM TORCS 10 uF Pin 9 PP0 Pin 11 PP1 Pin 30 PP2 Pin 32 PP3 Pin 3 GND BRAKE_1 (RC_IN) TO TORCS BRAKE_2 (RC_IN) TO TORCS BRAKE_3 (RC_IN) TO TORCS BRAKE_4 (RC_IN) TO TORCS WHEEL_3 FROM TORCS WHEEL_2 FROM TORCS WHEEL_1 FROM TORCS

HCS12

Figure A2-7 ABS ECU

5V
CAN_H RAIL CAN_L RAIL Pin 1 Vaux CAN HIGH Pin 45 PB5 CAN LOW Pin 47 PB4 Pin 49 PB3 Pin 51 PB2 Pin 53 PB1 Pin 55 PB0 GEAR_2 FROM TORCS GEAR_1 FROM TORCS GEAR_0 FROM TORCS GEAR_2 TO TORCS GEAR_1 TO TORCS GEAR_0 TO TORCS

HCS12

Pin 3 GND Figure A2-8 TRANSMISSION ECU

110

5V
Pin 1 Vaux CAN_H RAIL CAN_L RAIL CAN HIGH CAN LOW Pin 37 PA1 Pin 39 PA0 Pin 51 PB2 BRAKE LIGHTS OUT LIGHTS OUT ENGINE MODE SWITCH

HCS1 2
Pin 3 GND

Pin 53 PB1
Pin 55 PB0

LIGHTS SWITCH
TRANSMODE SWITCH

Figure A2-9 CONSOLE ECU

111

5V

TMR IN
1 8 7 6 5 10 nF 22 nF 2.2K Ohms

TMR RESET TMR OUT

5V

2 3 4

Figure A2-10 555 TIMER CIRCUIT

112

+15 V

RC IN

100K Ohms

+ -

RC OUT TO TORCS

10 uF

-15V
Figure A2-11 RC FILTER

5V
STEER_OUT BTN1 TO TMR IN TO STR ECU TO STR ECU TO STR ECU TO STR ECU

STEERING WHEEL

BTN2 BTN3 BTN4

Figure A2-12 STEERING WHEEL CIRCUIT

113

5V

ACCEL

TO PEDALS ECU

PEDALS
BRK TO PEDALS ECU

Figure A2-13 PEDALS CIRCUIT

114

A2-14 COMPLETE SYSTEM

115

A3 CONTROL DIAGRAMS

Figure A3-1 ABS/Brakes ECU Software Flow

Figure A3-2 Cabin Control ECU Software Flow

116

Figure A3-3 Cruise Control ECU Software Flow

Figure A3-4 Differential Control ECU Software Flow

117

Figure A3-5 Transmission Control ECU Software Flow

118

A4 ADDITIONAL GRAPHS A4.1 EXAMPLE ABS/BRAKES OPERATION

ABS/Brakes Operation: Wheel Speed vs. Brake Command

150

75

100

50

50 Wheel Speed (FL) Brake Cmd. (FL) 0 3 3.5 4 4.5 5 Time (s) 5.5 6 6.5

25

0 7

Figure A4.1-1 Example ABS/Brakes Operation (FL Wheel)

ABS/Brakes Operation: Wheel Speed vs. Brake Command

150

75

100

50

50 Wheel Speed (RL) Brake Cmd. (RL) 0 3 3.5 4 4.5 5 Time (s) 5.5 6 6.5

25

0 7

119

Applied Brake Command (normalized to 100)

200

100

Wheel Speed (km/h)

Applied Brake Command (normalized to 100)

200

100

Wheel Speed (km/h)

Figure A4.1-2 Example ABS/Brakes Operation (RL Wheel)

ABS/Brakes Operation: Wheel Speed vs. Brake Command

Wheel Speed (km/h)

150

75

100

50

50 Wheel Speed (RR) Brake Cmd. (RR) 0 3 3.5 4 4.5 5 Time (s) 5.5 6 6.5

25

0 7

Figure A4.1-3 Example ABS/Brakes Operation (RR Wheel)

120

Applied Brake Command (normalized to 100)

200

100

A4.2 PATHOLOGICAL ABS/BRAKES OPERATION

Pathological ABS/Brakes: Wheel Speed vs. Brake Command

80

80

60

60

40

40

20

Wheel (FL) Brake (FL)

20

0 2 2.5 3 3.5 Time (s) 4 4.5

0 5

Figure A4.2-1 Pathological ABS/Brakes Operation (FL Wheel)

Pathological ABS/Brakes: Wheel Speed vs. Brake Command

80

80

60

60

40

40

20

Wheel (FR) Brake (FR)

20

0 2 2.5 3 3.5 Time (s) 4 4.5

0 5

Figure A4.2-2 Pathological ABS/Brakes Operation (FR Wheel) 121

Applied Brake Command (normalized to 100)

100

100

Wheel Speed (km/h)

Applied Brake Command (normalized to 100)

100

100

Wheel Speed (km/h)

Pathological ABS/Brakes: Wheel Speed vs. Brake Command

80

80

60

60

40

40

20

Wheel (RL) Brake (RL)

20

0 2 2.5 3 3.5 Time (s) 4 4.5

0 5

Figure A4.2-3 Pathological ABS/Brakes Operation (RL Wheel)

Pathological ABS/Brakes: Wheel Speed vs. Brake Command

80

80

60

60

40

40

20

Wheel (RR) Brake (RR)

20

0 2 2.5 3 3.5 Time (s) 4 4.5

0 5

Figure A4.2-4 Pathological ABS/Brakes Operation (RR Wheel)

122

Applied Brake Command (normalized to 100)

100

100

Wheel Speed (km/h)

Applied Brake Command (normalized to 100)

100

100

Wheel Speed (km/h)

Pathological ABS/Brakes: Vehicle Speed vs. Yaw Rate Error Vehicle Speed Yaw Rate Error 3.2

100

50

1.6

25

0.8

0 2 2.5 3 3.5 Time(s) 4 4.5

0 5

Figure A4.2-4 Pathological ABS/Brakes Operation: Large Yaw Rate Error

123

Yaw Rate Error (rad/s)

Vehicle Speed (km/h)

75

2.4

A4.3 CABIN COMFORT CONTROLLER

K Ts z-1 Integral 1 In1 Error K (z-1) Ts z Derivative 3 Proportional Ambient Temperature Noise 1 Gain .0008z z-1 Temperature Dynamics 1 Out1

Figure A4.3-1 Temperature Controller Simulink Model

Step Response of Cabin Comfort Controller with Additive Random Noise 1.4

1.2

0.8

Magnitude

0.6

0.4

0.2

-0.2

5 Time (s)

10

Figure A4.3-2 Cabin Comfort Controller Step Response

124

A5 DATASHEETS BeagleBoard Datasheet. Retrieved from www.beagleboard.org MC9S12C128 Datasheet. Retrieved from http://www.datasheetpro.com/7054_view_MC9S12C128_datasheet.html MCP2551 Datasheet. Retrieved from http://ww1.microchip.com/downloads/en/DeviceDoc/21667f.pdf NI DAQ 6229-M Manual. Retrieved from http://www.ni.com/pdf/manuals/371022k.pdf LM 555 Timer Datasheet. Retrieved from http://www.national.com/ds/LM/LM555.pdf LM 348 Quad Op-Amp Datasheet. Retrieved from http://www.national.com/ds/LM/LM148.pdf APS12C128 User Guide. Retrieved from http://www.ece.cmu.edu/~ece348/labs/docs/APS12C128_module/SLKS12UG_module_user_gui de.pdf

125

A6 MATHEMATICAL EQUATIONS Turning radius calculation (Source: http://www.carbibles.com/steering_bible.html): Rturn=1/2*[Wheeltrack/2 + Wheelbase/sin(theta)] Theta is the steering angle in radians. Wheel track is lateral distance between wheels. Wheel base is longitudinal distance between wheels/axles.

126

A7 ADDITIONAL SCREENSHOTS

A7-1 Raw CAN Info

A7-2 Android Application

127