EETimes

Embedded Systems December 2000 Vol13_13

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

Contents of this Issue

Navigation

Page 103 of 197

i n o I = Application-def}endent components are modules used to impleme nt the specific detai ls. of an applica tion. As the name implies, th ese compone nts are not reusable across differe nt applications. Ideall y, these compo- nents are e liminated , since th ey must be redeveloped for each new application. Modules d e fi ned as appli ca tio n-d pende n t componen ts , however, can often be transformed into generic compo- ne nts if an a lgorithmic abstraction of th e module's functionality is pos- sible; th is would result in hard-coded information being converted to vari- able data. The configuration data can th en be obtained from the use r through a te le-operating device or keyboard, from a previously stored configuration in non-volatile RAM or EPROM, f.-om a fil e, or from an exte rnal subsystem, de pending on th e capabi lities offered by the target hardware. FIGURE 1 initia lly Port-based object model The model of a software component described in th is article is targeted specifically to em bedded real-tim e control systems. However, the tech- niques to create a framework and reusable objects that plug into the framework can be applied to other applications as well. The model is based on domain- specific elemental units to maximize usability, fl exibility, and real-time predictability. A framework is designed that uses these elemental un its as building blocks to incremen- ta lly create large r, more complex applications. There al-e two distinct aspects to integrating compone nts. One is to integrate the data paths from an archi- tectural perspective, as described in this section. The other is to integrate the code through use of a framework process and objects that "plug in" to the framework. The independent process is the ele- mental process model that underlies the software componenl. l An inde- pendent process does not have to communicate or synchronize with any other component in the system, mak- ing in tegration simple. A system that is composed only of independent com- ponents, however, is very limiting, because no means exist to share data or resources. Nevertheless, this extreme emphasizes a desire to keep the pieces of the application as self- contained as possible, by minimizing the dependencies between compo- nents. The less dependencies a com- ponent has, the simpler it wi ll be to integrate it into the system. Streenstrup, Arbib, and Manes for- malized the algebra of independent concurrent processes with their port- automaton theory.lI3] They model a concurrent process as an independent automaton that operates on the state of the environment. The communica- Traditional design of a device driver Code executing on the mainprocessor (Process-Flow Driver) Layers of a device driver I/O Filtering RTOS driver interface Device driver Control algorithm Ac~ua~utPut : cmdfi3 Raw data Actuato output Senso data Component-based device driver Component-based device driver Code executing on the main processor (Data-Flow Driver) Control algorithm I/O Sensor Electronics \ Actuator Sensor I/O Electronics Actuator 102 DECEMBER 2000 Embedded Systems Programming

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13