Space Systems Development

Abstract

This chapter describes the Space cluster use case using the innovative Space Tug project as an example. It provides an overview of the objectives (customer in the loop, quicker technical response) and related methods to support foreseen improvements through a dedicated toolchain. The IT infrastructure used for the demonstration is used as an enabling and demonstrative system with a focus on modelling and collaboration aspects, as outlined in Chapter “Extending the System Model”, on the flow of information, and on tool infrastructure and project costs. Descriptions of the developed tools are as follows:

• A web-based toolchain that includes functional analysis, discipline analysis, 3D modelling and virtual reality for project team collaboration.

• A workflow manager for collaboration between different companies.

• Small devices called ‘probes’ to ensure security and data protection in intercompany collaboration.

• A configurable customer front-end to ensure that the customer remains informed.

1 Introduction

1.1 Competition and Challenges in the Space Industry

The space era started during the Cold War, and tight competition between USA and USSR accelerated technological achievements, enabling the launch of an artificial satellite in 1957, the survival of a human orbiting the Earth in 1961 and landing on the Moon in 1969. This challenge led to a dramatic change, bringing a legacy of technologies that are evident to any person using a map, navigating using a GPS or using one of the many technologies that emerged from space research.

Currently, there are more than one thousand active artificial satellites, most of which are telecommunication and Earth observation satellites that monitor the environment, support disaster management, provide data to the scientific community, and support civil protection and military operations. There is also an outpost with a permanent crew of six people orbiting the Earth. There are also spacecraft exploring our solar system; observing or landing on planets, comets and asteroids; and telescopes observing the farthest zones of our universe.

Sixty years after the first artificial satellite, new challenges that are very different from those of the 20th century have arisen and may lead to improvements and progress for humanity. Examples of current challenges can be found in the roadmaps of the International Space Exploration Coordination Group (ISECG 2016), regarding a return to the Moon, paving the way for a human landing on Mars, and the current attempts to enhance satellite coverage to enable high-speed internet access using satellites.

What has changed in recent years? The current trends highlighted in the OECD (Organisation for Economic Co-operation and Development) report (OECD 2014) on the space economy reveal that:

• Competition is increasing. “Major challenges lie ahead both for the incumbents and for the new entrants into the space economy. In a globalised world, few sectors are sheltered from competition as the rapidly evolving global value chains in the space sector demonstrate. In addition, a new industrial revolution is looming on the horizon which holds out the prospect of deep-seated change in the traditional space industry” (OECD 2014).

• Industrial complexity is increasing. “private industry supply chains are getting more complex, influenced by the multinational nature of major space companies” (OECD 2014).

• Exploration Missions are becoming more complex and require international collaboration (ISECG 2016).

• An additional commercial market is growing. “The key drivers for more globalisation will include sustained institutional support from new sources worldwide, double sourcing guaranteed on the market offering new commercial opportunities, and a wider global addressable market size for all actors” (OECD 2014).

• National space budgets are not increasing. The space budget as a share of the GDP in European countries varies from 0.05 to 0.10% (OECD 2014).

Economy-driven and economy-driving challenges are expected in the future. The space industry is experienced and has technological capabilities. New improvements are needed to manage the prospective constraints that future scenarios involve. Among the many possible improvements (e.g., in product policies or technological R&D), this section analyses and proposes a solution for preparation of complex solutions by complex technical teams with continuous customer involvement.

1.2 Speeding up the Interdisciplinary Approach for a Quicker Response to the Customer

Adaptation to customer demand, continuous upgrades of provided services and products, and a quicker response to the customer are needed to manage the future space economy. These objectives of the Use-it-Wisely (UIW) project were analysed by the space cluster regarding the improvement of capabilities and efficiency of technical work.

The space industry handles complex products in a complex industrial organization that typically includes the customer; the customer participates in the design, verification and operations loops with engineering, scientific and high-tech capabilities. Customers may make decisions based on many key factors, such as political constraints (e.g., geographical return for member states in the case of the European Space Agency), the soundness of the solution, costs, schedule, and risks. For a commercial customer, the ability to quickly respond with an appropriate solution with the highest possible confidence that it meets the related needs is essential. The more complex the proposed solution is, the more of the following issues may appear:

• Understanding of real needs and constraints: the expressed needs and constraints may be incomplete or provided without a clear rationale (for instance, providing costly constraints that can be drastically reduced using alternative concepts).

• Feedback capture: customer feedback is essential to providing an alternative solution or to improving future products/services quickly.

• Traceability: the customer and user needs should be traced to the technical solution, changes should be clearly identified and their impact traced in the technical solution and retained for future evolution of the product.

The needs that arise from a customer-supplier relationship can be further broken down into technical team-level requirements:

• Responding to customer (or potential customer) requests or changes quickly, while managing complex technical issues in a distributed team, managing a large amount of technical data in a distributed team, and maintaining the required levels of quality and risks.

• Clearly presenting the technical solution to a potential customer, showing the advantages with regards to competitors by providing information at different levels of detail, clearly supporting any proposal for change by describing the advantages to the customer, and using clear, complete and visual means to show the solution and related operations (e.g., using simulation and 3D graphics).

1.3 The Proposed Solution

The proposed solution is based on analysis of an operational scenario, simplified but without loss of generality, comprising the following entities:

• The (potential) customer technical team: in charge of providing the needs and technically evaluating the solution or proposed changes.

• The solution provider technical team: manages the solution for the entire industrial team and acting as the main interface with the customer.

• The supplier technical team: a supplier of the solution provider, maintained in the loop to elaborate the solution.

As described in Chapter “Extending the System Model”, modelling methodologies are expected to provide advantages for technical (and project) data management. Moreover, the current trends in industry show extensive usage of MBSE (model-based systems engineering) methodologies, the quality and benefits of which should grow in the upcoming decades.

The solution is a federated environment in which each of the actors from the aforementioned operational entities can work in a distributed model-based environment that fits their organization and their needs. Such a federated environment is based on the following assumptions:

• Each environment is web-based, meaning that the models can be accessed through dedicated services available on the company network (with security restrictions). This is already the case for some commercial or custom tools and the current trend is to move towards web-based solutions.

• Any technical discipline can profit from such a system-level environment to retrieve required information from the other disciplines and to provide the system-level information required to the other entities.

• The web-based environment shall be semantically unique, i.e., the data can be retrieved, inserted and processed univocally by a human operator or an automated routine programmed by an operator independent of the data originator/owner. This is explained in detail in Chapter “Extending the System Model”. ECSS-E-TM-10-23A technical memorandum (ECSS 2016) describes the current effort in the European space domain to proceed towards an interoperable space systems data repository.

Based on the experience we have gained with model-based environments in recent years, difficulties arise in handling the interoperability of environments and security requirement compliance. These include four main issues, with related solutions:

• Data compatibility: solved using data semantics and well-defined and generic interfaces.

• Workflow realization: solved using the concept of services-based exchange between different entities and dedicated task definition and realization managers.

• Data security: solved using semantics and dedicated processes that allow a filtered exchange of information, clearly identifying what data exit the company network perimeter.

• Cost and maintainability of the IT infrastructure: solved using integration between tools that is based not on tool versions or custom formats but on mapping to common semantic data models or custom data structures defined at the user level (not at the tool vendor level).

The evaluation of a solution that follows such assumptions and constraints is performed for a demonstrative case. It is based on the future provision of an unconventional space-to-space re-utilizable product: a type of taxi service in space to move spacecraft from one position (orbit) to another that provides other servicing options. This concept is typically called Space Tug¹ and is assumed to be proposed as service to a commercial customer who decides to use this service or not based on their requirements.

This case was used because it includes a high level of complexity and can be briefly described and divided by entity:

• Customer:

  • Commercial customer: not constrained by political decisions or national budget allocation, intense worldwide competition.

  • Needs are (1) to determine if the proposed solution is effective, valid and advantageous, (2) to be supported during its design phase to eventually de-risk the interface with the Space Tug system, and (3) to be supported during operations.

• Solution Provider:

  • Provides the Space Tug, which will provide In-space Services: the Tug interfaces with the customer system or a dedicated interface, and related operations are coordinated.

  • Services provided are (1) engineering/project services provided to a potential customer during the preliminary design phase: to decide if the in-space service is suitable for its needs. (2) Engineering/Project Services provided to a customer during the design phase: to support any evaluation or potential changes and upgrades. (3) Engineering/Project Services provided to a customer during the operations: to support the operations and potential anomaly investigations or upgrade requested services.

• Supplier:

  • Provides the Ground Segment and the Ground Operations teams and manages operations.

  • Services provided are (1) engineering/Project Services provided to the solution provider to complement the space segment solution with ground-related operations, and (2) engineering/Project Services provided to the customer to support operations.

The following chapters show how the space cluster of the UIW project analysed a potential solution to support such actors and process. The space cluster is composed of Thales Alenia Space, ALTEC and Vastalla.

Thales Alenia Space has designed, integrated, tested, operated and delivered innovative space systems for 40 years. The UIW-project relied on the experience of the Collaborative System Engineering (COSE) Centre (at the TAS Turin site) on virtual reality, model-based interdisciplinary data exchange and systems engineering, and the design of exploration and science spacecraft.

The Aerospace Logistics Technology Engineering Company (ALTEC) is an Italian centre of excellence for the provision of engineering and logistics services to support International Space Station operations and utilization and the development and implementation of planetary exploration missions. The experience related to engineering and operations and competence in virtual reality and model-based design possessed by ALTEC were used in the project.

Vastalla is an IT company that offers consulting services, software development and IT system activities with an emphasis on IT security. Its experience was used for the collaboration portion of the overall solution and for the customer front-end.

1.4 Chapter Outline

Section 2 provides an overview of the application of the proposed solution. Section 3 provides a description of the demonstration and its outcomes. Section 4 provides conclusions and describes possible future applications.

2 Detailed Application of the Solution to Overcome the Challenges

2.1 The Users-Tools Functional Chain

The issues and considerations in Sect. 1 are translated into a modelling and collaboration methodology, a reference logical architecture and a tool chain to provide a demonstrative case to validate the approach.

Figure 1 shows the functional architecture of this tool chain, with the related tools or responsibilities implemented in the UIW-demonstration. The architecture is defined using a model-based approach with the ARCADIA methodology and Capella tool notation (Polarsys 2016)

Fig. 1

Logical architecture of the solution

For simplicity, the MBSE interdisciplinary and distributed environment is depicted only for the solution provider side and includes:

• System Models, Simulation Models and Services Process manager: this functional block is needed to support the interdisciplinary work between people and discipline-specific tools through dedicated adapters. This functional block also includes the definition of Engineering or Project Services to be provided to a customer.

• System Simulation and Visualization: this functional block is needed to support the visualization of the product, activities and simulation results.

• Simulation Execution: this functional block is needed to provide system level simulation, integrate discipline-level simulations, or provide early system-level simulation.

• Extranet Interface: this functional block is the gatekeeper that assures a safe flow of data.

On the customer side, we need to be able to respond to requests based on the services provided. Moreover, some services must be provided globally (e.g., workflow management) and could be allocated to a third-party such as an IT services provider, namely:

• Workflow Control: this functional block orchestrates the flow of information between actors.

• Communication Tools: this functional block allows for controlled communications that are external to the typical communication means.

• Repository: this functional block allows for a controlled repository of shared data.

On the supplier side, the MBSE environment is not explicit and is called Mission Control, based on the related function in the demonstration.

This functional architecture is then translated into a physical architecture, i.e., actual tools and applications, used in the UIW-project to provide an answer to the project challenges addressed in the first chapters of this book.

Maintaining customer involvement from the beginning is very important to guarantee the success of complex projects that manage extensive structured data, many companies working together, and many actors in the supply chain. In these business cases, supplier-generated feasibility and cost estimates take several days, so it is of paramount importance to keep the customer in the loop from the first day. Tools that maintain an appropriate flow of information to the customer can be easily deployed.

Customers can access a web application that acts as a bridge between them and the suppliers. This web application is called the Request Configurator, developed by Vastalla. Using this web application, customers can login, request new quotations for an array of commercial Space services, review past requests, or order a commercial Space service.

This web application is closely connected to other software modules that form the backbone of the IT infrastructure and allow for a smooth relationship with the customers.

Customers are in the loop. This mean that they are informed in real time about the current state of their requests. Furthermore, they can exchange relevant information that allows the suppliers to correctly quote the requested service.

All requests, past and present, are managed by the Workflow Manager developed by Vastalla. This software component traces the status of requests along workflows. These workflows differ one from another depending on the commercial Space service being requested. The Workflow manager is an API-based software that is automatically configured (on-the-fly dynamic configuration) by the Web Environment. The Workflow Manager is designed as an open software that easily integrates with other software components through pre-defined APIs.

The Web Environment is the software component that generates the commercial Space services workflows. The dialogue between the Workflow Manager and the Web Environment is mediated by the probes, small devices that act as gatekeepers of the communication flow between the Intranet portion of the global infrastructure architecture and the common Workflow Manager.

The probes are very small devices (approximately the size of a cigarette pack) that use Raspberry Pi technology (Rapsberry 2016) and have the capability to filter the IP traffic going through them to allow only legitimate traffic to pass to the Workflow Manager. The probes act as gatekeepers and can be implemented as separate devices depending on company decisions. For demonstrative purposes, Raspberry PI^® devices have been deployed (Fig. 2).

Fig. 2

Request configurator user interface and physical implementation of a probe (Raspberry Pi^®)

The Web Environment is part of the TAS DEVICE (Distributed Environment for Virtual Integrated Collaborative Engineering) Architecture (Pasquinelli et al. 2014), which also comprises the Virtual Environment (VERITAS) and the adapter to the discipline-specific tools. For this demonstration, a CAD adapter called RAP (Retrieve cAd Parameters, internal TAS development) is used. Modelica (Modelica Association 2016) is used as the language for the low-fidelity system-level simulation using OpenModelica (OpenModelica 2016) or Dymola (Dassault Systemes 2016) to execute the code.

The Web Environment is a model-based and web-based operational prototype developed by TAS that is inspired by the current European space domain efforts (e.g., ECSS-E-TM-10-23A (ESA 2016) and ECSS-E-TM-10-25A (ECSS 2016) technical memoranda), OMG efforts (OMG 2016) and THALES corporate-level (see Capella (Polarsys 2016)) initiatives but with a clear objective of enabling a social-technical network of people and tools to collaborate on technical solutions.

It is worth noting that the solution described in this section is a demonstrative research case to demonstrate and validate the architecture and methodology and that these prototype tools have not been deployed in the TAS or ALTEC networks.

The application of MBSE methodology is helpful not only during the design phases but also during the operational scenario of a Space system (Cencetti 2014). A model-based approach allows for better organization of the information that characterizes the execution of a space mission. The definition of a structured data pattern can help manage the information and ensure a more straightforward connection with the product baseline.

Elaboration of the information that emerges from a complex system is often not easy to manage during an operational scenario. For example, manned spacecraft and other classes of space systems are often characterized by a broad set of parameters, subsystems and data that must be properly understood and monitored to avoid incorrect interpretation of actual scenarios. Troubleshooting activities often require the retrieval and analysis of system documentation, which are generally difficult to perform when the information is not collected in a structured manner. These issues also arise during the design phases of a complex system when different domains are involved and many people with different backgrounds and skills collaborate on the same project. All the information generated during the design process is generally used during the operational phase in management of the space system. Space Operations are currently investigating and developing innovative solutions for exploiting system data. The increasing complexity of aerospace products leads to increasingly difficult management of available resources and telemetry data. From the literature, it is possible to see how different research initiatives address the definition and assessment of more effective approaches than the traditional ones. For example, web-based frameworks and MBSE methodologies are some of the research topics that are starting to spread across different phases of the spacecraft lifecycle, from design activities to dismissal processes. In the last few years, the development of MBSE design and analysis methodologies has gained increasing interest in the industry. The implementation of design solutions that ensure more effective management of system information allows for significant time and cost reductions.

Examples in academic literature show how the application of MBSE starting from the preliminary design phases can ensure more straightforward information management during operational activities.

A model-based approach can generally be used to support two main aspects of the product lifecycle: operational design process and space mission execution.

The main objective of the operational design process is to focus on organization of all the activities that will characterize the actual space mission. This process mainly addresses the design of the features of the operational phase. The same concepts can also be used during the execution of the real mission, ensuring a better connection between the data generated during the design process and the available information, e.g., telemetry. Examples of elements that characterize the design and organization of the operational phases are:

• Launcher constraints

• Ground station characteristics

• Spacecraft constraints

• Mission-specific constraints

• Payload constraints

• Launch window prediction

• Spacecraft and launch vehicle separation sequence

• Positioning and manoeuvring strategy

• Tracking schedule

• Scheduling operational events

• Ground station coverage

• Impact of the space environment on operations

• Payload operations strategy

• Data circulation scheme

• Feasibility of the mission

• Operational feasibility of the mission

• Mission operations concepts

• Ground segment internal and external interfaces

• Format and method of data exchange

• Data processing tools

• Mission operations team organization (preparation and execution phases)

• Testing strategies, methods and scenarios

These functions and processes represent some of the key elements that characterize the ground system and operations domain (ECSS 2008).

The information collected during design activities can be used to support preliminary analyses of a space mission with dedicated simulators of system performance. These data allow for more effective generation of simulation scenarios than in traditional approaches. A model-based philosophy ensures a seamless connection and consistency with the available baseline data. Analyses such as mission feasibility or ground station coverage can be performed within the same environment.

The design parameters of a system or equipment can be mapped with data such as telemetry to allow a direct connection with the product baseline. Thus, it is potentially easier to recover information for troubleshooting or anomaly characterization. The monitoring of a specific variable can be better supported if the operational range and other information are linked to reduce issues that can arise, as in the error-prone process of data retrieval from documentation.

The use of a model-based approach from the preliminary design activities to production can also benefit the operational phases. The information collected in a common system model can be used to properly support operational scenarios because the data can be navigated and tracked more consistently.

2.2 Development Innovation

When new methodologies are introduced in a company, there is some natural resistance due to the cost of the introduction and maintenance of a prospective new or updated tool chain, as well as the need for users to adapt their comfort zones. This has been experienced by the authors of this chapter in many fields.

Currently, the actual evolution of a concept into improved ways of working should be evaluated from a technical innovation perspective and also from business innovation and IT perspectives. The latter two are not trivial, especially the IT perspective. Many medium-large companies rely on complex software infrastructure, and even if their processes are acceptable and independent from the IT tools, daily work and related infrastructure costs are highly impacted. Therefore, the Space cluster scenario considered two main issues: (1) Tool interoperability and the maintenance cost of the interfaces, and (2) security and collaboration between different networks.

The first issue is easy to identify in any tool chain. Any tool has input/output capabilities and typically has custom interfaces or standard interfaces (e.g., using reference formats common for that type of application). For models, the model data interchange format is quite difficult to exchange because even if it is based on standard languages or semantics, the user typically enhances it for their own purposes to create a new “dialect” of the language or can base their interfaces on custom object libraries.

Moreover, format updates, tool updates and even technological updates can add to the high maintenance cost of the original tool interfaces.

The second issue is very critical, considering that company network security is a very sensitive topic, especially in companies that handle confidential data (e.g., working on protected innovation or with governments or military entities). Security is a continuous issue that limits the effectiveness of the daily work of those collaborating with an entity external to its network. The solutions studied by the space cluster in the UIW-project were:

• (1) Use of semantic models to define the product, activities, services, actors, requirements and needs.

• (2) Use of probes as interfaces between networks, profiting from the semantics of the I/O data.

• (3) Simplification of interfaces and user-oriented management of the models and related formats.

There are many initiatives related to the enhancement of semantics in data generation, management and exchange. In our case, we used a simplified approach based on:

• Class diagrams to represent semantic classes, attributes and relationships; these class diagrams can be transformed into classes in an object-oriented language or simply mapped or transformed to data exchange formats using specific rules.

• Libraries of objects, specific to the domain or the project, to provide an additional level of semantics for the technical toolchain or to enhance the user experience.

Figure 3 shows an example of how the use of such class diagrams improved tool interoperability. The definition of services, as in the Web Environment, is read by the Request Configurator and used to create the customer form. The two tools were developed by two different people using different languages. To adapt the interfaces, a meeting on the semantics and a meeting on the integration tests were sufficient to produce a working prototype.

Fig. 3

Example class diagram representing the data model of a service (partial view)

The Web Environment tool is based on a complex data model with more than one hundred classes (and related relationships) but the most important level of semantics is the possibility for the user to generate libraries of categories, properties and other types of knowledge based on their experience and specific expertise.

The Probes are compact devices that, from a hardware point of view, are Raspberry Pi devices: they have enough computational power and overall features to perform their task in the architecture. The Probes host business logic together with the necessary tools for managing the traffic and requests that goes through them. Disclosure properties are tagged within the data so the Probes can communicate to the Workflow Manager how to treat different data flows depending on the tag.

The software on the Probes consists of an open source framework (nodejs 2016) that is based on a Linux distribution tailored for Raspberry Pi devices [Raspbian (Rapsberry 2016)]. The Probes primarily exchange JSON files with the upper and lower parts of the architecture.

The innovative standpoint is that some tasks that were once delegated to complex and expensive ad hoc-designed appliances can now be largely replaced by very simple devices that have enough computing power and features to filter TCP/IP traffic efficiently and offer programmers a flexible platform to easily develop programs.

The Request Configurator and the Workflow Manager are software components that can be programmed dynamically using an API-based paradigm.

In our case, the Request Configurator and the Workflow Manager are programmed in real time from the Web Environment. This means these systems are not rigid or static from a design point of view.

Thus, the Web Environment can leverage these capabilities, and engineers who work on the Web Environment can change workflows on their side and these changes are automatically mirrored in other parts of the architecture without the need to reprogram the source code.

This is a clear advantage because it summarizes the advantages of decoupling systems and seamless integration using publicly available APIs.

Information tagging helps to preserve data privacy. Some data needs to be disclosed to the customer whereas other data might not. Some data needs to be disclosed to other parts of the supply chain/toolchain and so the Probes handle this part along with the Workflow Manager.

2.3 Results

Space Cluster’s objective was to build a Model-Based Collaborative Environment for collaboration through the entire lifecycle and technical activities that involves potential customers and the industrial consortium.

The approach used by the Cluster to achieve this objective is described in the architecture below (Fig. 4).

Fig. 4

Physical architecture of the overall demonstrative environment

The components of this architecture show the processes and tools developed by the Space Cluster within the UIW-project. They have been upgraded and improved during each iteration until obtaining tool interoperability at the end of Trial 3. The main achievements of these upgrade process are summarized below:

• It was possible to show how the logical architecture was implemented in the physical architecture and interoperability of the tools.

• The web-based Engineering Environment can define and expose services.

• The service requested by the user can be composed of several tasks defined in the Web Environment. A task is used to manage the flow of information or provide the customer feedback on the current status because it is possible to associate data and potential statuses with each task.

• Tasks can be visualized in a tree map to manage and understand the service more easily.

• The connection between the Request Web Configurator (RC) and the probe was successfully defined and tested and the Workflow Manager enabled management of the flow of data and information between the probe and the RC.

• All the actors involved in the process were successfully involved. ALTEC Mission Control was implemented and defined in the Web Environment.

• The tools that are part of the prototype were rapidly integrated.

The purpose of the demonstration phase is to create an end-to-end process to validate the tools and the related methodologies and acquire feedback from end users and process stakeholders.

3 Outcomes from the Application

3.1 Benefits of the Methodology and Related Tools

There are three main aspects in which benefits were demonstrated: (1) Support software development and maintenance, (2) user experience, and (3) potential impacts on the project. Regarding software aspects, the methodology chosen for the Request Configurator, Workflow Manager and Probes allows for easy integration of different components using APIs. Furthermore, maintenance of the software components is easier, leveraging on existing and widespread programming frameworks (Fig. 5).

Fig. 5

Sample images from the request configurator

Using APIs enables easily extending the features of the software components, provided they are designed with APIs in mind.

The methodology used to develop the Engineering distributed architecture, i.e., web-based tools for collaboration, visual supports (VR and in-browser 3D/2D visualization), web APIs for model-to-tools interfaces and use of data models and libraries for semantics, enabled the development, modification and integration of a complex environment using a rapid prototyping approach and rapid evaluation of outcomes (Fig. 6).

Fig. 6

Web modelling environment and virtual reality data accessible using simple but effective technologies

Regarding user experience, at first glance, the user is typically afraid of new tools and methodologies. The feedback gained from a preliminary dry run of the demonstration (a complete demonstration is planned a month after the conclusion of this chapter) showed interest from the participants, the user interface and process felt comfortable and were seen as potentially improving efficiency in daily work. The main aspects that were appreciated were:

• The availability of all the information in an easily accessible format, saving time searching for data or verifying that the data is the latest. In late phases of the project, this is typically well established with current processes that strictly control the baselines and changes but these processes are typically too expensive in early phases and for quick upgrades. A methodology similar to the one presented is expected to bring a new perspective in this sense.

• The presentation of information for any type of user (visual 3D/2D data and tables available in the browser) allows for a clear understanding by the entire team at a glance.

• The possibility for more controlled communication with external entities is considered a great improvement that has become particularly critical recently (due to security limitations).

• The possibility of a direct and controlled link with many customers is considered as potentially improving the relationships during the upgrade or order process and to store experience and retain customer feedback for future reference.

Visualization capabilities can also be used to support data exploitation and graphical elements can be generated based on data available from the system model. Thus, information can be exchanged in a more straightforward manner. An example of an orbital representation is provided in Fig. 7. Both the analytical solution (conics) and the numerical solution can be represented using the same interface.

Fig. 7

Orbit visualization capabilities

Regarding potential programme improvements, the use of an MBSE methodology within the context of operational scenarios leads to several advantages over traditional approaches. The definition of a structured system model that includes all the elements pertaining to the actual space mission positively affects the management of a space system. This approach reduces the time and resources needed during the design phase because data are managed in a structured manner. For example, the documentation can be generated in a straightforward manner to reduce the time spent on version control, consistency verification and updates. In the same manner, a model-based approach can also be used to support the management activities for a space system during a mission. Possible data that can be supported in this manner include: anomaly reports, stowage notes, mission action requests, electronic flight notes, international procedures, and generic ground-rules, requirements and constraints.

These products can be collected and mapped in a more effective manner and linked to the system baseline. This connection improves the capability to manage issues and non-conformances that can arise during the mission.

The planning of operational activities can be widely enhanced through a model-based methodology. Activities such as procedure scheduling can be performed in a more straightforward manner, reducing the time spent on activities such as document versioning or updates. For example, procedure generation can be performed using the information collected within the system model. In this manner, the changes to the current baseline of the operational activities can be tracked with fewer problems.

The operational scenarios can be designed during system development using the same model-based approach that characterizes all the other engineering domains. The use of a model-based methodology also ensures better exploitation of the data available from the system design. The information generated during the design phase can be exploited during the actual operational scenario, reducing the gaps that often occur during real missions. This information can be used to properly manage troubleshooting activities, telemetry elaboration and historical data retrieval. A formal data structure can reduce the time spent on data inconsistencies or baseline updates. This is also reflected in the data exchange process that can be performed with less effort than the traditional approach.

4 Conclusions and Future Work

The technologies that we use have proven to be very promising and show potential to address many more issues and challenges that we experience in our everyday working life.

The Request Configurator, Workflow Manager and Probes will be improved further to add additional features and expand their capabilities.

The Web Environment and its connection with Visualization, Simulation and Discipline tools demonstrated good maturity, and their use is currently planned in parallel with a project, to continue the validation approach in a more complex environment. The outcome of the UIW-project provided the team with very good feedback regarding potential benefits and areas for improvement of identified limitations. Such feedback will be used internally to the companies and with the relevant partners in order to improve the way we are transitioning to model-based engineering environments.