From the last decade, the number of software based systems embedded in a car increases every year. The reasons for this evolution are economical as well as technological. On the one hand, this situation is the result of the decreasing cost of hardware components, their increasing reliability and performances and the emergence of embedded fieldbuses; on the other hand, software technology makes easier and less costly the introduction of new functions. Formerly confined to functionalities such as engine or chassis control, this evolution now affects all car domains: wipers, door controls, lights, air condition, braking assistance, multimedia, etc. In the future, even critical functions, as for example, braking or steering, will be fully controlled by electronic systems leading to the X-by-Wire concept. The realization of such systems is obtained through a complex cooperative development process shared by several actors, in particular, OEM (carmakers) and tier-1 suppliers. Furthermore, it's no longer possible to study each system as a stand-alone one and all the partners involved in the design of these systems have to observe a global and common view of the whole embedded architecture. In this context, the main challenge is nowadays to provide means for an efficient development of a safe and optimal embedded system. In this presentation, we will focus on some keywords whose impact and meaning may look antagonist. For example, component, modularity and reusability are recurrent concepts aiming to increase the efficiency of a development while reducing its length. Nevertheless, these principles can be opposed to safety, reliability, dependability purposes. Indeed, the verification of these required properties have to be done on the whole system and not only on a single component. Therefore, we have to complete these first concepts and to introduce the notion of composition of components and moreover of interoperability of components. We will show how this composition can be described through a reference model of embedded architecture that provides on the one hand a standard embedded middleware and on the other hand, an architecture description language. Then, we will focus on the verification of safety/dependability properties and identify which kind of activities they can require and how these activities are related to the first point.