EETimes

Embedded Systems December 2000 Vol13_13

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

Contents of this Issue

Navigation

Page 137 of 197

= ~ /D discrete variable is shown as a capital le tter. The revised control module is shown in Figure 18. The o utput of the control module was already connected . The source for each input val-iable of this module must now be connected. The input Ur comes directly from the input module ccui. Th us that connection is made, and no additional modules are need- ed for that variable. The input v, is already available as the output of the tderiv module, so th at connection can be made. The reference velocity is a little trickier. It is not obvious where it comes from. As a design decision, let the control mod ule be responsible for setting it. That is, when the set or accel button is pressed on the driver 's cruise control keypad, the control module sets v,. to v,. Thus the control module not only has v,. as an input, but also an o utput feeding back to itself. Once the first draft of tile decom- position is complete, refin ements can be made. For example, the require- ments fo r the cruise control specifY that if the brake pedal is depressed, the crui se control fun ction is deacti- vated just as it would be if tile cIJ-iver deactiva ted it. The designer may choose to have the ccu.i module also monitor tile brake pedal. This refin e- ment, with the control module includ- ed and fully connected, is shown in Figure 19. The purpose of tI1is example is to demonstrate decomposition of an application into components; it is not to provide the reader witl1 the best algorithm fOI- doing crui e control. Further modifications can be made as necessary at this stage of the design to 'atis[y th e needs of the application. Fo r example, to obtain better control system performance, it may be desir- able to implement a more complex algorithm, in which case additional inputs to the control module are needed . To obtain measured accelera- tion (a, ), the tderiv module can be replicated, with v, as the input, and {l, as the output. Applying good technique Design of real-time software compo- nents does not require soph isticated tools. Rather, it requ ires applying good design techniques as o utl ined in this articl e, and d iscipli ne to setup a n applicatio n-independent fram e- work first, the n to create software blocks that adhere to the interface specifications of the framework, so they can easily be plugged in and used . While it is not possible to provide, in this article, all of the details neces- sary to replicate the design, sufficient detai l was provided for the reader to gain an appreciation for what is need- ed. Mo re details are avai lable in tI1e references. [5,9,1f>-201 Sample code Witll more details is also available onlin e. 121 Although it may take a bit of time to setup the initial framework, once that is done, th e fram ework can be reused over and over again . Many of th e software components can also be reused. In turn , th e amo unt of new software that needs to be develo ped for each new application wi ll decrease, and the oftware will be much easier to debug and maintain , due to the str ict modularity that is a side effect of deve lo ping reusable software com po ne n ts. esp Dave Stewart is executive vice president and chief technology officer of Embedded Research Solutions LLC (www.embedded- zone. com), a consu.lting and contracting finn. Prior to that, Dave was di11!Clor of the Software Enginee' ring for Real-Time Systems Laboratory and a faculty 'member in computer engineering at the University of Ma· ryland. His resea'reh has focused on next generation real-time operating system technology and tools to support the raflid design and analysis of component-based real-time software. He has a PhD in com- fJuter engineering from Carnegie Mellon University. His e-mail is dstewart@em.bed- ded-zone. com References 1. Fagan, Michael E. "Design and Code I nspections to Reduce Errors in Program 136 DECEMBER 2000 Embedded Systems Programming Development," IBM Systems Journal, v,15, n.3, pp. 744-751,1976. 2. Software Engineering for Real-Time Systems Laboratory, The Echidna Real- Time Operating System, Dept. of Electrical and Computer Engineering, University of Maryland, www.ece.umd.edu/serts/ echidna. 3. Blake, BA and P. Jalics, "An Assessment of Object-oriented Methods and C++," 1. Obiect-Oriented Programming, v.9, n. 1, Mar.-Apr. 1996, pp. 42-48. 4. Dort, R.C. Modern Control Systems, Third ed. London: Addison-Wesley, 1980. 5. Hassani, M. and D. Stewart, "A Mechanism for Communicating in Dynamically Reconfigurable Embedded Systems," Proc. of High Assurance Systems Engineering Workshop, Washington DC., August 1997. 6. Kelmar, L. and P.K. Khosla, "Automatic Generation of Forward and Inverse Kinematics for a Reconfigurable Modular Manipulator System," Journal of Robotics Systems, v.7, n.4, Aug. 1990, pp. 599-619. 7. Liu, c.L. and J.w. Layland, "Scheduling Algorithms for Multiprogramming in a Hard Real Time Environment," Journal of the ACM, v.20, n.1, Jan. 1973, pp. 44-61 . 8, Molesky, L.D., C. Shen, and G. Ziokapa, "Predictable Synchronization Mechanisms for Multiprocessor Real- Time Systems," The Journal of Real- Time Systems, v.2, n.3 , Sept. 1990, pp. 163-180. 9. Moy, M, and D. Stewart, "An engineer- ing approach to determining sampling rates for switches and sensors in real- time systems," Proc. of Real-Time Applications Symposium, Washington DC, May 2000. 10. Parnas, D.L., Pc. Clements, and D.M. Weiss, "The Modular Structure of Complex Systems," IEEE Trans. Software Eng., v.SE-11, n.3, Mar. 1985, pp. 259- 266. 11 . Schach, S.R. Software Engineering, Second ed. Asken Associates, 1993. 12. Schmitz, D.E., P. K. Khosla, and T. Kanade, "The CMU Reconfigurable Modular Manipulator System," Proc. of

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13