One issue the design team has to face in the process of building a new spacecraft, is to define its mechanical and electrical architecture. The choice of where to place the spacecraft´s electronic equipment is a complex task, since it involves simultaneously many factors, such as the spacecraft´s required position of center of mass, moments of inertia, equipment heat dissipation, integration and servicing issues, among others. Since this is a multidisciplinary task, the early positioning of the spacecraft´s equipment is usually done "manually" by a group of system engineers, heavily based on their experience. It is an interactive process that takes time and hence, as soon as a feasible design is found, it becomes the baseline. This precludes a broader exploration of the design space, which may lead to a suboptimal solution, or worse to a design that will have to be modified later. Recently, it has been shown the potential benefits of automating the process of spacecraft´s equipment layout using optimization techniques. In this paper, a prototype of an Excel ® based tool for multidisciplinary spacecraft equipment layout conception is described. Provided the geometric dimensions, mass and heat dissipation of the equipment, and the available positioning area, the tool can automatically generate many possible trade-off solutions for the layout. It allows the user to set specific equipment to specific areas of positioning, and different combinations of objective functions can be used to drive the design. The features of the tool are shown in a simplified three dimensional problem.

No abstract

No abstract

This paper proposes a Model-Driven Architecture (MDA) approach for the development of real time OnBoard Software (OBS) for satellites starting @om its UML modeling. The MDA definition is considered in a broad sense in which code is (semi-) automatically generated@om more abstract models. A Model-Driven Development (MDD) tool tailored for real time applications is used for sofiware construction, which provides more genera1 resources than just supporting UML documentation and high-level design "drafting". This allows for model execution where one may find problems and issues that whiteboarding and document reviews are unable to pnd. Moreover, an incremental development, based in the 4+1 architectural views, can be effectively attained even at high-level architectural models. A layered model is suggested for the logical architectural view of the OBS domain.

No abstract