View TL32_1070535.PDF datasheet online --- IC-ON-LINE

Datasheet File OCR Text:

hperry 5/4/01 real time system testing mit 16.070 lecture 32
hperry 5/4/01 real time system testing (32) ? the next three lectures will focus on: ? lecture 30: (r 11.3) how to minimize failure in real time systems methods used to test real time systems ? lecture 31: (r 13) what is software integration? test tools an example approach for integration and test of the mit 16.070 final project ? lecture 32: (r 11.4) fault tolerance exception handling formal test documentation
hperry 5/4/01 fault tolerance what does it mean for a system to be fault tolerant? the system can operate (although performance may be degraded) in the presence of a software or a hardware failure. how do you design a fault tolerant system? incorporate exception handling to tolerate missed deadlines or work around error conditions design fault tolerant or redundant hardware or software into the system ask yourself questions ? how can the system fail?
hperry 5/4/01 some exception handling methods q: what if your system randomly misses data from a sensor? a: time tag your system data and use it only if the time tag has been updated since the last time it was used. gps shared memory navigation sensor tasks sensors sensor data pools gps data with time tag is written to shared memory when other tasks come to read that data out of shared memory, they can discard the data if the new time tag = old time tag. lat, lon, alt, time tag lat, lon, alt, time tag data consuming tasks
hperry 5/4/01 some exception handling methods q: what if your system randomly misses data from a sensor? (continued) a: if data is too stale and the system cannot function properly without the new data, switch to a degraded mode of operation ? in a navigation system, this might be a backup navigation mode that operates on minimal inputs, separate from those that have failed ? in a space explorer robot system, this might be a zero-velocity state where the robot waits for communication of a set of new commands
hperry 5/4/01 some exception handling methods q: what if data goes bad for any number of reasons? what if bad data results in... divide by zero in the software algorithm data input from sensors out of a specified range (overflow condition for the algorithm or for the data type) a: add conditionals to your software to work around the problem. instead of use result = y/x; if x !=0 then result = y/x; data = get_data(); data = get_data(); if data>1000, data = 1000; if data<0, data = 0;
hperry 5/4/01 some exception handling methods q: what if a critical task should hang during execution? ? for example, a task is waiting on data from a sensor, but the sensor loses its data link to the processor before it can provide the data)? loop task while (1) data = get_data(); retrieves data from sensor and returns
hperry 5/4/01 some exception handling methods a: relieve the task from waiting by ? designing functions with return values to indicate good/bad status adding timeouts on retrieving the data to those functions to drive good/bad status return. note : this brings up the need for call by reference in c this concept can be expanded to operating system calls (posting mailboxes, releasing semaphores), library function calls, etc. provided the rtos supports it.
hperry 5/4/01 some exception handling methods the importance of ? call by reference ? to facilitate error handling c functions can return only one value if that value = status, how does the calling task (or function) get any information back from the task? the answer - call by reference. instead of use int get_data(); int get_data(*int x) where the int returned is data: where int returned is the status and y is data: data = get_data(); status = get_data(&y)
hperry 5/4/01 some exception handling methods without exception handling : int y; int get_data(); void light_led(); while (1) { y = get_data(); /* get data from sensor software*/ if (y>100) { light_led(); /* turn on leds */ } } /* end infinite loop */
hperry 5/4/01 some exception handling methods with exception handling : # include int y, error; int get_sensor_data(int* x) void light_led(); while (1) { error = get_sensor_data(&y); /* pass the function the address of y, return error */ if (!error) { if (y >100) light_led(); /* turn on leds */ } else printf("error in data coming from sensor = %d", error); } /* end infinite loop */
hperry 5/4/01 exception handling methods - the tradeoff on the one hand, exception handling can guard against problems such as: ? erroneous mathematical conditions (divide by zero, overflow) ? tasks that hang waiting for inputs that will never come (due to failed hardware, poor communication link, software bug etc.) ? poor reactions to missed deadlines on the other hand, putting in all of this exception handling takes up resources (cpu time and memory) that must be worth the trade-off you must balance the two to achieve a robust software design that works within the timing and sizing constraints of the system
hperry 5/4/01 fault tolerance - checking hardware resources how can a processor check its own status? built-in-test (bit) ? ongoing diagnostics of the hardware that runs the software ? interface checks cpu testing (done in the background) memory testing ? checking for memory corruption due to vibration, power surges, electrostatic discharge, single event upsets, etc. ? use error detection & recovery schemes (crc, hamming code) watchdog timers ? counting registers used to ensure that devices are still on line ? cpu resets the timer at regular intervals. timer overflow indicates a problem with the cpu
hperry 5/4/01 fault tolerance redundant hardware solutions - a two processor scheme primary sends replica of all its inputs to secondary secondary runs same software as primary secondary checks for ? pulse ? from primary to verify its health if pulse is absent, secondary takes over the system requires redundant communication lines to all system components many military aircraft systems are built this way primary secondary
hperry 5/4/01 fault tolerance redundant hardware solutions - a two processor scheme when might this scheme fail? ? ? ? primary secondary
hperry 5/4/01 fault tolerance - redundant processors computers can vote on who is worthy of staying in the system -check ? pulse ? to be sure the computers are on-line - compare data outputs from computations how many do you need? a c b a b 2? 3?
hperry 5/4/01 fault tolerance - redundant processors a c b a b 2? 3? a says b is sick b says a is sick who is right? who should take over the system? a says b is sick b says a is sick c says a is okay c says b is sick you might deduce that b is sick but what if you lose one computer? you must consider the probability of losing a computer given the catastrophe of being in a 2 computer case.
hperry 5/4/01 in some cases 4 computers are necessary, each checking the status of the other 3. a c d b e is there any way that the 4 computer scheme can still fail? fault tolerance - redundant processors
hperry 5/4/01 fault tolerance - redundant processors who needs 4 computers and a backup? the space shuttle on ascent and landing/entry the space shuttle uses 4 identical computers and one backup. why? a 1/2 second glitch in the guidance, navigation & control software will cause the shuttle to spin out of control. during rendez-vous and docking, 2 computers are used on orbit, only one computer is necessary in all cases, the backup computer is always available and runs a different set of software than the other 4, a technique known as n- version programming.
hperry 5/4/01 n-version programming same system requirements for multiple implementations the different implementations of code are written by independent teams or contractors eliminates the common software fault issue often used as a backup system
hperry 5/4/01 test documentation
hperry 5/4/01 real time system testing (32) test documentation (test plan / test report) includes an executive summary describes test environment identifies software to be tested identifies tests that will be run on the software includes a requirements traceability matrix describes results of each test may have additional information provided as ? notes ?
hperry 5/4/01 section 1 - executive summary system overview ? purpose of the system ? general operation of the system ? history of system development document overview ? summarize contents of the test plan / report ? summarize key test runs and success/failure of tests ? includes an overall assessment of the project software
hperry 5/4/01 section 2 - software test environment software items under test ? identify what exactly is being tested (i.e. the workstation and handyboard software) components in the software test environment ? identifies operating systems, compilers, communications software, related application software, etc. used to test the workstation & handyboard software ? identify version numbers for the various software test environment hardware and firmware ? identifies computer hardware, interfacing equipment, extra peripherals, etc. used in the testing of the software ? describe purpose of each item software test configuration (diagram)
hperry 5/4/01 section 3 - test identification identify planned tests for the ? . serial i/o thrust controller simulator fuel out indicator altitude and velocity display integrated system
hperry 5/4/01 section 4 - requirements traceability identifies the method used for verification of the requirement: ? analysis ? inspection ? demonstration ? test maps each software requirement to a test
hperry 5/4/01 mit 16.070 requirements matrix for final project rqmt # description method test (if applicable) 1 the system shall be composed of a controller (implemented on a handyboard), a workstation simulation of the mars lander, a graphics package (which shall be supplied to the developer) and a serial interface (cable and software) to connect the controller to the workstation. inspection n/a 2 the mars lander simulation shall begin to execute on the workstation. test 3 the simulation ends when the mars lander softly comes to rest on the surface of mars, when it crashes into the planet, or when it rises above its initial altitude. test demo 4 when the spacecraft is allowed to free fall (no thrust), it shall crash into the mars surface in approximately 16 seconds. test demo 5 with thrust, the user should be able to land the spacecraft softly on mars. test demo 6 the controller shall operate as the user ? s interface to the mars lander vehicle. test 7 upon receipt of a data packet (1 byte) from the simulation, the controller shall: 1. display vehicle altitude and vehicle velocity (both plus & minus) on the handyboard lcd. test demo 8 upon receipt of a data packet (1 byte) from the simulation, the controller shall: 2. light the leds if the ? fuel out ? bit is on. test demo 9 upon receipt of a data packet (1 byte) from the simulation, the controller shall: 3. format a data packet and send it to the simulation. test 10 this data packet shall contain a ? thrust on/off ? indication. when the start button is depressed, the controller shall indicate a ? thrust on ? condition to the simulation. this condition will remain ? on ? until the stop button has been depressed (even through subsequent transmissions of the data packet to the simulation). when the stop button is depressed, the controller shall indicate a ? thrust off ? condition to the simulation. this condition shall remain until the start button is pressed. test 11 the simulation will track fuel remaining and send a flag to the controller identifying when the fuel is out. if the vehicle has run out of fuel, the simulation will not process any more thrust commands from the controller. test
hperry 5/4/01 rqmt # description method test (if applicable) 12 the simulator will have three types of output. it will: 1. send information to the controller specifying altitude, velocity, and whether there is fuel remaining; test 13 the simulator will have three types of output. it will: 2. call a graphics package (provided) that will display a representation of the lander as it descends. the simulator must determine the condition of the vehicle using one of four conditions defined in the graphics package interface section (see "vehicle-condition" variable); test 14 the simulator will have three types of output. it will: 3. write altitude, velocity, thrust and fuel remaining information to a telemetry file using the same format as the simulation in ps8 (plus a fuel remaining column), and write an error message to the telemetry file if the graphics package returns an error condition. test 15 the simulation will end when the vehicle reaches 0 meters of altitude or goes above its initial altitude. test (see rqmt 3) 16 simulation code will interface to the provided graphics package test demo 17 the serial interface should be used to continually send data back and forth between the simulation and the controller. test 17 data sent from the simulation to the controller shall correspond to the provided interface specification test 18 data sent from the controller to the simulation shall correspond to the provided interface specification test section 4 - requirements traceability (continued)
hperry 5/4/01 section 5 - test results includes an overall assessment of the software as demonstrated by the test results identifies any remaining deficiencies, limitations or constraints that were detected by the tests includes recommended improvements in the design, operation or testing of the software includes a writeup of each test ? s results
hperry 5/4/01 section 6 - notes any general information that aids in the understanding of the test report may include ? a list of abbreviations or acronyms ? definitions ? background information ? test rationale ? etc.
hperry 5/4/01 real time system testing - summary over the last 3 lectures, you have learned that test and integration is an important part of developing a real time system. why? a real time system must continue running in the presence of failure therefore, we must design in fault tolerance we must find as many errors as possible before the system goes into use we must be methodical about how we test and document what we learn

▲Up To Search▲

Price & Availability of TL32

	To Download TL32 Datasheet File
If you can't view the Datasheet, Please click here to try to view without PDF Reader .