Management Methodology

Systems Engineering in Space Projects

A system is a collection of components that interact and work synergically to satisfy specified needs or requirements. Most systems do not exist independently, but are components of a supersystem. The objective of systems engineering is to design, fabricate, operate, and dispose of a system that satisfies a set of specifications in a manner that is cost effective and conforms to a predetermined schedule with a defined acceptable risk. Space systems engineering discusses the process and techniques to concurrently develop the different subsystems of a sophisticated space system. With the goal being the overall success of the system, the essence of systems engineering is compromise and trade-offs. Space systems development is generally characterized by:

  • A broad range of requirements, Procurement in small numbers,
  • Significant changes in the applicable technologies over the development cycle,
  • Launch costs that are a significant fraction of the total costs, and
  • The inability to access the space environment to carry out repairs or upgrades.

As a consequence, space systems are generally unique, robust and reliable, with minimal mass and power.

Systems engineering is the most prominent methodology in space engineering and it is very well supported and documented in the ECSS standards, the most relevant ones used the European space industry. The INCOSE defines systems engineering as:

Systems Engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations, Performance, Test, Manufacturing, Cost & Schedule, Training & Support, Disposal.
Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs.

As a quick summary of the systems engineering development cycle for a general project, in the next figure, the V-model is represented. In space systems engineering terms, first, the system and its mission is defined through feasibility studies, and then, requirements must be set to ensure the fitness of the solution. Once a preliminar design is achieved and reviewed, the team proceeds to refine the design, to completely define it and to deliver a detailed solution. The next step is its implementation through the assembly, integration, testing and verification phase. Finally, the spacecraft is launched and the mission starts to operate.

../../_images/v-cycle.png

Fig. 3 The V-model of the systems engineering process

During the whole process (initial studies, design, production, testing and operation), the ECSS standards provide the number and type of documents that should be released as well as the reviews that should take place. Also, they both recommend and forbid the use of certain technologies and materials in space missions, depending on their specific application. Following these standards is usually a requirement imposed by ESA when working with them and, consequentially, with the most important companies and institutions in the European space industry. Space systems engineering defines a framework of requirements and objectives that must be fulfilled. In this approach, the design phase is usually an iterative top-down process that reaches a solution in compliance with said requirements and objectives. The systems engineer is the person that acts as the link between the different subsystems and coordinates the different aspects of the design process to ensure compliance with the solution.

According to ECSS-M-ST-10C Rev.1 Project planning and implementation, a space project is divided into the following phases:

  • Phase 0: Mission analysis/needs identification
  • Phase A: Feasibility
  • Phase B: Preliminary Definition
  • Phase C: Detailed Definition
  • Phase D: Qualification and Production
  • Phase E: Utilization
  • Phase F: Disposal

This structure comprises and orders adequately all processes, tasks and work packages in the development of a traditional space mission. Important reviews take place at the end of each phase, i.e. to proceed with the next phase a formal review must be successfully passed. Some of these reviews are:

  • MDR: Mission Design Review
  • PDR: Preliminary Design Review
  • PRR: Preliminary Requirements Review
  • CDR: Critical Design Review
  • AR: Acceptance Review
  • LRR: Launch Readiness Review
  • ELR: End-of-Life Review

Phase 0 and A usually happen together and are involved in the detection and development of an idea and its feasibility, producing at the end the PRR. Phase B is when a more precise definition of the mission and its design is made. This means that the first specific studies are carried out and the most important decisions have been made. For the end of Phase C, the design must be frozen as well as the rest of the decisions that will happen in the future, like the AIT (Assembly, Integration and Test) plan and the project schedule. This information is completely settled for the CDR. The assembly, integration, testing and verification are the most important tasks in Phase D, when everything is subjected to a qualification process that ends with the launch and beginning of the mission. Finally, the mission ends.

Concurrent Engineering

The concurrent design (CD) consists of an engineering design style based on a continuous flow of information. This information is shared as parameters and design values, previously defined in the database. All subsystems from a space project and the interfaces between them must be defined using these design parameters. The CD allows instantly updating any design modification that may affect other subsystems, so it is transmitted to all the computers in order to share this update to the rest of the subsystems. In this way, the CD method saves time while avoiding many errors due to design changes that may not be communicated to others responsible.

The concurrent design philosophy implies an iterative design working: the subsystems are defined and the information is shared and updated until the mission requirements are fulfilled. This is called an “iteration”. Once a closed design is achieved, a new iteration modifying the necessary design parameters is carried out. This methodology allows achieving an optimization of the previous iteration, whether of size, cost, weight, etc. Once the iterative process has been completed, the results are studied to verify the viability of the project (phases 0 and A of the project).

Among the main advantages of concurrent design, specifically of its application in the field of space missions, it must be highlighted the time reduction to obtain relevant information to verify the feasibility of a complex mission, such as be the total power required, the volume or the preliminary cost of the mission.

By applying the concurrent design in a CDF, the communication between the subsystems responsible improves considerably, since they are all in the same place and at the same time. A CDF or Concurrent Design Facility is an advance design room equipped with a network of interconnected computers, multimedia devices and different software that allows implementing CD method.

The ESA has adopted the next definition for the Concurrent Engineering:

Concurrent Engineering (CE) is a systematic approach to integrated product development that emphasises the response to customer expectations. It embodies team values of co-operation, trust and sharing in such a manner that decision making is by consensus, involving all perspectives in parallel, from the beginning of the product life-cycle.

Essentially, CE provides a collaborative, co-operative, collective and simultaneous engineering working environment.

When a space project starts at the CDF, the first step is to define completely the mission. One of the following options must be followed, depending on two different situations:

  • If the client has provided the requirement list, you must check all these requirements in order to understand them and to assign each one of these requirements to one or several disciplines (all the subsystems defined in a satellite).
  • If the client gives you a description list of the properties that must fulfill the satellite, you must extract from this list all the nominal requirements by analysing the description of the mission.

The next step is to create and coordinate the teams that must work on the satellite design depending on the defined requirements. The teams shall be defined depending on the different subsystems involved in the project (e.g. the Attitude Determination and Control subsystem, the structural subsystem, the communications subsystems…).

During the pre-design steps, you must have in mind that some of the solutions are trade-offs between two or more subsystems, e.g. increase the total external surface generates a larger total power (from the solar panels) but increase the satellite weight.

It also must be highlighted that some subsystems generate a close loop with some parameters, e.g. the system engineer needs the mass and power consumption from all the subsystems; but the power subsystem engineer also needs the power required. This required power from all subsystems affects to the power consumption of the power subsystem. The solution of this problem is to estimate a first value of one of these parameters and make iterations until a trade-off solution is achieved.

CDF Design Typicall phases

The main objective of the concurrent engineering process is to ensure that the study meets the customer requirements within the time and cost assigned. The process make the most efficient and effective use of experts and their tools in order to create a design.

An important challenge for each team is to develop a process that is consistent and repeatable, but flexible enough to allow the necessary changes during a concurrent engineering study/session. Given that the members of a concurrent engineering team generally vary according to the studies, it is important to have consistent processes in order to generate easily traceable results and reduce the variation in the output products of the study. It is not required that the process be the same in the concurrent teams in different centres, but it is necessary to define the interfaces between the different teams that carry out distributed collaborative design sessions, similar to the interface agreements between subsystems.

A consistent systematic process is essential to reach a conclusion and finalize a design (including results documentation) in an allotted time. The individual secondary steps differ in response to the needs of the customer and the requirements and composition of the individual concurrent teams. The scheme shown in Fig. 4 captures, at the highest level, a representative process for a design study sequence. This sequence begins with the customer initial mission concept and goes to the final products. The details of each of the steps can vary between the concurrent engineering teams, but the main steps are still quite similar. The amount of time it takes to complete a particular step or study can vary from days to weeks or months, depending on the level of detail of the study or the complexity of the mission concept.

../../_images/CDFphases.png

Fig. 4 Typicall Concurrent Engineering Process

  1. Establishing the scope

In order to make the most of the design team, it is essential to start the study with a solid problem definition. The team lead/study facilitator meets with the customer to understand the problem to be solved and develop the requirements list for the study. The team leader and the customer agree with the objectives of the design study, the figures of merit, the required products and any engineering or other study constraints. The level of effort, the time of completion and the cost of the complete study vary depending on the scope and level of detail of the analysis and desired products.

  1. Pre-Study background work

The amount of background work done before the concurrent engineering session varies according to the team and the type of the mission being evaluated. Before the study, team members should review similar previous missions and perform early work on long-term subsystems (eg, mission analysis). They can also discuss specific aspects of the mission with the client to gain a better understanding of the requirements and limitations of the mission before the design session.

  1. Full-team concurrent design sessions

A design session is the physical or virtual meeting during which the members of the concurrent team perform the necessary analyses to design a collective system. The customer could be an active participant in the design team sessions. The activities and the results of the design effort depend on the type of study that is carried out and on the level of maturity of the mission concept. Different teams develop their designs in different time scales, depending on the amount of work done in real-time concurrent sessions versus independent work outside the sessions. The study may vary from the first feasibility studies of the mission to determine if a concept is viable, to the detailed designs of converging points, including the design of high-level subsystems, to the very detailed design of the system and the levels of subsystems, including cost estimates and schedules. During the design session, the concurrent design team works with the customer to achieve the desired level of fidelity. The designs (or a set of architectures for trade studies) are repeated until they converge, or are determined to be nonviable. Convergence is generally driven by a combination of certain key parameters and constraints, which generally include mass, power, cost and fitting within the launch vehicle constraints.

  1. Post-session documentation and presentations

Although there is a great variation in the activities of the post-design sessions between teams, all of these teams develop a product that documents the final design using a coherent and consistent template, presenting also the design to the client. Products can include PowerPoint slides, text documents, trajectory files and configuration drawings, among others.

CDF Studies at the ESA/ESTEC

The following is a list of some of the studies/reviews carried out by the CDF at the ESTEC in 2018:

Table 1 Studies/reviews carried out by the CDF at the ESTEC. Source: http://www.esa.int/Our_Activities/Space_Engineering_Technology/CDF
Title Customer
VEGA Standardisation MICRA Study GSP
MICE Giants Assesment of Orbiter or Probe for Neptune or Uranus SCI
EnVision M5 Assesment of Mission to Venus SCI
RGE Rover Garage Element for Lunar ISRU Studies MICRA Study HRE
THESEUS M5 Assesment of Transient High Energy Sky Surveyor SCI
SPICA M5 Assesment of Cryobenic Infrared Telescope for ESA JAXA Mission SCI
ATHENA SIM Phase A and B1 Continuation of ATHENA SCI
MSR Mars Sample Review Reviews and Phase A/B1 work HRE
ISRU Technology Demonstrator Design of Components for Lunar ISRU HRE
QPPF Quantum Physic Study to Test Quantum Superposition Theory SCI
LiteBird Next Generation measurement of Polarisation of Cosmic Microwave Background SCI

An good example of a study developed by the ESA at the CDF is the ASIM Mission: Atmospheric monitoring of blue jets, sprites and elves. It was a completed study for the Directorate of Human Spaceflight, Microgravity and Exploration showing the feasibility of accommodating the atmospheric Space Interactions Monitor (ASIM) payload on the International Space Station (ISS) Columbus External Platform Facility (CEPF).

The ASIM payload has been proposed by the Danish Space Research Institute (DSRI) to observe Transient Luminous Events (TLEs) that occur in the Earth’s upper atmosphere accompained by thunderstorms in the lower atmosphere. These events are known as blue jets, sprites and elves and they were first observed at 2003, a year a before the ASIM mission was studied at the CDF.

The CDF assessed the viability of conduncting science observations and conducted technical analyses to specify a design concept compatible with the ISS interfaces and constrainsts. The contamination and radiation environment and the instrument viewing requirements were analysed and taken into account. The CDF engineers designed equipment for power distribution, data handling and computing based on standard hardware avaliable to ESA external payload.

Launch: April 2nd, 2018
Vehicle: Dragon
Weight: 314 kg
Power consumption under nominal conditions: 200 W (including survival heaters: 430 W)
Data transmission: 200 kbit / s continuous
Main contractor: Terma, Denmark
Control center: B.Usoc, Belgium

Source: http://www.esa.int/Our_Activities/Space_Engineering_Technology/CDF

Agile Development

The agile development methodology was originated in the software industry and tries to facilitate software development in an iterative and incremental way, where requirements and solutions evolve through the collaborative effort of self-organising and cross-functional teams and their customers.

Agile system engineering practices are well established methodologies in software projects and are now being explored and studied to be applied in complex hardware projects. These practices permit a flexible and development working environment while allowing risk uncertainties to be managed in a disciplined manner.

The main principles are collected in the Manifesto for Agile Software Development, which are:

  • Customer satisfaction by early and continuous delivery of valuable software
  • Welcome changing requirements, even in late development
  • Deliver working software frequently (weeks rather than months)
  • Close, daily cooperation between business people and developers
  • Projects are built around motivated individuals, who should be trusted
  • Face-to-face conversation is the best form of communication (co-location)
  • Working software is the primary measure of progress
  • Sustainable development, able to maintain a constant pace
  • Continuous attention to technical excellence and good design
  • Simplicity –the art of maximizing the amount of work not done– is essential
  • Best architectures, requirements, and designs emerge from self-organising teams
  • Regularly, the team reflects on how to become more effective, and adjusts accordingly

These principles were written by software engineers with software engineering in mind, but they can be adapted to nanosatellite engineering easily, since it is a good methodology for small teams where everyone works with every subsystem, conforming a cross-functional team.

Another important difference is that nanosatellite engineering is focused on getting a physical system (the nanosatellite), that requires both software and hardware. This fact changes completely the paradigm, because hardware is not as iterable and revisable as software, so testing can happen as quickly and frequently as the agile methods suggest. Having that issue in mind, these methodologies can still be applied in the preliminary design phase, since no hardware is usually involved.

The principles that sustain this methodology decrease the constraints of development procedures and increase the responsiveness to the sponsor of the project. Some key points are self-organizing teams and a minimum number of documents written, maximizing its content and improving them continuously.

The main idea of these methods is to break the product development into small increments and tasks instead of approaching the problem with big work packages. In each short iteration, all members of the team work in design, analysis and testing/review/quality checking, with daily quick meetings to update their progress to the rest of the team. This process is similar to the first steps in a concurrent engineering process, but in this case every member of the team works in all parts of the software, so everyone gets a global view of the product.

Another difference with concurrent engineering is that these practices are applied throughout all the product development, something feasible with small teams. Applying these ideas are also possible for student teams, since their knowledge may not be as specialised as in traditional projects and they can benefit from working in the different subsystems that compose a nanosatellite.

As an example, we shall see how this methodology has been adopted for nanosatellite development at the Johns Hopkins University in USA and at the Observatoire de Paris’ CERES campus. The latter made use of student teams and some lessons learnt are described in [Segret].

A first design cycle was carried out applying a concurrent engineering model named by ESA the “Spiral Model”. The iteration starts with a mission requirement analysis that leads to the actual mission analysis. Then, the subsystem design step takes place and later it is followed by a design verification. Finally, risks are assessed before re-examining the mission requirements, completing the iteration. This cycle took 600 h of study. Some conclusions mentioned by the author include how time consuming is to manage a team of nine students that does not have real engineering experience and that shows heterogeneity in their works. One issue that happened was a deep misunderstanding of the problem that was tackled in time by an intermediate study report.

The second design cycle followed the agile principles. A common workspace (a FTP server) was set up. Each team of designers had a folder where to submit their deliverables. Important and valuable deliverables (documents, software, specifications, test routines, etc) were in a read-only folder that was frequently updated by the project manager, with backups of previous iterations.

During this cycle, there were periods of time, called runs, during which all efforts were concentrated towards a specific goal, with a duration of two or three weeks. The chairman oversees the run, usually a system engineer, the project manager or the deputy of the systems engineer. He/she requests every designer to deliver their work in their folders before a deadline and asks for the roadmap that the designer is going to follow in this run. Right after the deadline, the chairman analyses the deliveries and prepares a meeting that everyone attends, and where they have time to present a topic of interest, discuss the feedback and check the deliveries. Finally, the chairman decides what is saved in the common data archive, with a cretain confidence level in the results.

Other important roles that are set for each iteration are the tracker and the testman. The first one is in charge of preventing misunderstandings and bad communication between the different designers. The testman must test the project and advise the designer about possible improvements to make the tests more accurate, useful and usable by others.

This methodology can be combined with the concurrent engineering approach very easily and it does not require a linear flow as rigid as the traditional one: some subsystems could be more developed than others, for the flexibility and adaptability of these principles can accommodate easily major changes.

[Segret]Segret, Boris, et al. “The Paving Stones: initial feed-back on an attempt to apply the AGILE principles for the development of a CubeSat space mission to Mars.” Modeling, Systems Engineering, and Project Management for Astronomy VI. Vol. 9150. International Society for Optics and Photonics, 2014. URL https://spie.org/Publications/Proceedings/Paper/10.1117/12.2056377?origin_id=x4325&start_volume_number=09100