System Design Document - Senior Design | ECE 480, Exams of Principles of Theater Design

Download System Design Document - Senior Design | ECE 480 and more Exams Principles of Theater Design in PDF only on Docsity!

System Design Do cument

Jaime Martin, Nilesh Humbad, Steve Kansa, Dan Forbes

Anti-lo ck Brake System

March 24, 1999

Contents

co des when voltage levels are either to o high or to o low. All error co des are stored in a cache for access by a technician.

1.3 Design Constraints and Limitations

Constraints to the anti-lo ck braking system include the following:

 The wheelsp eed sensor gives input to the controller. Rapid deceleration causes the ABS system to start. The system must check for skidding hundreds of times a second. If one wheel is decelerating faster than the others, lo ckup can b e caught b efore it happ ens.

 The system must control a value that interfaces with the wheel cylinders. It results in 'pump- ing' of the brakes, as much as 10 times p er second.

 This relieving of pressure within the wheel cylinder can b e accomplished by diverting some of the uid into a small reservoir.

 The ABS must re-pump this reservoir's uid back into the main uid reservoir.

 When the vehicle is initially started, the ABS go es through a test sequence. Another test sequence is needed every time the brakes are applied. The system must evaluate itself. If an error is found, the system turns itself o , and sends an error light to the dash. The ABS system is designed to calculate the maximum braking pressure that can b e applied to the wheels b efore lo ckup o ccurs. This is accomplished through the use of a previously loaded ROM table of ideal braking sp eci cations. The table is created using sample data from lab oratory test cars in simulated conditions. These values are computed with an appropriate safety margin to allow for some variation in car maintenance. Performance of the system can b e negatively e ected when conditions on the vehicle, such as tire wear, tire pressure and brake wear, fall b elow accepted norms. ABS will not work accordingly if the user pumps the brakes manually. It is recommended that ABS car owners hold the brake down and allow ABS to p erform the pumping actions, which is its entire purp ose.

2 System Architecture

The architecture of ABS is broken into many subsystems with a p eer-to-p eer relationship. The layering and partitioning of these subsystems de nes the interaction of these subsystems, and is illustrated by the system top ology diagram. Another architectural prop erty of ABS is that software control is event-driven. The control resides in several indep endent ob jects concurrently. ABS conforms to a real-time system architectural framework. To put this in more concrete terms, a real-time system is one that is timing crucial; i.e., time constraints on actions are particularly tight and the slightest timing error cannot b e tolerated. At highway sp eeds, fractions of a second can mean tens of yards. Clearly, real-time resp onsiveness is a necessary condition of the system design. ABS has b een designed to make as many as ten solenoid adjustments p er second. Real-time systems, by de nition, are also interactive systems. An interactive interface is a system that is dominated by interactions b etween the system and external agents, such as humans, devices or other programs. In the case of ABS, the only external agent is the brake p edal.

2.1 Top ology

The Anti-lo ck brake subsystems represent a p eer-to-p eer relationship. For example, ABS has two CPU's, one for controlling the front brakes and one for the wheel brakes; b oth communicate with various applications through one op erating system. The subsystems are layered in the system top ology to represent abstraction. Abstraction increases from the lower layers up to the higher layers. Each layer is thus built in terms of the one b elow it, and knowledge is one-way. This means layers know only ab out subsystems b elow them. ABS layering conforms to a closed architecture, each layer is built only in terms of the immediate lower layer. Portability and mo dularity are the advantages of using a closed architecture. Partitions divide a system into indep endent, weakly-coupled subsystems which provide sp eci c services. In other words, the vertical partitions of the system top ology represent functional decom- p osition.

2.1.1 Top ology Mo del Description

The lower layer of the ABS top ology represents hardware units. They are partitioned into the in- put circuit, which converts the sinusoidal AC voltage from the wheelsp eed sensors into square-wave output signals; a cache holding a table of error co des to b e replaced on a rst-in- rst-out basis; a cache holding previously calculated deceleration and sp eed; ROM containing a table correlating sp eed values with average deceleration and slip rates used for detecting wheel lo ckup; the wheel- sp eed sensors; and the solenoid valves. Another hardware layer represents the two central pro cessing units (CPU). One CPU controls rear brake applications while the other controls front brake applications. Two CPUs are used in order for the front and rear brakes to use the applications concurrently. Immediately ab ove the CPU layer is the op erating system layer. ABS has a distributed op erating system. A distributed op erating system is necessary to facilitate b oth CPUs. The distributed op erating system supp orts multithreading to enhance application throughput and application re- sp onsiveness. Multithreading also exploits the parallelism of the two CPUs. The layer ab ove the op erating system represents system applications. They are partitioned into the rear brake applications, the front brake applications, and the input conversion subsystems. Both the rear and front brake applications consist of the error data monitor, voltage monitor and controller logic applications. The error data monitor tests data used to make sure the system is working prop erly. For example, identical test inputs are sent to the front and rear CPUs and the end calculated values are compared. Should they di er, an error co de is generated and sent to the voltage monitor which shuts down the entire ABS system and sends the co de to an error co de cache in memory for future evaluation. The voltage monitor also monitors voltage levels of ABS comp onents and issues an error co de should values deviate from the norm. Any time the voltage monitor issues an error co de, it shuts down the system and turns on the warning lamp. The controller logic application calculates the controlled variables slip, deceleration and wheel sp eed for the wheels based on the pro cessed digital word from the input conversion application. These values are used to determine prop er p ositioning commands for the solenoid valves. If wheel lo ckup is detected based on these values, the controller logic needs to inform the solenoid valves to start pumping, thus releasing pressure. Both CPUs have access to the input conversion application which takes the square-wave output signal from the input circuit and converts it into digital words for control signals to the controller logic. The top layer in the ABS top ology represents the user interface. The warning lamp alerts the driver to an error in ABS, thus indicating it is inop erative.

2.2 Data Stores

Three main data stores exist in the anti-lo ck braking system. The rst is lo cated in ROM and holds a table of ideal braking sp eci cations. There is a correlation b etween braking conditions and set vehicle sp eeds. Braking conditions are de ned by the co ecient of friction and a maximum decel- eration rate. Vehicle sp eed de nes a mean braking deceleration, total braking time and a braking distance. This table is referenced for comparison with currently calculated values to determine if wheel lo ckup will o ccur. A memory cache is used to hold a table of previously calculated sp eeds, slip and deceleration to b e used for new calculations of these values. The cache incorp orates a rst-in- rst-out replacement algorithm b ecause older values are only needed for one calculation after their own use. The third, and nal, memory store is also a cache. This cache holds the error co des issued by the

voltage monitor. Each error co de is time stamp ed to determine which ones need to b e evaluated by the service technician. A rst-in- rst-out replacement metho d is also used for the error co de cache.

2.3 Software Control

ABS is an event-driven system. In an event-driven system, the system's activation is triggered by some external event. Control resides in a dispatcher or monitor which activates the system when certain conditions have b een met. For ABS, there are several primary dispatchers. The rst is the error data monitor. Each time the brake is applied, a test is p erformed by the error data monitor. This test compares the output values of two identical CPUs, which are simultaneously receiving the same input. If there are any discrepancies, a message is relayed to the voltage monitor, which will turn on the warning lamp. The voltage monitor is also a dispatcher which activates the warning lamp when voltage levels are not within close tolerances. Finally, there is the controller logic, which constantly receives input from the input conversion application. When the controller logic detects p otential wheel lo ckup, based on the slip and deceleration values, it sends prop er p ositioning commands to the solenoid valves. Concurrency is another feature of the anti-lo ck braking system. In concurrent systems, control resides within several indep endent ob jects simultaneously, with each ob ject p erforming a separate task. In ABS, the wheelsp eed sensors take input while the solenoid valves are acting in resp onse to previous output. The CPUs themselves op erate concurrently with resp ect to each other. While one CPU handles data from the rear brakes, the other CPU handles data from the front brakes. Besides the obvious sp eed advantage this a ords, there is also a considerable safety advantage, as there are separate error data monitors and voltage monitors. This translates to increased p erformance in error detection and recognition. The ma jor purp ose of concurrency with the CPUs in ABS is so the front and rear brakes can p erform the controller logic applications simultaneously. This allows for detection of wheel lo ckup in the front and rear brakes at the same time, without a time loss for reactions. Without this concurrency, wheel lo ckup could b e o ccurring in the rear brakes while the front brake values are b eing pro cessed. The loss of time to detect the lo ckup in the rear brakes would cause late reaction time by the solenoid valves, and p ossibly a car crash thus making the entire anti-lo ck braking system worthless. In safety-critical systems, where fractions of a second can mean the di erence b etween life and death, one can't b e to o particular ab out system choices.

3 GUI Description

The ABS user interface is comp osed of two key elements: the brake, and the ABS error lamp that is lo cated on the dashb oard. These two comp onents are the only elements of ABS that give user 'feedback.' The pumping action of the brakes, when ABS is activated, can b e considered a part of user 'feedback.' However, since this action is a result of the brakes b eing pressed, it is not included as part of the user interface. Furthermore, this action underlies the user interface, so it is not ignored in the overall system.

The user interface can b e more clearly understo o d by lo oking at the ABS prototyp e. Figure 2 shows what the prototyp e lo oks like up on instantiation. The prototyp e has four user changeable elds: brake pressure as a p ercentage, p otential wheel lo ckup selection, road condition selection and the sp eed of the motor vehicle. The brake system in the prototyp e is mo deled by rst sp ecifying

• 1 Intro duction
  • 1.1 System Ob jectives
  • 1.2 Hardware, Software, and Human Interfaces
  • 1.3 Design Constraints and Limitations
• 2 System Architecture
  • 2.1 Top ology
    • 2.1.1 Top ology Mo del Description
  • 2.2 Data Stores
  • 2.3 Software Control
• 3 GUI Description
• 4 System Design Description
  • 4.1 Ob ject Mo del
    • 4.1.1 Ob ject Mo del Description
    • 4.1.2 Data Dictionary
  • 4.2 Dynamic Mo del
    • 4.2.1 Dynamic Mo del Description
  • 4.3 Functional Mo del
    • 4.3.1 FunctionalMo delDescription
• 5 References
  • 5.1 System Do cumentation
  • 5.2 Technical References
• Figure 2: Prototyp e Figure
• Figure 3: Prototyp e Figure

pole pin

magnet

Sensors

sensor ring

Car Brake System DashLights

input circuit^ Accumulator pump^ Return pump^ solenoid valve

Hydaulic Pressure Mosulator pump

master brake cylinder wheel brake cylinder^ brake pedal

ABS

4

4

4 4

valve

Outlet valve Input Valve^ check valve

spring

main spring^ Auxillary spring

wheel frequency^ wheelspeed sensor Voltage monitor

Input Conversion

Controller logic Error Data Monitor^2

2 2

warning lamp

Figure 4: Ob ject Mo del

1

magnet

2

ECU

2 pole pin

generates pulse in

sensor ring

sensors 4 (^4 )

reads

1

2 input circuit

1 sends signals

wheelFrequencywheelspeed sensor

Figure 5: Sensor Ob ject Mo del

Outlet valve Input Valve check valve

Accumulator pump Return pump

main spring apply force^ Auxillary spring

2

controls pressure in

master brake cylinder

wheel brake cylinder^2

1 controls pressure in

2

1 signals

brake pedal

solenoid valve pressureBuilduppressureRelease pressureHold

4

valve closeopen

spring exertForce

Hydraulic Pressure Modulator (^1) pump

Figure 7: HPM Ob ject Mo del

4.1.2 Data Dictionary

1. ABS: Used to enhance braking safety, the anti-lo ck braking system prevents the wheels from lo cking in resp onse to excess brake pressure. The ABS exercises direct control over the op eration of the service brakes.
2. Input Circuit: This circuit converts the sinusoidal AC voltage from the wheelsp eed sensors into square-wave output signals.
3. Controller Logic: Calculates the controlled variables "slip" and "deceleration" for the wheels based on the pro cessed wheel sp eed (digital words from the input conversion application). Based on these values, the controller logic sends the appropriate p ositioning commands to the solenoid valves.
4. Error Data Monitor: Used for error recognition and evaluation. Resp onds to faults by trig- gering an error signal and shutting down the voltage monitor to deactivate the system.
5. Warning Lamp: Alerts the vehicle op erator to the fact that ABS is inop erative.
6. Input Conversion: This is where the square-wave signal is converted into digital words.
7. Voltage Monitor: Monitors and stabilizes voltage supply, incorp orates a low voltage recogni- tion function to switch o the system in the event of inadequate vehicle p ower supply or fault memory. Also governs the warning lamp.
8. Hydraulic Pressure Mo dulator: Implements commands issued by the Controller Logic. The HPM uses solenoid valves to automatically control pressure levels at the wheel-brakes.
9. Return Pump: Transmits the emerging brake uid through the accumulator back to the master brake cylinder as pressure is released from the wheel-brake cylinders.
10. Accumulator: Temp orarily absorbs ow surges that o ccur as brake uid is discharged during the pressure-release phase.
11. 3/3 Solenoid Valves: Control pressure mo dulation pro cesses in the wheel-brake cylinders during active ABS intervention. Each wheel has a solenoid valve.
12. Wheelsp eed Sensors: Provide signals (wheel frequencies) to the input circuit as the basis for determining the wheels' rotational sp eeds.
13. Pole Pin: Connected to a p ermanent magnet pro ducing an electric eld that extends outward to the sensor ring, generating a voltage in the sensor's winding to provide an index of wheel sp eed.
14. Sensor ring: Pulse rotor joined to the wheel hub.
15. Main Spring: Lo cated in the solenoid valves. Due to high tension and pressure from the auxiliary spring, the main spring op ens the input valve. Likewise, when the pressure is no longer exerted, the input valve closes.
16. Auxiliary Spring: Lo cated in the solenoid valve. It exerts forces on the main spring for control of the input valve.

In the Pressure Holding state the controller monitors the wheel deceleration and wheel slip rate. If the deceleration rate falls back into an acceptable range then the Pressure Build-up state is re-entered. If the wheel slip rate exceeds the maximum level, the controller sends the Op en Out- Let command, lo oks up the ideal wheel sp eed from the table in memory and enters the Pressure Reduction state. In the Pressure Reduction state the controller compares the current wheel sp eed with the ideal value. When the current wheel sp eed is equal to the ideal value, the controller sends the Close Outlet Valve and Op en Input Valve commands and re-enters the Pressure Build-up state. If the driver releases the brake during this stage, pressure reduction by the solenoid valves is no longer necessary, and this state is exited.

Figure 11 represents the test on the two CPUs each time the car is started or the brake is pressed. During the test the two CPUs are sent identical inputs. If the system is working correctly, the two CPUs should pro duce identical outputs. If the outputs are identical the system is enabled, otherwise the system is shut down and an error co de is stored.

Brake[ Test Fail ]

Brake[ Test pass ]

Car Started

Do: test Cycle

Service Brakes

Do: ABS Disabled

Only

ABS System Enabled

Figure 8: High Level