EETimes

Embedded Systems December 2000 Vol13_13

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

Contents of this Issue

Navigation

Page 151 of 197

objects to meet some functi o na l objective, and many such organiza- tions are possible. The advantage of separating the logical and physical architectures in this way is that one can change how th e sys tem is deployed (for example, going from one to several processors) withou t altering the logical model. The concurrency mode l de fin es the task threads and the semantic objects they will contain, as well as the policies for selecting tasks to run , to resolve mutual exclusion problems, and so on. The ROPES process defin es about a dozen strategies for identi fy- ing task threads.2 The typical way the concurrency model is derived is to apply one to three task identification strategies to identify the task threads, and then add an "active" object for each. The semantic objects that exe- cute within the task frame of that active object are then added by means of composition relationships. The distribution model defin es how objects will communicate and col- laborate over communication media. This is often done using middleware such as COREA, COM/ DCOM, or a publish-subscribe wagon is extraordinarily safe-l can't get it out of the garagel It is safe, but not reliable. In general, when a system has a fail-safe state (a condition known to be always safe) , safety and reliability are opposing concerns. When a ystem has no fail-safe tate, then improving one requires improving the other. Fina ll y, th e deployment model maps the other models to the underly- ing physical hardware. The mapping can be stati c, as in the case of asym- metric multiprocessing strategies, or dynamic, as is the case with symmetric multiprocessing strategies. Those five aspects of architectural design all occur within th e architec- tural design subphase, although not necessarily a ll within the same spiral or prototype. The next subphase of design is called mechanistic design. It focuses on optimizing individual col- laborations and is, therefore, much more local in scope than architec- tura l design. This is whe re th e com- mon design pa tte rns are applied , such as th e conta in er patte rn o r fa ade patte rn . Both architectural and mechanistic mecha ni sm. Distribution can be managed as asym- metric (objects are dedicated to a sin- gle processor), symmetric (objects can be dynamically loaded to any proces- or depending on current processor loading), or semi-symmetric (object loading maps are computed at boot time) . The safety and reliability model defin es how faults will be identified, localized, and handled and the poli- cies surrounding both reliabili ty and the safety of the system. Many people find the difference between safety and reliability subtle, but the distinction is crucially important fo r a great many systems. Safety refers to the freedom from accidents or losses, while reliabil- i ty refe rs to the probabili t tem will continue to fun ction. A hand- gun is a very reliable piece of equip- ment, but not very safe. On the other hand, my 1972 Plymouth sta tion design proceed largely, although not exclusively, through the application of design patterns. Buschmann et al. pro- vide a numbe r of useful architectural design patte rns while the CoF ("gang of four") patterns book is the standard text for mechan istic design patterns. Detailed design focuses on the inter- nals of individual objects. Usually only 5% to 10% of the classes in a sys tem require special care- either because they are algori thmically or structurally rich. Most classes are fairly obvious, but a small pe rce ntage normally requires extra work. y that the sys- Translation and testing The translation phase takes the design model and produces someth ing that the computer can execute. This can be done either by automatic code gen- eration from the design model, by manual hand-coding, or a combina- tion of the two. Legacy and third-party software are incorporated during this 150 DECEMBER 2000 Embedded Systems Programming phase as well. In the ROPES process, unit testing at the individual class level is performed before objects and com- ponents are permilled for use in team builds. In my experience, this is a tremendous timesaver over the more common approach of throwing the system together and then trying to dis- cover why it doesn't work. The testing phase has two subphas- es. The first is called integration and test. This subphase takes the unit-test- ed components from the translation phase and combines them together to construct the prototype. In doing so, it tests all the inte rfaces among those components to ensure that the system adheres to the subsystem and compo- nentmodel design. This means testing not only the signature of the inter- faces (the easy part) but also the pre- and po t-conditions, exceptions that get thrown across the inte rface, and so on. Integration and test is done according to a preset plan called the integration test plan. This plan can be written as soon as the subsystem and component structure of the prototype is known-that is, the fo llowing sys- tems engineel-ing subphase. The last portion of the testing phase is validation. This tests the con- structed prototype against its mis ion. The mission of a prototype i the set of use cases and requirements to be implemented in the prototype and any additional risk reduction or explorato- ry requirements. Validation testing is done against a validation test plan, which can be written immediately after the requireme nts of the proto- type are defined, that is, afte r the requirements analysis subphase. Summary Although we have only touched the surface of the ROPES process in this article, we have seen that it specifies how to pe rform a number of activities relevant to real-time and embedded systems. We specifically showed, for example, how to iden tify functional and quality of service requirements, how to identify subsystems, and even

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13