<div class="section abstract"><div class="htmlview paragraph">The development process of space mission software has to go through numerous steps, from early dimensioning factors at system level (e.g. energy to be consumed by a system, weight of equipment) to the description of low-level software concerns (tasks period, etc.). Most of the time, mission components are taken or derived from existing projects and use well-known best practices: hardware and software concerns are designed from a set of existing components, and are usually well tested and documented. However, teams, with different technical backgrounds, and development approaches, achieve the design. This adds incidental complexity to the design of a common architecture and its verification. Consequently, even if design of new systems is close to existing ones, the recurring key challenge is to reconcile the different views built by these teams, and to ensure that all properties are preserved and validated. This calls for an integrated process that would combine modeling, refinement and incremental validation.</div><div class="htmlview paragraph">To investigate potential approaches that would overcome these issues, the European Space Agency commissioned a study to evaluate AADLv2 modeling patterns to support such a process, and ensure consistency between each development step. This is an extension of the TASTE (<b>see <span class="xref">reference 8</span></b>) process that tackles the implementation of systems from a well-defined architecture of the system, which is also based on AADLv2.</div><div class="htmlview paragraph">This paper reports the current state of our investigations. Here is an outline of our contribution: <ol class="list nostyle"><li class="list-item"><span class="li-label">1</span><div class="htmlview paragraph">Properties have been defined to represent dimensioning factors; a root system is built to represent the mission parameters.</div></li><li class="list-item"><span class="li-label">2</span><div class="htmlview paragraph">A set of abstract functions is built from the mission requirements. These functions host the high-level view of the function blocks (name, interface, data types, etc.) and are instantiated in one system implementation that represents the high-level view of the functions to be implemented, with a specific resource budget (computing capacity, power supply, etc.).</div></li><li class="list-item"><span class="li-label">3</span><div class="htmlview paragraph">In parallel, platform integrators provide an AADL model of each of their components. These models are an abstraction of their corresponding datasheet, making visible some of their properties. These models are used to build one or several implementation candidates for the mission platform. From their properties, one can validate that the platform matches the overall mission parameters.</div></li><li class="list-item"><span class="li-label">4</span><div class="htmlview paragraph">Finally, a validation system is defined. This model maps elements from the functional design to the implementation one. This allows in-depth checking of the budget allocated to each function, but also to check for functional coverage using the REAL AADLv2 annex language.</div></li></ol></div><div class="htmlview paragraph">By using only AADLv2 constructs, we can use existing tools for analysis and implementations from the TASTE toolset (Ocarina, REAL, graphical modeling tools). In the future, we contemplate extending them with specific GUIs and graphical DSL to support each step. This capability is interesting for supporting system engineers that do not want to enter into the intrinsic of MDE frameworks, should it be plain AADL or UML and its extensions.</div></div>