EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 129 of 197

i s a FICiURE 12 - .. . ... . Output module software from one hardware plat- form to anothe r. As an example, consider the design Actuator FICiURE 13 Input Elements ( accel Accelerator pedal brake t Brake pedal ccui t Cruise control user interface t ( position Wheel position resolver t pie communication. For example, in a manufacturing plant, the application may consi t of multiple robots per- forming assembly and a conveyor belt calTying the part from one robot to the next. In such a case, each robot would be its own subsystem, and inte- gratio n of the subsystems would be accomplished through the conveyor belt and its corresponding software. As a nother example, the computing needs 01" an automobile may be split into subsystems based on the person- nel needed to build each. One subsys- tem may be the fuel injection ; another ) ( Speedometer • ) ( ( engine Force to engine Wheels Force to wheels • • dashboard Odometer • the speed con trol; a third is the entertainment ystem, and a fourth is a distributed network that contains processors for all of the power locks and windows. De fin ition of a subsystem should not be based o n the targe t hardware. Rathe r, base each subsystem on a phys ical or fun ctiona l e ntity that can be tested inde pende ntly. It does not matter whe the r a subsystem is spread across multip l processors, or a sin- gle processo r consists of multiple subsys tems. Whe n using compone nt- based software, it is easy to move 128 DECEMBER 2000 Embedded Systems Programming ) ) Output Elements of an automotive speed con tro l subsys- tem. The goal of a cruise control sub- system is to maintain a constant veloc- ity of the car despite the presence of real forces such as friction and gravity. The velocity of th car is continuously monitored. If the car slows down to below the desired speed, mo re gas is given to speed up the car. If the car speed up due to going down a hi ll , th e accelerator releases, and if neces- sa ry, the brake is applied lightly. The driver must also be able to override the cruise control function, by press- ing on the brake or accelerator pedal instead of tll e buttons that form the cru ise control user interface. There are no precise rules for decomposition. Most engineers rely on prior expertise. New engineers use common sense, but do not necessari ly end up with the best design. As a more systematic method of spli tting the sub- system into components, the fo llowing guideli nes are offered . These guide- lines can help yie ld a pretty good first draft of the components in the system. Further refinement is often needed, either by decomposing some blocks further, merging othe r blocks th at are very similar, or modifying tlle fun c- tionali ty to prope rly meet all require- ments. It is important to understand that in such a design, there is no right answer. However, when comparing two different designs, specific q uestions can be asked to compare whether one design is beller than anoth er; such questions are d ispersed througho ut the fo llowing discussion. Create one module for each output I / O element The starting point for any subsystem should be the I/O elements. An I/O element is a sensor, switch, light, actu- ator, or other application-dependent item, or communication to an ex ter- nal subsystem. An I/O element is not an I/O port, such as serial or parallel port. Rather, an I/ O port is encapsu-

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13