EETimes

Embedded Systems December 2000 Vol13_13

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

Contents of this Issue

Navigation

Page 133 of 197

FIGURE 16 Modified sp-lit-pm module to handle manual overrides fra ~ a control frb ~ U / td split-pm plus J minus fdw fde . G~ Force to engine ( wheels Force to wheels ~ pie desired force to be applied to engine can be .hI .. while force applied to wheels can be.hiw' The dashboard inputs may be called measu red veloci- ty (v% ) and measured position (x% ). It is Accelerator pedal ( ~ Brake pedal ~ Cruise control user interface ( dashboard Wheel position resolver Speedometer Odometer J For example, the force for both the engine and wheels should be in Newtons ( ) , while the input to the speedometer is in meters per second (m/ s) or kilometers per ho ur (km/ hr). Of course, the British sy tem of uni ts can also be used; what is imporu'lnt is to be consistent and only use standard units. Do not use raw data values, like a 12-bit value needed by a digital-to-analog converter (DAC). Rather, those conversions will be encapsulated into tlle I/O compo- nents. If performance when using standard units is an issue (for exam- ple, floating point vs. in tege r), address it later during the implementation phase, when the target hardware is taken into consideration. Software decomposition is part of the architec- tural design phase, and should be independent of the target computing hardware. By using tandard uni ts only, each software component can more easily be used in multiple configurations. Furthermore, it makes it vel-y easy to later revise a display module to d isplay in the user's preferred uni ts of mea- surement, such as selecting a digital speedometer to d isplay in eith er km/ hr or mph). In tlle diagram, use mathematical notatio n for tlle variables. Fo r exam- 132 DECEMBER 2000 Embedded Systems Programming control ) fd fdw split-pm ~ J fde ~ Force to engine wheels Force to wheels J ~ engine J important to use formal naming convention here, because it empha- sizes that the most precise way to define a control system is through math. By using these variable names, it is obvious to the control system design- er what are the inputs and outputs. Be sure to create a table that matches these variable names to the full names. Also be consistent. The item th at matches the uni ts of the variable (that is, force, velocity, and so on) are the variable names, and the specific instances of the variable (that is, desired, measured, and so on) are the subscripts. Derme computational modules In the same way that a module was created fo r each I/ O output element, now create the modules for each vari- able needed by one of the output com- ponents. For each module, determine what input would be needed, what is the fun ctio n, and what is its output. For example, the e ngine and wheels each need a force that is output by a speed-control algorithm . If the force to be applied to the vehicle is posi tive, then we wan t .hll'> otherwise we want!dw' We can do this in two possible ways: either as a single control module that produces both outputs, or as a control module with a single force out- put, and a second module that spli ts the variable depending on whether it's positive or negative. The two possibili- ties are shown in Figure 15. Neithe r design is o ptimal; rather, the re are trade-oIls, such that the one that is selected by the designer is based o n which criteria in the system needs to be optimized most. The first versio n results in less modules, and thus may have slightly better pe rfo r- mance and use less memo ry. The exact amoun t of ove rhead used by each component is usually small , but not always negligible.! 19!

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13