Software Requirements Specification (SRS) Steer By Wire System

Transcription

1 Software Requirements Specification (SRS) Steer By Wire System Authors: Chelsea Carr, Jason Harris, Kevin Woodward, Fai Hui Wu Customer: Continental Automotive Instructor: Dr. Betty H.C. Cheng 1. Introduction This document first introduces the specified product within, then gives a description of the system and while providing its specific and modeled requirements, and then describes a prototype of the software. The references used and a point of contact for further information are at the conclusion of the document. This Software Requirements Specification is intended to provide a high-level perspective of the Steer By Wire product s purpose, requirements and design. This document should serve as a basis for implementation of the product Purpose The purpose of this document is to describe the Steer By Wire system for cars in a clear and well-defined manner for both the developers and the customer of the system to validate the requirements. The final version of this document is recommended for use in the low level design of the software and its implementation. The intended audience for this document is the students of CSE 435 at Michigan State University, Dr. Betty Cheng, and Continental Automotive Scope The software product to be developed is a Steer by Wire controller for consumer vehicles. This controller, designed for use in consumer vehicles, provides away to steer a car by means of a non-mechanical steering mechanism. This application s domain is limited to an

2 embedded automotive system by which means of communication are limited to the input from a Controller Area Network (CAN) bus. The Steer By Wire controller will benefit the user by providing a means by which to steer a vehicle without the need for direct driver interaction with the steering wheel. The benefit to this system is such that a driver could be engaged in some other activity while the car remotely steers itself along a predetermined path or a path that is being updated by an outside or remote controller. The Steer by Wire controller will not provide an autopilot functionality in the vehicle without the use of another product monitoring the environment outside the vehicle and providing to the Steer By Wire Controller the proper input Definitions, acronyms, and abbreviations The purpose of this section is to explain and define any acronyms or abbreviations used in this document for clarification. CAN - Controller Area Network. A message-based protocol, designed specifically for automotive applications. deg - degrees. A unit of measurement; typically used for angles. The range for this is -720 to HTML - Hyper Text Markup Language. A language that is interpreted by a web browser to display content. MPH - Miles Per Hour. A measurement of vehicle speed, how many miles it can drive in an hour. NM Newton Meters. A measurement of distance in the metric system. PID - Proportional Integral and Derivative. Provides closed loop control of the vehicle steer angle based on a steer angle request. SBW - Steer by Wire. The product described herein. 2

3 SRS - System Requirements Specification. A document outlining a high-level design of a software system, the requirements it should meet and the constraints by which it should be limited. SWA - Steering Wheel Angle. The current angle and orientation of the steering wheel. WA - Wheel Angle. The current angle of the wheels Organization The remainder of this document is an overall description of the product (including constraints, assumptions and dependencies, and apportioning of requirements), followed by the modeled requirements of the system. Then, this document describes a functional prototype, how to use the prototype, and example scenarios of the prototype in use. Finally, this document includes all references used and a point of contact for further information. 2.Overall Description In this section, the overall idea of a SBW system is covered. The following is a list of the specific ideas that are described in this section: The possible constraints, specifically the ideas discussed in the requirements section The functionality of the software Who will be using this product Informed assumptions Team Auto Pilot has made based on elicitations and refinement of requirements Any changes made to the project by the customer 3

4 2.1.Product Perspective This product is currently meant to be used in scenarios where no one is operating the vehicle. By implementing a Steer By Wire System (SBW), the military can send these vehicles into missions, without putting anyone in danger. The SBW System makes up the steering component of a car by replacing the current hydraulic system with an electro hydraulic system. Figure 2.1.1, shows specifically how this system works and what components make up the system. Figure 2.1.1: Diagram of SBW integration into automobile system As depicted above, the SBW system takes in an input angle, processes the given angle, converts the given angle into the angle for the tires and actually turn the wheels of the car. There are a few constraints that could arise with this system. Because the vehicle is unmanned, the system interface will have to be set up differently than if someone was driving the car. The angle inputs will be passed to the car through an external method and not by physically turning the wheel. The system will also be a replacement for the old hydraulic system. This new system is an electro hydraulic system that takes out the manual effort. 4

5 2.2.Product Functions The system will take in an external request, which is the desired angle for which they want to turn. The equation to calculate the desired angle from the external request is as follows: External Request(angle) = SWA * 45deg/720deg The system itself will manipulate the input value, deciding what torque values are needed to turn the wheels to the desired angle. The system can calculate the load torque by adding together the inertia coefficient, the dampening coefficient, the spring constant and the total friction as shown below. Load Torque = Nm/s^ Nm/s + angular velocity (2 nd derivative of the external request) + velocity (1 st derivative of the external request) The load torque value is then applied to the request angle to turn the wheels. The diagram below shows a more thorough example of how this is done. 5

6 Figure 2.2.1: Visual Functionality - A breakdown of the functions used in the system 2.3.User Characteristics A SBW vehicle should be unmanned at this time. Before the system begins executing commands, a trained, SBW specialist will be entering angles, speeds, and other values. There will be no public use of this vehicle with its current design. 2.4.Constraints The SBW System has a few constraints that continually need to be monitored in order for the system to run. The vehicle must stay within the speed range of -10 mph and 20 mph, otherwise the system will not be able to respond quickly enough to the angle input. Another constraint is that the vehicle can only take in an input angle with the range of deg and 720 deg. Any angle outside of this range will not be acknowledged by the machine. The interpreted output angle can lie only within -45 degrees and 45 degrees. If an input angle outside of its range is entered, then the car will not be able to turn to that amount. Because of the two other listed constraints, the torque output range is also constrained. The torque output range can only be between -10Nm and 10Nm, otherwise the torque will skew the amount the car actually turns. 2.5.Assumptions and Dependencies The assumptions made in this section are ideas that were not necessarily clarified by the customer and were decided on by Team Auto Pilots. The assumption is made that the vehicle is powered on and is moving with a speed within the specified range of operation, between zero (0) and twenty (20) miles per hour in an area that is free of any obstacles including but not limited to other motor vehicles and pedestrians. An additional assumption is made that any change in angle request is given by the user. A double check is done against the current steering wheel angle (SWA) to make sure that any driver override of requested angle is given priority and in such a case the requested input angle is eschewed in favor of the SWA. The dependencies made in this section are ideas that can only be implemented if other components of the system are implemented. Regarding dependencies the system is dependent firstly upon the controller area network (CAN) bus. This dependency gives the SBW system 6

7 permission to run along with desired input angles. The SBW system will also set a data flag when an error is encountered in operation and the vehicle needs to cease motion or a driver takeover is required. The SBW system is secondly dependent upon a requested steering angle given either through the CAN bus or by a change in the current SWA. This change will be used in the tire wheel angle calculations. The SBW system is lastly dependent upon the current vehicular speed as its intended operational velocities are between zero (0) and twenty (20) miles per hour. Outside of this speed range the SBW system should cease operation and a driver takeover is required. 2.6.Apportioning of Requirements One example of future expansion is to make this vehicle work as a public form of transportation. Currently, there is an SBW system implemented for planes, however this is not a feasible form of transportation for society s day to day travel. Because of the SBW system s current implementation, it is unstable to be used by the public. The system currently just takes in a set of external requests and processes them. One day, the external request will be connected to the steering wheel, making it possible for the user input to be taken straight from a user, rather than an execution string. Another idea would be to increase the range of speeds at which the vehicle can travel. Currently, if the vehicle is moving at a speed outside of the range of speeds or even towards the very limits of these constraints, the response time of the vehicle is drastically slowed down. 7

8 3. Specific Requirements Requirements help define and specify what a system should be doing. The requirements below give a general overview of all the main functionality, system hardware and software, and safety features that should be implemented in a SBW system. 1. Hardware Requirements 1.1. A de-coupled steering wheel with an integrated steering wheel angle (SWA) sensor 1.2. An electronic controller to read the SWA sensor signal, read a vehicle steer angle signal, and provide PID control of a steering actuator 1.3. An electric steering actuator to provide torque which acts on the steering mechanism 1.4. A steering mechanism which transmits the actuator output torque into the actual vehicle steer angle and includes an integrated steer angle sensor for feedback to the controller. 2. Software Functionality 2.1. The driver inputs a steering request via the de-coupled steering wheel that has an integrated steering wheel angle sensor The sensor signal is input into an electronic control module and is mapped as the driver s steering angle request A feedback signal from the vehicle s actual steer angle (via integrated sensor) is subtracted from the driver s steering angle request signal, creating a steer angle error signal The error signal is input into a PID control algorithm which outputs a control signal (torque request) to the electric steering actuator, which in turn acts on 8

9 the steering mechanism to create closed loop control of the vehicle steer angle. 3. Steering Wheel Angle Interface 3.1. SWA to Steer Angle Request Mapping: External Request (angle) = SWA * 45deg/720deg 3.2. SWA = +/- 720deg (Wheels would be at angle -45 deg to 45 deg) 3.3. Steering Actuator: Torque Output Range is +/- 10 Nm Dynamic characteristics with time constant(t) = 20 ms 4. Steering Mechanism Interface 4.1. The vehicle steer angle range is +/- 45 deg with redundant vehicle steer angle sensor output signals proportional to the vehicle steer angle 4.2. The load characteristics of the steering mechanism are per the following equation: Load Torque = inertia*theta + damping*theta + spring*theta + friction 4.4. The steering mechanism inertia coefficient is.053 nm/s^2 (N*M*sec^2/deg) 4.5. The steering mechanism damping coefficient is.067 nm/s (N*m*sec/deg) 4.6. The spring rate characteristic of the overall steering mechanism tends to return the steer angle to the zero degree position as shown in below curve. 9

10 4.7. The torque values are proportionally reduced to zero as vehicle speed is reduced to zero The steering mechanism friction characteristic is Coulombic and will act to resist the motion of the vehicle steer angle. 5. Functional Requirements 5.1. Speed range: -10 to +20 mph 5.2. Steady state error: Vehicle steer angle +/- 2% of requested theta value 5.3. Response time: At 20 mph, with a vehicle steer angle request step input from zero to 10 deg, the actual vehicle steer angle shall reach 63% of it s steady state value within 50ms. 6. Safety Requirements 6.1. A Proportional Integral and Derivative (PID) control shall be implemented in software to provide closed loop control of the vehicle steer angle based on a steer angle request The control will provide a torque request signal to the steering actuator theta to create desired angular output while acting against the torque load of the steering mechanism 7. Update Rate 7.1. Refresh the motor drive commands data from updated calculations at a rate no slower than every 500 microseconds. (This is required for proper control) 8. Sensor Diagnostics for Safety 8.1. Verify that the SWA sensor values correspond within 5% of each other. 10

11 8.2. Verify that the vehicle steer angle sensor values correspond within 5% of each other Perform these tests at a rate not less than every 10 milliseconds Use the minimum value of the redundant sensor signals for the calculation. 9. Operational Diagnostics for Safety 9.1. (Optional) An internal watch dog timer, an external watch dog counter and interrupt counter shall be used to ensure all control loops and background software are operational Operational diagnostics shall be repeated at a rate no less than every 10 milliseconds. 10. Fault handling for Safety Should a failure condition be detected, measure the existing motor current value then ramp the current back to zero over a 2 second period The safety diagnostics shall be tested via fault insertion in real time to show that the safety measures are functional At a minimum the following are required: External watch dog failure Steer angle sensor value failure 4. Modeling Requirements It is important for a development team to depict their requirements using several different types of diagrams and/or models. This strategy helps to detect early disagreements or errors that may be costly if they are not handled early in the development process. By creating several 11

12 different types of diagrams the developers can also examine many important aspects of their project from different perspectives. 4.1 Use-case Diagram The first type of diagram will help to clarify the domain, or scope, of the project. This diagram is called a use-case diagram. It is used early on in the design process and allows the developer to examine interactions between the different components of the project. The components specific to our use-case diagram are as follows: Controller: the software component of our model. Electronic Actuator: this component is the mechanical-response that physically turns the wheels. Wheel Sensor: provides the controller with the current angle of the wheel. External Watch Dog: this component is currently hypothetical; it will be a small software package that confirms that the controller is functioning properly. System: this term refers to the controller, electronic actuator, wheel sensor, and external watch dog as a whole (i.e. the software and hardware units found in our model). External Request: this term refers to an entity outside of the system; in our model the external request is a computer. The use-case diagram, Figure 4.1, depicts the goals of the SBW model. Each goal is termed by the phrase use case. This use case diagram can be broken down into six parts: 1. An actor is depicted with the stick-figure icon; this represents one of the components that were defined at the beginning of section four. 2. A goal is represented by an oval; the description of each goal is represented by the text inside the oval. This can also be referred to as a use case scenario. 3. A line from an actor to a goal represents the actor taking part in completing that goal. 4. An arrow labeled with the <<Includes>> text represents a relationship between two goals. This relationship shows that one goal depends on another goal in order to be completed. The direction of the arrow points from the dependent goal to the goal that it is dependent upon. 12

13 5. An arrow labeled with the <<Extends>> text represents another relationship between two goals. This relationship depicts one goal representing a unique case of another goal. The direction of the arrow points from the unique case to the generic goal. 6. The surrounding box represents the domain of the model. It encompasses the goals of the entire model. 7. All use case scenarios are represented in the tables following Figure 4.1. These tables can help to clarify some of information conveyed in the use-case diagram that may otherwise be difficult to depict in the use-case diagram alone. 13

14 Figure 4.1: Use-case diagram Use Case: Actors: Description: Controller Failure External Watch Dog The watch dog reports an error if the controller is not functioning properly. 14

15 Type: Secondary Includes: NA Extends: Monitor Diagnostics Cross-refs: 9,10 Dependent Use Cases: NA Use Case: Monitor Diagnostics Actors: External Watch Dog, Controller Description: Watch dog checks the controller to make sure that it is functioning properly. Type: Secondary Includes: NA Extends: NA Cross-refs: 9, 10, Dependent Use Cases: Watch Dog Failure Use Case: Report Current Angle Actors: Wheel sensor, Controller Description: The wheel sensor reports the wheel s current angle to the controller. Type: Primary Includes: NA Extends: NA Cross-refs: 2.2, 7 Dependent Use Cases: Sensor Failure Use Case: Sensor Failure Actors: Wheel Sensor Description: Report an error if the wheel sensor has failed. Type: Secondary Includes: NA Extends: Report Current Angle Cross-refs: 8, Dependent Use Cases: NA 15

16 Use Case: Calculate Angle Error Actors: Controller, Wheel Sensor, External Request Description: The controller checks the angle of the wheel against the angle that is being sent from the external request. Type: Primary Includes: NA Extends: NA Cross-refs: 2.3, 2.4 Dependent Use Cases: Calculate Torque Assist Use Case: Calculate Torque Assist Actors: Controller Description: The controller calculates the amount of torque required to match the current wheel angle to the external request angle. Type: Primary Includes: Calculate Angle Error Extends: NA Cross-refs: 1.2, 2.3, 2.4 Dependent Use Cases: Request Torque Assist Use Case: Request Angle Actors: External Request, Controller Description: The external request reports the desired angle. Type: Primary Includes: NA Extends: NA Cross-refs: 2.1, 2.2, 7 Dependent Use Cases: NA Use Case: Actors: Description: Type: Includes: Request Torque Assist Controller, Electronic Actuator The electronic actuator is sent a signal from the controller. The signal contains the appropriate amount of torque assist needed. Primary NA 16

17 Extends: NA Cross-refs: 1.2, 1.3, 2.4 Dependent Use Cases: NA Use Case: Signal Failure Actors: External Request Description: An error occurs if there is a problem with the external request signal. Type: Secondary Includes: NA Extends: Request Angle Cross-refs: 8 Dependent Use Cases: NA 4.2 Domain Model Diagram Another type of diagram, shown in Figure 4.2, describes the components of the software used in the system. This is known as a domain model diagram or a class diagram. A box in the diagram represents an element in an object-oriented software package. The first section of an element box shows the element s title, the second section depicts the element s attributes, and the third section describes the functions that the element can activate. These objects are connected by lines which represent relationships between the objects, and the numbers located at either end of the line represent the number of objects that can be associated with each other in the system. A line with a black diamond at the end of it denotes a composition-association between two elements. The class connected to the diamond is made up of the class at the other end of the line. These elements are dependent upon each other in order to exist in the system. A line with a white arrow at the end of it represents an inheritance relationship. The arrow points from the childelement to the parent-element. A domain model diagram helps to specify the unique characteristics of each element in the system and a developer can view ways that objects relate to one-another. To further describe these characteristics each class is depicted by a data dictionary that is in the form of tables following the class diagram. Each data dictionary may help to convey information that may be difficult to see in the class diagram alone. 17

18 Figure 4.2: SBW Domain Model Diagram 18

19 Element Name SpeedSensor Attributes Operations CurrSpeed: Float Description The speed sensor class represents a sensor that detects the current speed of the vehicle. A value which represents the speed in miles per hour. ReportToController() : Float Function that overrides the virtual function defined in the sensor class; reports the value of the CurrSpeed. Relationships Child of Sensor. Reports to Controller. UML Extensions Element Name Sensor Attributes NA Operations ReportToController(): Virtual Float Update(): void Relationships Description Abstract class that defines the shell for all the sensor elements in the system. NA Function that sends the appropriate information to the controller. Function that refreshes the information stored in a sensor to reflect the current information of that sensor. Parent of SpeedSensor, and WheelAngleSensor. The Controller pulls in information from this type of class. UML Extensions Element Name ExternalRequestSensor Attributes RequestAngle: Float Description This class represents a signal from an external entity (driver, computer, etc.). This signal is in the form of an angle measurement which simulates the position of the steering wheel. Stores the current request angle in degrees. 19

20 Operations Relationships ReportToController() : Float Function that overrides the virtual function defined in the sensor class; reports the value of the RequestAngle. Child of Sensor. Reports to the Controller. UML Extensions Element Name WheelAngleSensor Description This class represents a sensor that will monitor the current position of the wheels in the system. Attributes CurrAngle: Float Stores data that represents the current angle of the wheels in the system, measured in degrees. Operations Relationships ReportToController() : Float Function that overrides the virtual function defined in the sensor class; reports the value of the CurrAngle. Child of Sensor. Reports to the Controller. UML Extensions Element Name Actuator Attributes CurrTorqueAssist : Float Operations Actuate() : void Relationships Description A class that represents the component of the system that mechanically moves the wheels. Stores the data for the current torque that is being applied by the actuator (in Newton meters). Function signals the wheels to change the current angle. Receives signal from the Controller. 20

21 UML Extensions Element Name WatchDog Attributes Flag : Bool Operations Description A class that monitors the director to make sure that it is functioning properly. An error value which is set to true if there is any discrepancy between the watch dog logic and the controller logic. Relationships WatchDogAlgorithm() : void A function which double checks the logic of the controller to make sure that it is functioning properly. OverrideController() : void Signals the controller that there is an error and appropriate steps must be taken to return the system to a safe state. Monitors the Controller. UML Extensions Element Name Controller Attributes Operations Description A class that processes data from the sensor components, calculates the appropriate torque assistance that is needed, and signals the actuator with the torque request. Override : Boolean Stores the value of the override state. LeastRecentlyUpdated : Float Stores data that denotes the time that the sensors were last refreshed. CurrWheelAngle : Float Stores data that represents the current value of the wheel angle in degrees. CurrRequestAngle : Float Stores data that represents the current value of the request angle in degrees. CurSpeed : Float Stores data that represents the current speed of the vehicle in miles per hour. RegisteredSensors : <<Class>> A List that stores the sensor objects that are Sensor[] reporting to the director. 21

22 Relationships RefreshSensorValues() : void Function that sends signals for the sensor objects to refresh their current data. CalculateTorqueAssist() : void Function that calculates the appropriate amount of torque assistance that is needed to correct the difference between the wheel angle and the request angle. RequestTorqueAssist () : Float Function that signals the actuator with value of the torque request that is needed. Signals the Actuator to apply torque to change the current position. Receives data from the Sensor classes. Monitored by the WatchDog. UML Extensions 4.3 Sequence Diagrams In this section each diagram represents an instance of an execution path in the system. These diagrams are referred to as sequence diagrams. A sequence diagram shows the interactions that take place between objects as they progress over a time period. Each object is denoted by a box located at the top of the timeline. The text in these boxes denotes the name of the instance and the type of class that the instance represents, separated by a colon (respectively). Time is depicted as the vertical dotted lines; moving down these vertical columns represents progression in time. The current instance of an object is depicted by the vertical boxes on the timeline. Interaction between these objects is shown by solid horizontal lines. These arrows are labeled with the function s name. The arrows at the end of a horizontal line represent the type of interaction. An asynchronous function call is represented using a full solid arrow; in this type of interaction the object being called upon must complete its task before the calling object can proceed in its tasks, and the completion of a call is shown using a horizontal dotted line. A synchronous function call is represented using half of a shaded arrow; in this type of interaction the object that is calling the function is not dependent upon the completion of that task. In the first sequence diagram, shown in Figure 4.3.1, the object instances that are represented are Controller, Speedometer, and ElectronicActuator; which are of class types Controller, SpeedSensor, and Actuator respectively. The Controller calls a function to refresh the 22

23 values of all of its sensors (this case specifically shows the sensor titled Speedometer). The Speedometer calls its update function to refresh the current value that is stored in its speed variable. Once this task is complete the Speedometer reports its updated speed value to the Controller where the value is stored. The Controller uses this updated value to calculate the necessary torque assistance that must be applied. Lastly, the Controller signals the ElectronicActuator with the appropriate amount of torque. In the second sequence diagram, shown in Figure 4.3.2, the object instances that are represented are Controller, WheelSensor, and ExternalWatchDog; which are of class types Controller, WheelAngleSensor, and WatchDog respectively. The Controller begins by requesting the current data value of its sensors, and the WheelSensor responds with an update and its reporting function. The Controller then attempts to calculate the appropriate amount of torque assistance. This logical operation is double checked by the ExternalWatchDog s algorithm function. In this scenario the solution to the WatchDog s algorithm does not match the solution to the Controller s calculation. The Controller s function is terminated (denoted by the X in the diagram) and the WatchDog notifies the Controller of the inconsistency by calling its OverrideController function. In the last sequence diagram, shown in Figure 4.3.3, the object instances are represented by the names Controller, ExternalRequest, Speedometer, and WheelSensor; which represent the classes Controller, ExternalRequestSensor, SpeedSensor, and WheelAngleSensor respectively. This diagram reflects the interactions between all of the sensors and the controller as the controller attempts to calculate the new torque assistance based on the current values stored in the sensors. The Controller begins by signaling the sensors to refresh their current values. All of the sensors refresh their data simultaneously and then report back to the Controller with their new data. Once all of the updates are complete the Controller then attempts to calculate the new value of torque assistance that is required. 23

24 Figure 4.3.1: Sequence Diagram - Torque Request Based on Change of Speed 24

25 Figure 4.3.2: Sequence Diagram Controller Error Causes an Override Call by the WatchDog 25

26 Figure 4.3.3: Sequence Diagram Controller Signals Sensors to Update to Reflect New Input 4.4 State Diagram In this section, a diagram is used to represent the status of a system. This type of diagram is referred to as a State Diagram, shown in figure Each status can be referred to as the system s state. A state is denoted using a rounded-edge box. The text inside the box describes the state of the system. The system may change its state by completing a task or through the occurrence of a specific event. These transitions are denoted by the arrows connecting the boxes, and each is accompanied by text that describes the task that has been completed or the event that has occurred. The last two symbols that are present in any state diagram are used to represent the initial state of the system (shown as a filled circle) and the final state of the system (shown as a filled circle inside of an empty circle). 26

27 The state diagram presented in this section describes the possible statuses of the SBW system. Firstly, the system must be powered on to work. Next the system takes in an external request, or the desired angle to turn the wheels, This request must be validated to make sure that the angle entered is within the acceptable range (-720 deg to 720 deg). If the angle is outside of the acceptable range, a flag is set to indicate an invalid angle and a new angle must be reentered, as that one will not be used. If the angle is valid, then the controller of the system takes the angle and calculates a load torque value to successfully turn the wheels the right amount. This torque value is calculated by using the external request and information gathered by the car, such as friction between the tires and the road, speed, etc. After the load torque is calculated the angle and torque value are applied to the wheels to actually turn them to the right angle. During any step of this process, the current state can return to the EnterAngle State and retrieve a new angle. The system can only be powered down at the EnterAngle State as the system is in the middle of calculating values at all other states in the system. Figure 4.4.1: State Diagram How to use the system 5 Prototype The prototype is made from JavaScript and Hyper Text Markup Language (HTML). JavaScript works in all major web browsers such as Internet Explorer, Firefox, Chrome, Opera, and Safari. The user will input desired Steering Wheel Angle (SWA) that he or she wants to use in the simulation as well as the car s present speed. According to the user s input data the 27

28 prototype displays relevant output data as well as internal system values used in output calculations. 5.1 How to Run Prototype The prototype requires an Internet connection to run and must be accessed from any major web browser such as Internet Explorer, Firefox, Chrome, Opera, and Safari. In addition, the prototype requires several user inputs (w,s,a,d) from the keyboard in order to properly run. The w and s keys are used to increase and decrease the velocity, respectively. The a and d keys are used to increase and decrease the steering angle. The required inputs are used for value calculations and are the current vehicle wheel angle, load torque, and the present speed of the vehicle. These variables can be used and varied to display a wide variety of scenarios to show the operation of the Steer by Wire (SBW) controller. 5.2 Sample Scenarios Scenario 1 The picture below (Fig 5.2.1) is scenario 1 for the prototype of web application. In this scenario, user presses d to increase the steering wheel angle value to 30 and presses w to increase the velocity value to 20. Since the speed and the angle of steering wheel are known, the values of Load Torque, Current Friction, and Spring Rate are calculated by applying the Load Torque formula below. Figure Scenario 1 28

29 First, the prototype uses the formula below (Formula 5.2.1) to change the requested SWA into the proper angle to turn the vehicle wheels. The prototype is also set up to use a default value of 2 seconds to turn to the desired SWA. Using the below formula the prototype determines this theta: 30*45/720= Vehicle Wheel Angle=Ө request= SWA*45/720 Formula The equation used to change the requested steering angle into the wheel base angle. Second, the prototype must determine the Spring Rate value from the formula below. The Spring rate is the absolute value of the Wheel Angle divided by 9. In Scenario 1, the Spring Rate is equal to 30/9= Spring Rate=Ө request= absolute (WA*/9) Formula The Spring Rate is used to calculate the Load Torque. Third, the prototype must determine the Load Torque value from the formula below (Formula 5.2.3). In order to determine the Load Torque the SBW controller uses two intermediate values, the Inertia factor, whose value is shown below in Formula 5.2.3, and the Dampening coefficient, also shown below in Formula These values also use the Spring Coefficient, shown below in Formula Load Torque=Inertia* angular velocity +damping * velocity +spring*ө + friction Formula The equation used to calculate the Load Torque on the vehicle tires. The Inertia Factor, shown below in Formula is a constant that is used in the calculation of the Load Torque above in Formula Inertia factor =.053 Nm/s^2 Formula This equation gives the Inertia Factor angular velocity = 2 nd derivative of the angle The Damepening Coefficient, shown below in Formula is a constant that is used in the that calculation of Load Torque shown above in Formula

30 Dampening coefficient =.067 Nm/s Formula This Equation gives Dampening coefficient. velocity = 1 st derivative of the angle The Spring Coefficient, shown below in Formula is a constant that is used in the calcuation of Load Torque shown above in Formula Spring coefficient = 5/45 Nm/degree Formula This Equation gives Spring Coefficient. Ө= Ө request - Ө current measurement At different speeds there is a different coefficient that will ramp the amount of the SWA angle. At faster speeds the SWA to Wheel Angle (WA) changes such that it takes a greater SWA to achieve a higher WA and at lower speeds a smaller SWA will attain the same WA. The Friction formula below, Formula 5.2.7, is used in the Load Torque calculation (formula 5.2.3). When the vehicle velocity is above three (3) miles per hour the Friction formula shall always output a value of one(1). At a vehicle speed of zero miles per hour a value of eight (8) is returned. When the velocity is between zero and three miles per hours, the value of Friction will use Formula In scenario 1 the Velocity is -7 so the friction formula will return a value of 8. Friction = velocity *(-7/4) + 8 Formula The Friction Formula described and used in the Load Torque equation. In the scenario presented herein the load torque is calculated as in the figure below, formula 5.2.8, with values achieved from the above equations in formulas through Load Torque=.053*(-7)/2+.067*(-7)+5/(-7) *(-7-0)+ 1= Formula The Load Toque calculation with filled in values and result 30

31 After calculating these values the prototype will display the resultant Load Torque that will be used by the actuators in the system. Scenario 2 The picture below (Fig 5.2.2) is scenario 2 for the prototype of web application. In this scenario, user presses d to increase the steering wheel angle value to 180 and presses w to increase the velocity value to 20. The prototype is also set up to use a default value of 2 seconds to turn to the desired SWA. Since the speed and the angle of steering wheel are known, the values of Load Torque, Current Friction, and Spring Rate are calculated by applying the Load Torque formula above. Figure Scenario 2 The value of Vehicle Wheel Angle is calculated from the formula and equals Since the velocity exceeds 3 miles per hour, the Friction will be 1, based on the chart in figure S. Spring Rate is calculated from the formula and equals Load Torque is equal to The Velocity is constrained to a value between -10 to 20 miles per hour. There is a function to make sure the user will exceed the maximum value, even though the user continues to request an increase. 31

32 Figure A chart showing a few calculated friction values. Scenario 3 The picture below (Fig 5.2.4) is scenario 3 for the prototype of web application. In this scenario the user presses s to increase the steering wheel angle value to 720 and presses w to increase the speed value to 15. Since the speed and the angle of steering wheel are known, the values of Load Torque, Current Friction, and Spring Rate are calculated by applying the Load Torque formula above. Figure Scenario 3 32

33 The value of Vehicle Wheel Angle is calculated from the formula equals 45. Since the velocity is between zero and three miles per hour, the friction will equal Spring Rate is calculated from the formula 5.2.2, and gives 5. Load Torque is determined by the formula 5.2.4, which is equals to The Steering Wheel Angle is constrained to a value between -720 to 720. There is a function to make sure the user will not go beyond these values even if the user continues to request an increase above the maximum value or a decrease below the minimum value. 6 References Continental Corporation, and Betty H.C. Cheng. Steer By Wire. Ed. Team Auto Pilot. Steer By Wire. Continental Automotive. Web. < Continental-ver3.pdf>. Continental Corporation. "Elicitation 1." Telephone interview. 26 Oct Continental Corporation. "Elicitation 2." Telephone interview. 7 Nov "Electrohydraulic - Definition and More from the Free Merriam-Webster Dictionary." Dictionary and Thesaurus - Merriam-Webster Online. Web. 20 Nov < 7 Point of Contact For further information regarding this document and project, please contact Prof. Betty H.C. Cheng at Michigan State University (chengb at cse.msu.edu). All materials in this document have been sanitized for proprietary data. The students and the instructor gratefully acknowledge the participation of our industrial collaborators. 33

34 34