The objective of the activity is to define the global picture of the models needed around On-board Software Reference Architecture (OSRA), their relationship, their ownership, the process to produce and use them, and therefore the need for exchange, and the exchange format. This is an input to the consolidation of the architecture of the software factory.

The definition of the On-board Software Reference Architecture (OSRA) has led to the definition of a main model (the architecture itself, defined in OSRA), supported by other models focusing on specific aspects such as real-time, transaction, bus exchange, etc. or making the link with system such as the Spacecraft Data Base. The space system primes and space software providers have been starting to use various modelling languages (UML or DSLs) and various tools to support their in-house tailored software engineering processes. Since the software engineering process is often distributed among several stakeholders, including suppliers, integrators and clients, it is useful to have a common agreement on interchange formats to import/export such models in order to facilitate the process. The activity includes the following tasks: 1) Following and expanding the OSRA approach, definition of the set of models that are involved in the production (by a software factory) of the on-board software. Identify the existing one, define the missing ones. 2) identification of the industrial use cases, the analysis of needs, and the resulting data exchanges. This include the analysis of the types of models and their detailed content that are interesting to be exported/imported during each SW engineering phase. This analysis shall be based on current and near future foreseen practices at various software space industry stakeholders and shall result in a detailed synthesis accommodating the commonalities and differences. 3) consolidation of the architecture of the software factory. Definition (or reuse) of an interchange format for the data exchange identified above. 4) implementation of the import/export tools from the various stakeholder's models and tools to this interchange format. 5) a case study spread among the various stakeholders to mimic a project in which software is engineered among several organisations and making a proof-of concept of the interchange format and tooling across the software engineering cycle. The software engineering shall comply with ECSS-E-ST-40C and the output of the case study will contain the artefacts expected at the major project milestones and in the end the source code.