【正文】 The automotive domain gives an idea on the increasing demand of software variability management. A modern car can be considered a “distributed system on wheels”: 40 up to over 100 of (8, 16, 32bit) microcontrollers interconnected by a plex work (. LIN, CAN, MOST, Flex ray) is the normal case – as is a 1 l/100 km additional fuel consumption due to the weight of all the work cables. About 35% of the total costs of a car is in the electronics. Automobile electronics, in turn, makes up about 80% of all the innovations in a car. Furthermore, 90% of these innovations e up with software and not hardware. Thus, software is not only a functional issue of the macaronis product “automobile”, but also an economical one of high strategic importance. On the one hand, there is a strong need to reuse software solutions across the different variants and models of a car. On the other hand, in a large number of cases, highly specialized software solutions need to be built depending on the actual car variant or model. Alone relying on, for example, objectoriented approaches to cope with the diversity of problems ing up when developing embeddedsystems software is not enough. Specialization by means of inheritance, ., soon may result in unmentionable class hierarchies if the binational plexity increases. Not to mention the risk of performance loss and large memory footprints in the case of an excessive exploitation of interface inheritance and, thus, late binding. Alternative as well as supplementing approaches are required in order to benefit from object orientation if one wants to develop system software that is reusable and customizable at the same time. In the following, experiences made with the exploitation of wellknown softwareengineering approaches in the design and developments of embedded operating systems are discussed: the program family concept, feature modeling, and aspectoriented programming (AOP). The three approaches are in strong coherence, not only with respect to their history of development. A program family bines the two properties “reusability” and “specialization”. The former relates to mon functions shared by some family members, while the latter refers to the different 嵌入式操作系統(tǒng)可變性的重要 專業(yè)班級：網(wǎng)絡(luò)工程 042 姓名：宋曉波 學(xué)號： 39 4 functions that distinguish family members from each other. Embedded operating systems need to be designed and implemented as a program family, primarily specializing in a given application domain while it is highly desirable to assemble them from as many reusable building blocks as possible. Feature modelling appears to be the suitable technique to circumstantiate the mon and variable properties of and, thus, to anize a program family. Finally, AOP is a technique that allows one to rework a reusable software asset for the purpose of customization/specialization. It is argued that operating systems must be a software product line in order to be specifically prepared for present and future challenges in the embedded systems domain. Motivation of this view is drawn from own experiences in the development of various operating systems for the desktop, parallel, and embedded systems domain . Most of the ideas presented get realized in the scope of the ongoing CiAO project. 2 Causes of variability Variability of operating systems es in different flavours: it may originate from horizontal and/or vertical changes in order to add, remove, port, or specialize functions. These changes can be further classified as static or dynamic, with the former being carried out before and the latter during operatingsystem runtime. In the matter in hand, before runtime means at configuration, pilation, binding, or loading time. In the following, dynamic changes will not be considered mainly because of two reasons. Firstly, prerequisite for a dynamically alterable system is a software structure that aids static changes. It is known for a quite long time that only “a well structured system can easily be understood and modified”. Above all, this implies a kind of holistic software design methodology. If one is unable to identify modularized (“l(fā)oosely coupled”) sections in a program, attempts to restructure this particular program dynamically can hardly be put into practice, if at all: design for static changes e before the dynamic case. Secondly, it is out of character to dynamically change software structures of embedded systems. For quite a large number of embedded systems, not only is scarceness of resources (in terms of memory and 嵌入式操作系統(tǒng)可變性的重要 專業(yè)班級：網(wǎng)絡(luò)工程 042 姓名：宋曉波 學(xué)號： 39 5 energy, .) a handicap for carrying out dynamical changes but also the need for a sustained guarantee of a certain quality of service or adherence to (soft, firm, hard) time limits or safety rules. The ability to changes is motivated in many respects. Examples are debugging, but also