A. Embedded Systems
Model Driven Engineering as we deal with it in this chapter is related to embedded systems design. An embedded system is the information processing and controlling part that is embedded in another (the embedding) systems, e.g., a copier or MRI scanner. The embedded system plays a controlling or monitoring role in the embedding (or hosting) system. Typically, embedded systems communicate to their embedding systems by actuators and sensors, not by human communication. This makes embedded systems different from information systems. Nowadays, embedded systems can be found everywhere. For example in cars, copiers, cameras, cell phones.
Embedded systems are complex, because of for example, but not constrained to, their heterogeneity, concurrency and power constraints. One reason that they are complex is simply that they are big systems, e.g.,: the effort to develop them is huge, they contain many lines of code. Embedded systems are heterogeneous because they are built out of various components, including software processes, processors, accelerators, memories, busses and networks. To design a component, assumptions have to be made about other (heterogeneous) components in the system. Since embedded systems observe and control many parts of their embedding system, multiple processes have to run in parallel. This requires concurrent handling. Many embedded systems have limited power supplies such as batteries. Battery use stresses the importance of energy constraints in embedded systems. For example, because they are portable (like cell phones), are implanted in humans (like medical devices) or are used in isolated areas (like wireless detection devices).
Characterizing Embedded Systems Design
Embedded systems design aims at the design of complex information processing (sub)systems that will meet their requirements (functional as well as non-functional). The design should be done in a cost-effective way and should deliver the product in time (time-to-market). An embedded system design will therefore be judged by three main criteria: quality, effort and time. Because of the growing system complexity, a methodological approach or design flow is needed to meet these criteria. The design flow is the set of design activities (cf. method or development process, like Rational Unified Process (RUP)) needed to develop the system. An example of a design flow is the ordered set of activities: requirements definition, design and development, integration & testing and releasing, as shown in Figure 1.a. Other appearances of a design flow exist. For example, because of the experience that phases are not strictly separated but are intertwined (figure 1.b) or because of that other terminology is used for defining the phases (figure 1.c). Software tools are used to support the implementation of a design flow.
Embedded system design is often characterized as co-design of hardware and software (Wolf, 2003). For example, computer architecture provides designers with information about performance and energy consumption of processors. Knowledge about hardware components, and their cost, is needed to design software in a way that a cost-efficient system results that will meet its requirements. The embedding system might include involvement of other disciplines as well. Often disciplines are involved such as control engineering, electrical engineering and mechanical engineering. Taking more disciplines into account than software and hardware is denoted as multidisciplinary approach (Heemels & Muller, 2006). Each of these disciplines uses its own terminology, models of computation and tools. Knowledge about each of the disciplines and its interaction with other disciplines is needed to design embedding systems, such as a printer.
In this chapter, we focus on the design flow of embedded systems, more specifically: hardware and software co-design. This design flow will often be part of the development process of an embedding system. Therefore there will be an interaction of the design flow with multidisciplinary development. After having specified the (high-level and low-level) system requirements, the design phase starts which involves disciplines such as mechanical engineering, electrical engineering and software engineering. Although these disciplines are tightly coupled in the final system, their development is traditionally carried out in a rather mono-disciplinary and independent fashion, and the engineering results are delivered in a sequential way. Conventionally, first the mechanical subsystem is designed, then the hardware and finally the software.