Processes following Aerospace Industry Standards
Mevine Staaden
Rymdteknik, master 2021
Luleå tekniska universitet Institutionen för system- och rymdteknik
Given the high risks and stakes within the aerospace industry, it is not surprising that this industry has a number of strict regulations and requirements to uphold. Nevertheless, these comprehensive requirements need to be verified and controlled thoroughly to ensure proper quality and safety of the products. Organising all of this while keeping the business efficient and profitable can prove a challenge to SMEs and emerging companies in this industry. This thesis aims to identify the di↵erent factors influencing business management systems and verification processes in the space industry and compare these to practical examples of management processes in various industry. Using these inputs, this thesis has managed to give recommendations and considerations for organisations to design, implement and maintain an ideal business management in the aerospace industry.
List of Figures . . . 1
List of Tables . . . 2
Acknowledgements . . . 3
List of Abbreviations . . . 4
1 Introduction 6 2 Theory 7 2.1 Business Management Theory . . . 7
2.1.1 Concepts . . . 7
2.1.2 The Four Components of a BMS . . . 8
2.1.3 The Management System Process . . . 14
2.1.4 Designing a BMS . . . 15
2.2 Spacecraft Design . . . 15
2.2.1 Spacecraft Subsystems . . . 16
2.2.2 Space Projects . . . 17
2.2.3 Concurrent Engineering . . . 19
2.2.4 The Aerospace Industry Process . . . 21
2.3 Requirements and Standards in the Aerospace Industry . . . 22
2.3.1 International Organisation for Standardisation (ISO) / European Norm (EN) . . . 22
2.3.2 ECSS Standards . . . 27
2.3.3 Other requirement sources . . . 29
2.4 Quality Assurance and Verification . . . 29
2.4.1 Quality Assurance . . . 30
2.4.2 Verification Principles . . . 30
2.4.3 Model Types . . . 35
2.5 IT Tools . . . 35
2.5.1 Enterprise Resource Planning . . . 35
2.5.2 Project / Task Management Tools . . . 36
2.5.3 Process Management Tools . . . 37
2.5.4 Communication Tools . . . 37
2.5.5 Document Management . . . 38
2.5.6 Requirements Management Tools . . . 38
2.5.7 Other Types of Tools . . . 40
2.5.8 Verdict on IT Tools . . . 40
3 Practical Implementation 41 3.1 Company Selection . . . 41
3.2 Interviews . . . 42
3.3 Findings . . . 44
3.3.1 Overall . . . 44
3.3.2 Processes . . . 44
3.3.3 Documentation & Tools . . . 44
3.3.4 BMS Satisfaction . . . 45
3.3.5 Verification . . . 46
3.3.6 Feedback . . . 46
3.3.7 Certifications . . . 46
4 Ideal BMS 48 4.1 Requirements . . . 48
4.2 Design Recommendations Discussion . . . 48
4.2.1 Approaches . . . 49
4.2.2 Methods . . . 50
4.2.3 Tools . . . 51
4.2.4 Values . . . 54
4.3 BMS Considerations . . . 55
4.3.1 Skilled Employees vs Rigid Processes . . . 56
4.3.2 Efficiency vs E↵ectiveness . . . 56
4.3.3 Cost of Implementation . . . 56
4.4 BMS Implementation . . . 57
5 Conclusion 58 5.1 Discussion . . . 58
5.1.1 Considerations for a successful BMS . . . 58
5.1.2 Certifications: Yes or No? . . . 59
5.1.3 Requirements Management . . . 60
5.2 Practical Implications . . . 60
5.3 Originality / Value . . . 61
5.4 Limitations . . . 61
5.5 Outlook and Future Research . . . 61
5.6 Conclusion . . . 62
2.1 Figures (a) and (b) showing the concept and an example of a subsystem. . . . 8 2.2 An example of some of the subsystems within a BMS. . . 8 2.3 An example of a classic functional model. Teams are split according to their
function and hierarchy is defined and maintained. . . 9 2.4 An example of how the cross functional model would work, based on the same
groups as the class functional model. People from di↵erent teams and hierarchies are combined into new teams to collaborate. . . 9 2.5 An example of an integrated BMS. The dotted lines show that the systems are
integrated with each other as well rather than just via the main system. . . 10 2.6 The iterative waterfall method within management, specifically project management. 11 2.7 The agile project management method, consisting of planning and requirements
analysis in advance, and then verification and deployment in a sprint before going into maintenance. . . 12 2.8 An example of a process turtle to illustrate the general template. Cartoon turtle
taken from: [1]. . . . 13 2.9 The optimisation wheel for management systems and processes, inspired by the
PDCA cycle, Six Sigma and strategic management process. . . 15 2.10 The phases of spacecraft design modelled on the waterfall method figure used in
section 3.1. The color-coded circles encircle the areas which are relevant to each phase, for example Phase B does both requirements and design and Phase E is both Deployment and Maintenance (i.e. Launch and Operations). . . . 18 2.11 Figures (a) and (b) showing a GANTT chart and WBS. . . 19 2.12 A wheel of concurrent engineering of the di↵erent subsystems as mentioned in
2.2.1, with sprints according to the agile method during the di↵erent design parts. 20 2.13 The general process of spacecraft manufacturing and mission completion in the
industry. . . 21 2.14 BMS optimality over time when a company follow the process described in the
optimisation wheel. . . . 24 2.15 The general testing procedure for requirements that are chosen to be tested. . . . 32 2.16 The process for the material sample during the thermal vacuum outgassing test.
Figure inspired by description in ECSS-Q-ST-70-02C [2]. . . . 33 2.17 A screenshot of the features within the Valispace Engineering Platform as adver-
tised on their website [3]. . . . 39 4.1 A visual depiction of the items in each of the four components of an ideal BMS. . 49
2.1 The di↵erent subsystems of a S/C along with a short description and example parts for each of them. . . 16 2.2 Typical Mission Phases of a Space Mission, according to ECSS-M-ST-10C [4]. . 17 2.3 Classification and Identifiers of the ECSS standards. . . 27 2.4 Verification Methods as taken from ECSS-E-ST-10-02C [5], and The New SMAD [6]. 31 3.1 Company Selection, where a * indicates that there was a company of that size
and in that field. Companies were classified once by size (Micro, Small, Medium or Large), and once by either start-up or established. The explanation for each term is in the text. . . 41 A1 A table summarising the di↵erent IT tools introduced in section 2.5. . . 71 A1 A table summarising the di↵erent IT tools introduced in section 2.5. . . 72
Acknowledgements
I would like to thank my sambo, Emil, for putting up with me during stressful days and bringing co↵ee and snacks when I asked for them. He has been very supportive and understanding on those longer nights and has also been a great source of inspiration when bouncing ideas back on forth. His tendency for criticism while annoying at times has helped elevate this thesis and in hindsight I am very grateful.
Next, I would like to thank my friends, especially Clara and Nehir, for being supportive even as I was getting frustrated. They were always there for me, whether it was to get me focused or to distract me.
I would also like to thank my family for the support I received in the form of long walks, discussions, and sometimes cake and other “fika”. I am also grateful to my father specifically for lending me his extended network throughout these times where it has been harder to contact companies. This has been a great help in completing this thesis.
At this points I would also like to thank all the people that participated in the interviews. Their input has helped understand the practical implementation aspects of business management systems and this thesis would be incomplete without them. Following this, I would like to thank my colleagues at Airbus, specifically the PYYP Procurement Processes team who were supportive and keen to help me out throughout my entire stay.
Finally, I would like to thank my supervisors, Torbj¨orn Hult and Sebastian Hugel. Torbj¨orn has provided direction and advice when I didn’t know which ideas I should follow through on and which would exceed the scope of this thesis. Our shared enthusiasm for this topic helped spark discussions and thoughts that lead to the results illustrated in this thesis. Sebastian came up with the idea for this thesis, helped with mentoring and gave realistic input from a large European aerospace company.
List of Abbreviations
ACS Attitude Control System AIT Assembly, Integration and Test
AIV Assembly, Integration and Verification
AR Acceptance Review
BMS Business Management System BPM Business Process Management CDR Critical Design Review
CM Configuration Management
CNES Centre National d’Etudes Spatiales
DLR Deutsche Luft- und Raumfahrt Gesellschaft DMAIC Define, Measure, Analyse, Improve, and Control DPMO Defects Per Million Opportunities
EASA European Union Aviation Safety Agency
ECSS European Cooperation for Space Standardisation ELR End of Life Review
EMS Environmental Management System
EN European Norm
EPS Electronic Power System ERP Enterprise Resource Planning ESA European Space Agency
HR Human Resources
ISO International Organisation for Standardisation IT Information Technology
ITT Invitation to Tender MCR Mission Close Out Review MDR Mission Design Review
MS Microsoft
NASA National Aeronautics and Space Administration OBDH On-Board Data Handling
OBC On-Board Computer
ORR Operational Readiness Review PDCA Plan-Do-Check-Act
PDR Preliminary Design Review PFM Protoflight Model
PM Project Management
PRR Preliminary Requirements Review QA Quality Assurance
QMS Quality Management System RM Requirements Management
S/C Spacecraft
SEE Single Event E↵ect
SME Small and Medium Enterprises TCS Thermal Control System TQM Total Quality Management TT&C Telemetry, Tracking and Control UUT Unit Under Test
WBS Work Breakdown Structure
Introduction
The global space sector is a noteworthy and growing industry. World-wide, the space economy had an average 6.7% yearly growth rate between 2005 and 2017, which is almost twice as much as the growth rate of the global economy [7]. It is also projected to grow even more over the next 20 years [8]. Among this growth, Europe is becoming an important player in the space industry [9].
Initially, the space industry was largely fueled by national / international space agencies, for example the National Aeronautics and Space Administration (NASA) launched in 1958 in the United States of America (USA) [10], or the European Space Agency (ESA) created in Europe in 1975 [11]. Recently though, more private companies have been emerging in this industry [9].
In 2017, private companies constituted around 70% of sales within the space industry in Europe [12]. Some of these private companies are Airbus Defence and Space, OHB, Thales Alenia Space, and RUAG Space, to name a few [12].
With more private companies emerging and the European Commission setting up policies to support Small-to-Medium Enterprises (SME) in Europe, the importance of a sound business model increases [13]. A profitable business model requires a functioning management system.
Therefore, a well-planned and properly executed business management system (BMS) is beneficial to any space organisation in the current economic climate.
This thesis has analysed the di↵erent aspects of business management systems, starting with business management theory, looking into di↵erent requirements and standards (ISO, EN 9100, ECSS), verification methods in the space industry and various IT tools that can be used to assist management. To balance this, a broad spectrum of companies has been interviewed to discuss their approach to business management and analyse any factors for practical implementation that might not be apparent from the theory. Finally, this thesis has attempted to design the ideal business management system for the aerospace industry.
To guide the research three research questions were defined:
RQ 1: What are the main considerations for a successful BMS in the aerospace industry?
RQ 2: Should aerospace companies aim to acquire certifications?
RQ 3: What is the key to managing all the requirements in an aerospace project?
This thesis has examined the implementation of processes which successfully adhere to industry standards and understand the holistic business management system behind it. With these results, the aim was to design an ideal business management system for space organisations to guide them in their endeavour to optimise their processes and function as efficiently as possible.
Theory
The theory aspect of this thesis will focus on five major topics. The first is business management theory, including concepts behind management systems and some approaches, to provide a broader understanding. The second topic is spacecraft design, to give some background information on this industry and the processes within. Next, a collection of requirements and standards in the European aerospace industry will be discussed to provide understanding on what the requirements in the space industry are. To complement this, the fourth topic is quality assurance and verification, which will address how di↵erent requirements are verified. Finally, IT tools will be reviewed to see if and how they can aid the management and implementation of processes that adhere to requirements.
2.1 Business Management Theory
A management system is the collection of activities and tasks that are completed to fulfill a certain outcome. Management systems can be specific to distinct areas, such as the environment, resources, quality, etc. or a collection of these areas, which is then considered a business manage- ment system (BMS) [14]. Understanding and optimising the management system of a company is essential to maximise productivity and production [14, 15]. While it may not always be formal, organised or even intentional, every organisation has a BMS [15].
The idea of a business management system is to integrate all the specific management systems into one, essentially allowing them to interact with each other and thus work as a system. As management aspects and concepts often apply to a variety of subjects, it seems trivial to simply integrate them into one [14]. Even though this approach should simplify the system as a whole, some organisations seem to struggle to combine their management systems into one [14]. As one paper pointed out, a common challenge is to find harmony among the di↵erent objectives of a project: customer satisfaction, financial limitations and technical and quality requirements [16].
We can try to simplify this challenge by understanding the theory behind it.
First, a few concepts are explained to understand the background. Next, the four components of a BMS are discussed before moving on to the improvement process of a BMS. In the final part, designing a BMS will be explored.
2.1.1 Concepts Systems
A system is a combination of elements working together to achieve a certain outcome. A system element either has “a function or an attribute within the context of the system” as a whole [17].
Systems can be natural, such as the human body, or man made such as a transportation system.
A system that has been designed intentionally can also be defined as “a collection of components designed to work together to efficiently perform a certain function” [17]. Any system can be described with three components, input, process, and output [18].
Subsystems
As systems become larger and more complex, it can be beneficial to split them into a collection of subsystems. This separation can be based on functions, location or any other classification.
This can be done to almost any system, with the structure consisting as in 2.1a. Figure 2.1b shows an example for a local transportation system. The number of subsystems will depend on the complexity of the system and the best way to separate it.
(a) A system which has been split into several sub- (b) An example of this separation for a local trans-
systems portation system.
Fig. 2.1: Figures (a) and (b) showing the concept and an example of a subsystem.
Management
Management can be defined as “a process of running and managing business [...] to accomplish certain objectives and goals by a team” [19]. The management function includes activities of planning, organising and controlling tasks within design, strategy, marketing, procurement, human resources and finance [18, 19]. Essentially, it is the overarching actor in any organisation with several functions.
Business Management System
A business management system (BMS) simply combines the concept of systems and management within business. It is a way of managing business activities and tasks by organising them into a system. This system has inputs, outputs and processes, and can be split into subsystems as seen in figure 2.2.
Put simply, it is a combination of the other three concepts discussed. However, describing or designing a BMS requires an understanding of the di↵erent components of a BMS.
These are examined next. Fig. 2.2: An example of some of the subsystems within a BMS.
2.1.2 The Four Components of a BMS
The various aspects of a BMS can be categorised into di↵erent components. A paper published in 2000, identified three components of total quality management (TQM): techniques, tools and values [20]. The same paper classified TQM as a management theory along with supply chain management and human resource management [20]. Modern literature is now often taking a more integrated view, examining the overall business management systems to ensure that all subsystems of a BMS use the same approach. Therefore, the three components will be complemented by a fourth component, approaches. These four components are examined separately for a better picture of what each entails.
Approaches
There are di↵erent approaches to organising the business management system. An organisation can choose to focus on one of these approaches or combine them. An approach can be seen as a more overarching way to set up the BMS.
One of the approaches is the classic functional model, in which an organisation is split into departments with di↵erent management systems. These can also be referred to as “silo’s in hierarchy” and are typically not supportive of agile work [21]. Agile work occurs when companies and organisations work proactively and flexibly, resulting in a faster response to unexpected changes [22, 23]. In this model, process design involves writing policy and procedure manuals for functional departments to follow [24]. After reviewing more recent literature, this approach seems outdated.
Fig. 2.3: An example of a classic functional model. Teams are split according to their function and hierarchy is defined and maintained.
A contrary approach to the functional model is the cross-functional model. In this model, teams are assorted of people from di↵erent functions and on di↵erent hierarchical levels. There are a number of benefits connected to the cross-functional approach, such as improved innovation management [25] and better overall performance [26]. This type of approach is favoured in the current dynamic environment organisations are encountering [27].
Fig. 2.4: An example of how the cross functional model would work, based on the same groups as the class functional model. People from di↵erent teams and hierarchies are combined into new teams to collaborate.
Another approach is an integrated system in which the systems are integrated with each other as seen in figure 2.5. With this approach, a principle which is also used in spacecraft design, concurrent engineering (see sec. 2.2.3), can be used. Designing the di↵erent subsystems together means that all subsystems share the same overall model which simplifies process design, especially for overlapping requirements [28]. This system is often combined with the cross-functional model.
Fig. 2.5: An example of an integrated BMS. The dotted lines show that the systems are integrated with each other as well rather than just via the main system.
A further approach is business process management (BPM). As the name indicates, BPM focuses on the processes of the management system, rather than for example roles and responsibil- ities of each individual. It can be especially beneficial during the starting phase of implementing a BMS since it gives a tangible starting point [29]. BPM also fosters continuous improvement as discussed later in section 2.1.4 [16]. This approach is often combined with the integrated system and the cross functional model as processes can be defined across functions and management systems. Some techniques arising from using this approach are process definition and process optimisation, discussed in the next section.
Techniques / Methods
Within a BMS, techniques or methods are “ways to work within an organisation” to achieve a certain outcome [20]. They usually have a broad application but do not constitute a holistic approach. To give a general picture, a few are named and discussed here but there are countless other methods.
One concept used in business management is Six Sigma, or 6 . The term is derived from statistics, specifically from the standard deviation ( ) of the normal distribution. The six sigma standard implies 3.4 defects per million opportunities (DPMO), and essentially is a quality reference tool. Six Sigma is also defined as a level of quality, a problem solving methodology, and an overall management philosophy [30]. This method can be broken down into five phases:
define, measure, analyse, improve and control (DMAIC) [30] [31]. Six Sigma can be more data heavy, which comes with its own benefits and drawbacks [32]. It can also be combined with other methods and approaches and then could also be used as an approach to BMS [24]. As this method applies best to optimising o↵-the-shelf products and the space industry has more customised products this technique is not explored further.
Another method is process definition. Rather than the overall approach of BPM, this is a technique which addresses the actual processes and how they are defined. Defining a process includes determining the inputs and desired outputs and then identifying the tasks and activities that constitute the process which transforms the inputs to the outputs. A process owner should also be assigned to each process to ensure responsibility among the employees. They can also be in charge of the process documentation.
Following from the last technique, we have process optimisation. As the name implies, in this technique processes are being analysed and results are being measured to identify any means of optimisation. Usually, the process owner is in charge of analysing improvement options (optimisation), and taking the necessary steps to implement any optimisation (such as updating
the handbooks and communicating changes to employees) [33].
Another method is the waterfall method. This is a method often used for projects where one task is done after the other, the way a waterfall flows down. An updated version of this is the iterative waterfall approach, as depicted in figure 2.6, in which the process can flow back up during the process. This method is likely to be successful if the requirements are available from the start of the project [34].
Fig. 2.6: The iterative waterfall method within management, specifically project management.
Contrary to the waterfall method, a di↵erent option is the agile method. Here things are pre-planned and then quickly tested and deployed, in ”sprints”. These sprints can be repeated several times as di↵erent features of the project or product are deployed. The benefit with the agile method that it assumes that not everything is known from the start and and its not equally critical [35]. Therefore, the key features can be developed early on and extra aspects can be designed as the project progresses and is updated.
In literature, agile and waterfall are often compared. The waterfall method is the recommended option if the project cannot be split into several separate deliverables and frequent updates or changes are not possible [34]. However, another paper argues that these two processes mimic each other in several ways and there is not a big di↵erence in which choice one makes [36].
Fig. 2.7: The agile project management method, consisting of planning and requirements analysis in advance, and then verification and deployment in a sprint before going into maintenance.
Tools
The tools of a BMS are more concrete, sometimes come with instructions and are usually predefined in their use. The point of using any tool is to optimise the experience and save time or money in the long run. Therefore, it is important to only utilise tools that are beneficial.
A perhaps obvious example of tools are IT tools, which will be discussed more in section 2.5 as it is a more elaborate topic. In general, IT tools provide structure to activities and processes and can assist in their fulfillment. When used badly, they can also be a hindrance and an obstacle to fulfilling processes as they could add extra steps.
Another tool for BMS are di↵erent standards and requirements. These too will be discussed in length in a di↵erent section (sec. 2.3). Using standards can help provide requirements and guidelines on how to meet them. Additionally, depending on the type of standard, a certification can be acquired, certifying to customers that the organisation adheres to these requirements.
This can give internal performance and organisational benefits and external marketing advantages [37].
Other tools can broadly be defined as diagrams. These can include any process diagrams such as process turtles as seen in figure 2.8. Using a tool like this can help define processes when it seems unclear or overwhelming to start. This is an example of process mapping and using diagrams to aid this step can help understand the workflows and tasks even across di↵erent departments [16]. Other diagrams could be GANTT charts for timelines (fig. 2.11a), Work Breakdown Structures (WBS) to organise tasks and workloads (more on WBS in section 2.2, see fig. 2.11b) or organisational diagrams to illustrate the company structure.
Fig. 2.8: An example of a process turtle to illustrate the general template. Cartoon turtle taken from: [1].
Values / Principles
Values or Principles are an important aspect of designing management systems. The intention behind defining values is to give a guideline as new methods or tools are implemented and to remember the importance of them. According to one paper, quality principles can be summarised into the following three [38]:
• customer focus
• continuous improvement
• team work
The values mentioned in another paper are [20]:
• base decision on fact • focus on processes
• improve continuously • top management commitment
• focus on customers • let everyone be committed Another paper determined 10 principles of good business and process management [39]:
• context-awareness • involvement
• continuity • joint understanding
• enablement • purpose
• holism • simplicity
• institutionalisation • technology appropriation
The ISO 9001:2015 standard (discussed in section 2.3.1) also gives some QMS principles [40]:
• customer focus • improvement
• leadership • evidence-based decision making
• engagement of people • relationship management
• process approach
A paper from 2008 investigated a collection of di↵erent principles and examined their commonal- ities to find six business excellence criteria [14]:
• leadership • people
• strategy & planning • stakeholder and market focus
• information & knowledge • process management & innovation From these, some common themes can be taken and compared to existing principles or values held by the organisation to decide on a set of business excellence principles. Such principles, also referred to as core values, can help guide the system design and implementation. They can be seen as the foundation or base for developing, implementing and maintaining an e↵ective BMS [14, 39].
2.1.3 The Management System Process
Designing and maintaining a management system can be seen as a process in itself. One of the approaches is the Plan-Do-Check-Act or Plan-Do-Check-Adjust cycle [18], which is also part of the ISO 9001 standard (see section 2.3.1) [40]. The di↵erent steps can be described as follows:
Plan: Establish the objectives. Identify what resources (inputs) and processes are needed to fulfill the requirements (outputs). Determine any risk.
Do: Implement the Plan.
Check: Performance measurements. Check results against objectives and require- ments.
Act: If improvements are possible and/or necessary, adjust. Implement new actions.
Sometimes, a fifth step can be added, Diversify, in which extra activities can be done such as training [18].
A similar concept is discussed with regards to Strategic Management, where the process is described as [41]:
1. Mission & Objective 2. Situation Analysis 3. Strategy Formulation 4. Strategy Implementation 5. Strategy Evaluation
The method used in Six sigma, define, measure, analyse, improve and control, is another similar approach. These approaches all follow a similar pattern, of creating a plan, implementing the plan, measuring the performance and then optimising accordingly (as depicted in figure 2.9).
This is a means of fulfilling the principle of continuous improvement.
This continuous improvement can be implemented using the agile method. Specifically the
“implement” aspect of the optimisation wheel (fig. 2.9) can be done using a “sprint”. That way the BMS or specific tool that is being improved is not “out-of-action” for an extended period of time while it is optimised. The step of “measure”, “optimise” and “plan” can be done in the background as the tool is being used.
Fig. 2.9: The optimisation wheel for management systems and processes, inspired by the PDCA cycle, Six Sigma and strategic management process.
2.1.4 Designing a BMS
Combining this, we can see the general idea of a business management system (BMS). It is a system to organise the entire business, from environmental, to quality, to manufacturing, human resources (HR) and finance. Some approaches use a QMS as the main system for the “main processes” and then have supporting systems for HR, finance, procurement, etc, the “supporting processes”.
As stated earlier, some organisations might struggle to create a complete business management system. One paper recommends “integrating principles, business excellence performance criteria [...] and process improvement” to create a thorough BMS [14]. Combining this with the procedure of having four components to a BMS, the approach(es), methods, principles and tools, it becomes easier to design a full business management system.
Additionally, each of the systems have di↵erent elements which work together to provide a structure. According to one paper the main elements of a good BMS are individual principles, performance criteria and results [14]. This is supported by the components of the optimisation wheel, specifically the measuring and evaluation of performance.
This section gave some necessary background information on the theory of business management.
BMS in the space industry are in general very similar to BMS in another industries, with the main di↵erence being the extensive standards and requirements [29]. To better understand this aspect, the next three sections will examine the processes, standards and verification procedures in the space industry.
2.2 Spacecraft Design
This section will discuss the basics of spacecraft (S/C) design as an example to illustrate what needs to be organised and managed within the space industry. It will discuss the basic concept and design of S/C and the timeline and project phases of such designs. It will also address a leading approach within S/C design, concurrent engineering, and the big picture process in the aerospace industry.
It is important to note that while S/C are often viewed as systems and are split into subsystems to simplify this view, the S/C is often part of an even larger system. It requires a ground control system to support its control and a launcher system to bring it into orbit or on the right trajectory [42]. Within a systems point of view, it is important to view each entity as part of the system it belongs to while also dividing it into further subsystems as required.
2.2.1 Spacecraft Subsystems
As other systems are often broken down into subsystems, so is a spacecraft. These subsystems can be classified into two categories, the payload and the platform. The payload is defined by the mission or vice-versa so, to put it simply, is the part that needs to go into space. For example, an observational satellite is often equipped with a type of camera, (high resolution, infrared or similar), which would be considered the payload. The platform is the rest of the S/C, making the S/C function and thus fulfilling the mission. The parts of the platform can be classified as the subsystems seen in table 2.1.
Subsystem Description
Attitude Control System (ACS)
Controlling the attitude and orbit of the S/C.
Parts: reaction wheels, star sensors, ...
Propulsion / Orbit Control System
Controlling and correcting the orbit.
Parts: chemical thrusters, electromagnetic thrusters, ...
Thermal Control System Regulates the temperature of the S/C.
Parts: radiator, heater, ...
Electronic Power System (EPS)
Provides and regulates electronic power to di↵erent parts of the S/C. Parts: battery, cables, solar array, ...
Telemetry, Tracking and Command (TT&C)
Responsible for the communication between ground and S/C.
Parts: antenna, receiver, transmitter, ...
On-board Data Handling (OBDH)
The on-board computer handles and stores any data on board the S/C. Parts: On-Board Computer, Interface Units, Mass Memory,...
Mechanics and Structural Subsystem
Entire structure of S/C, holding it together, with mechanics for extending parts such as antennae or solar arrays.
Parts: outside walls, inside structure, “arms”, ...
Table 2.1: The di↵erent subsystems of a S/C along with a short description and example parts for each of them.
The mission requirements often determine the requirements for the subsystems. For example, an earth observation satellite with a high resolution camera might need a specific angle towards earth and precision in that angle. In this case, the attitude control system would have the requirement to provide this precision in the crucial moments of the mission.
During the design of these subsystems, other factors need to be considered as well. For example, as repair is generally not possible for a S/C, the system needs to be analysed for risk of failures before- hand. Some crucial parts might need to be redundant (included more than once) in case of failure.
Another aspect is the availability and readiness of the required technology [6]. Availability refers to whether the technology has been designed yet or whether it needs to be developed during the S/C design and build process. Readiness of technology refers to whether this technology, if available, has been tested extensively enough to be reliable on a space mission. In the space industry, technology is often classified according to the Technology Readiness Levels [43]. Often, technology that might be available in the market will take years before it sees space since testing needs to be done first. Therefore, something which is often considered when designing subsystems and choosing di↵erent parts is heritage.
Heritage refers to whether a technology has already been used in space. It can be beneficial to go for “older” technology if it has proven to be reliable in space by another mission. This can be applied to single parts within a system, entire subsystems or in some cases even most of the platform. For example, the Venus Express mission platform was based on the Mars Express platform [44]. Some of the parts of the Mars Express mission were in turn based on the Rosetta mission, which reduced costs [45].
Due to the complexity of the subsystems and their interdependence, S/C design can be quite lengthy and complex. Therefore, planning the S/C design process requires its own section. As put by one book on S/C engineering: “Space Mission Engineering is a complex process with many intertwined steps” [6].
2.2.2 Space Projects
Due to the length and complexity of space projects, they are often defined into di↵erent phases that have di↵erent tasks and di↵erent review processes. In Europe, these stages have been defined by the European Cooperation for Space Standardisation (ECSS) in standard ECSS-M-ST-10C.
The stages are divided as seen in table 2.2.
Phase Tasks Concluding Review Process
Phase 0 Mission Analysis Mission Design Review (MDR) Phase A Feasibility Study Preliminary Requirements Review
(PRR)
Phase B Preliminary Design Preliminary Design Review (PDR) Phase C Critical Design Critical Design Review (CDR) Phase D Production and Qualification Acceptance Review (AR) and Opera-
tional Readiness Review (ORR) Phase E Launch and Operations End of Life Review (ELR)
Phase F End of Life Mission Close Out Review (MCR)
Table 2.2: Typical Mission Phases of a Space Mission, according to ECSS-M-ST-10C [4].
As can be seen in table 2.2, each phase of the mission has main tasks and at least one concluding review process. Some phases, such as phase D also include a qualification review during the phase, which isn’t considered a concluding review. Specifically phase E contains a few more reviews which are conducted between the final production of the S/C (phase D) and launch, such as the flight readiness review.
Taking this in comparison to the methods and techniques mentioned in section 3.1, it becomes clear that the design of a spacecraft utilises more of an iterative waterfall approach rather than an agile approach. Figure 2.10 shows that by using color coded circles for the di↵erent phases.
Phase 0 happens before the requirements are identified and Phase F is after maintenance, since it entails the end of life of the S/C.
Fig. 2.10: The phases of spacecraft design modelled on the waterfall method figure used in section 3.1. The color-coded circles encircle the areas which are relevant to each phase, for example Phase B does both requirements and design and Phase E is both Deployment and Maintenance (i.e. Launch and Operations).
Considering it meets the requirements for a successful waterfall implementation (requirements known beforehand, not separable into deliverables and frequent updates are not possible), this is not surprising. As the agile method best applies to projects that can be updated as they are used, this would not be the right method for a spacecraft. Therefore, the waterfall method is the only suitable choice.
To keep track of this process and the di↵erent phases, GANTT charts are often used to organise the timeline of the space mission. These are an example of a tool used in space project planning and an example can be seen in figure 2.11a. Another tool used to plan space projects is the Work Breakdown Structure (WBS). This is used to structure and organise the di↵erent tasks that need to be done for di↵erent subsystems and products. It is also mentioned in ECSS-M-ST-10C-Rev1 [4]. An example can be seen in figure 2.11b.
GANTT Chart
YEAR 1 YEAR 2 YEAR 3 YEAR 4
TASKS J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N D J F M A M J J A S O N D Task 1
1.1 Activity 1.2 Activity 1.3 Activity 1.3.1 Activity 1.4 Activity 1.5 Activity Task 2 2.1 Activity 2.2 Activity 2.2 Activity Task 3 3.1 Activity 3.2 Activity 3.3 Activity 3.4 Activity Task 4 4.1 Activity 4.2 Activity 4.3 Activity
1
(a) An example of a GANTT chart with di↵erent tasks and a timeline of 4 years.
Platform
1.1 Activity
Task 2
1.2 Activity Task 1
1.3 Activity
1.4 Activity
1.5 Activity
2.3 Activity
1.3.1 Activity
2.1 Activity
2.2 Activity
Task 3
3.3 Activity
3.4 Activity 3.1 Activity
3.2 Activity
Task 4
4.3 Activity 4.1 Activity
4.2 Activity
1
(b) An example for a WBS with di↵erent tasks for di↵erent activities. The activities can be di↵erent subsystems or products. The activities here coincide with the activities in the GANTT chart (fig. 2.11a).
Fig. 2.11: Figures (a) and (b) showing a GANTT chart and WBS.
2.2.3 Concurrent Engineering
Concurrent engineering is an engineering approach where the di↵erent parts and subsystems of a spacecraft (S/C) are designed simultaneously rather than one after the other. The problem with a sequential approach is that the subsystems create requirements for each other. For example, a heater for the thermal control system (TCS) needs power from a battery from the electronic power system (EPS), however the battery might also need to stay in a certain temperature range and thus has heater and radiator requirements for the TCS. A workaround would be to design each subsystem with maximum capacities and ranges to ensure that requirements from other subsystems can be met, however, this would not be efficient. Therefore, subsystems cannot be de- signed sequentially if an optimal design is desired. The alternative approach is to design the entire system at the same time, thus the subsystems are designed in parallel using concurrent engineering.
Figure 2.12 shows how concurrent engineering can work. Essentially, as each subsystem is designed and requirements for other subsystems come up, this is transferred onto the next one and so on. Starting for example with the EPS, it could have a requirement for the temperature for the battery, which goes into the thermal design. From this, the thermal subsystem requires a mechanical structure that allows for a radiator, which in turn requires one of the walls to be all radiator and thus changes the design for the ACS as it might ot be able to put a sensor or actuator for the attitude control on that wall. The circle continues during the entire design phase (Phase B & C). Of course the path within the circle can be deviated and a new thermal requirement for the EPS does not need to go the entire route through the other subsystems before reaching the EPS again. Concurrent engineering simply means that the designs for the subsystems are completed together to reach the optimal design.
For concurrent engineering, a more agile method is applicable. An example is shown in figure 2.12, each subsystem also has a few grey circles on it. These represent agile sprints as discussed in section 2.1.2 and shown in detail in figure 2.7. The number of sprints depends on each subsystem and the number shown in figure 2.12 is just an example. The agile sprints are therefore applicable for spacecraft design as well, however only during the design development and testing phases (phase B, C and D), and not the entire space mission.
Fig. 2.12: A wheel of concurrent engineering of the di↵erent subsystems as mentioned in 2.2.1, with sprints according to the agile method during the di↵erent design parts.
For concurrent engineering to work in the space industry, systems engineers are employed to work on projects. The job of a systems engineer, as put by an ECSS standard “is to ensure that all parts of a project work together” [46]. This job is separate from a project manager as the manager is in charge of keeping schedules, costs, etc., while the systems engineer is focused on the compatibility of each subsystem within the system as a whole. The systems engineering approach is therefore an approach in which the focal point is compatibility between the di↵erent subsystems to ensure that they work together optimally.
One of the benefits of a concurrent approach is reaching a feasible design faster [28]. Using the systems engineering approach can also be beneficial as it often leads to the entire system being based on the same model [28]. This centralised model provides harmony among the subsystems and can lead to a simpler and cheaper S/C. It also motivates engineers to have important conversations early on to avoid problems later [28]. A systems engineering approach can also be more technical, with more metrics and data which can result in more efficient error prevention and detection [47].
While both concurrent engineering and systems engineering are commonly used in S/C Design, they are great approaches for any system, especially one involving subsystems. Systems engi- neering can even be viewed as a management approach, even to business management [47]. The general approach is the same, rather than designing each part separately, the entire manage- ment system as a whole is designed simultaneously while focusing on compatibility, ensuring no unnecessary redundancy and complexity. Concurrent engineering is especially beneficial when designing a complex system with several disciplines [42]. As this is a case in an industry combining engineering, physics, business and management, this approach could be beneficial to space companies.
2.2.4 The Aerospace Industry Process
Designing and building a spacecraft in reality has a few more steps around it. To illustrate this process, two examples will be discussed. One example will be a scientific mission from ESA, the other will be a private customer asking to launch their payload on a smaller CubeSat satellite. A general overview can be seen in figure 2.13.
Fig. 2.13: The general process of spacecraft manufacturing and mission completion in the industry.
When ESA has the budget for a new space mission, they will call for a mission proposal. Here, scientific missions can be proposed based on the scientific goals of ESA, overall mission cost, size and some other details included in the call for proposals [48]. After a selected amount of time, these proposals will be reviewed and a few will be selected to go into an assessment phase, where a feasibility study will be conducted by ESA scientists and engineers [48]. This can be equated to Phase 0 of the spacecraft design process as described in table 2.2. After a committee reviews these results and recommends a few missions to enter the next phase where a preliminary design is created for each mission [48]. This can be seen as Phase A (see tab. 2.2) and is often conducted by scientists and industries in parallel. A committee then reviews these designs and decides which missions shall be chosen for the next phase.
In the next phase, industrial contracts are issued to potential prime contractors and they compete for the mission [48]. The companies are asked to develop a more detailed preliminary design which can be seen as the first part of phase B in table 2.2. This is called an “Invitation to Tender”
(ITT) and includes a collection of documents.
One of these is a statement of work (SoW) which outlines the scope of the work. Other documents important for the spacecraft design is the system requirements document (SRD). It provides a list of all the requirements, such as the performance requirements of the spacecraft. More on requirements will be discussed in section 2.3.
With the ITT, companies can compete to win the prime contract. ESA then chooses one of these companies to complete the rest of the mission [48]. Recent examples of prime contractors are Airbus, with the Earth Return Orbiter [49] and OHB with the Arctic Weather Satellite [50].
Prime contractors also often need to find subcontractors to help with the development or produc- tion of certain parts of the spacecraft. Depending on the technological requirements, parts such as the battery need to be developed to meet the specific requirements and cannot be bought
“o↵-the-shelf”. In those cases, subcontractors could be hired to develop this part. In other cases, the prime contractor (or prime) might not need a subcontractor to develop parts but can ask to purchase them, such as screws, etc. This means, while the prime is often in charge of the satellite development and production they rarely do the work alone.
A di↵erent example is a private customer requiring a payload to go on a CubeSat into a certain orbit. Here the customer can approach di↵erent CubeSat companies, for example Open Cosmos, to build a satellite for them [51]. Depending on the payload requirements and the company, the satellite might need to be customised or can be used “o↵-the-shelf”. These satellites can then be launched into space in di↵erent ways, depending on their orbit. For example, a “rideshare launch” can be chosen in which small satellites essentially piggyback o↵ a larger satellite launch and use the same rocket to launch into space [52]. Private companies specialising in this exist as well, one example being Exolaunch [52]. One of the main di↵erences between the private customer and public (ESA) process is that the private customer does not need to go through a public procurement process and thus does not need to follow the formal process as ESA does.
2.3 Requirements and Standards in the Aerospace Industry
As any other industry, the aerospace industry has standards and requirements to ensure a certain level of quality. In the aerospace industry, these requirements are often stricter, given the increased risks compared to other industries. It makes sense to mitigate these risks as much as possible by increasing quality and safety regulations.
Requirements are generally either internal or external. Internal requirements are any requirements set within the company, originating internally. External requirements can come from customers or external regulatory organisations and other bodies. In the space industry, the latter range from any legal requirements set by the local governments, to standards set by international organisations such as ISO (International Organisation for Standardisation) and more specific re- quirements set by organisations such as ECSS (European Cooperation for Space Standardisation).
Another way to categorise requirements is into technical and non-technical (or “business”) re- quirements. As the name implies, technical requirements usually cover the technical aspects of a product, such as size, power, etc. Non-technical requirements on the other hand apply to the business aspect of the aerospace organisation. These can range from regulatory requirements set by the European Union Aviation Safety Agency (EASA) [53] in Europe to quality requirements set by an ISO standard. This distinction is important because depending on their classification, the tools and means of validation will be di↵erent.
To give an impression of the extent of these standards, this section will focus on some standards set by ISO and ECSS which are applicable to the space industry. Throughout this section, several di↵erent standards will be discussed to various degrees. Discussing all relevant standards and each requirement included would exceed the scope of this thesis. For specific inquiries, it is recommended to review the standards.
2.3.1 International Organisation for Standardisation (ISO) / European Norm (EN)
ISO is the International Organization for Standardization [54]. It is based in Geneva, Switzerland [55] and currently (Jan 2021) has 165 member countries [56]. ISO has provided over 20 000 standards varying from management systems to technical aspects, information security, food safety, and many more [55]. Some of its most popular standards are addressed in this thesis, the ISO 9001 standard for quality management systems and the ISO 14001 standard for environmental management systems. Furthermore, standards such as the EN 9100 are based on ISO standards and simply add more specific requirements [57], see more here.
As mentioned, the two ISO standards examined in this thesis are the ISO 9001 Quality Manage- ment System Standard and the ISO 140001 Environmental Management System Standard. ISO 9001 is discussed because of its importance in the aerospace industry, especially with regards to the EN 9100 extension. ISO 14001 is highlighted because sustainability and the environment are becoming more prevalent topics for any organisation and corporation and thus should be considered even by the aerospace industry.
ISO 9001
ISO 9001 is part of the ISO 9000 family for quality management and the newest iteration of this standard was released in 2015 [58]. As mentioned previously, ISO 9001 specifically provides the requirements for a quality management system (QMS). As ISO puts it, the “adoption of a quality management system is a strategic decision for an organization that can help to improve its overall performance and provide a sound basis for sustainable development initiatives” [40].
The standard also states various benefits that organisations might experience if they implement this standard, including “consistently providing products that meet customer and applicable statutory and regulatory requirements” [40].
The standard provides the context with an introduction, scope, a normative reference and terms and definitions. The terms and definitions that are applied in ISO 9001:2015 can be found in a di↵erent standard from the same family, ISO 9000:2015. In general, some important terms to note are:
• “shall” indicates a requirement;
• “should” indicates a recommendation;
• “may” indicates a permission;
• “can” indicates a possibility or a capability.
These terms are used throughout the requirements of the standard and help understand the precise meaning of each clause. The requirements itself are categorised into “context of or- ganisation”, “leadership”, “planning”, “support”, “operation”, “performance evaluation”, and
“improvement” [40].
There are a few key principles discussed in this standard which are relevant to quality management systems regardless of whether one is intending to implement the standard or not. One of these are the quality management principles, as discussed in section 2.1.2. They describe values which should be encompassed by a QMS and provide a guideline to anyone looking into designing or optimising their QMS.
The standard also emphasises “risk-based thinking”, which is considered essential for achieving an e↵ective QMS. Analysing risks beforehand and implementing preventive action will reduce the risk of nonconformities and issues by addressing them before or when they arise. This leads to reduced costs and improved efficiency since errors are less likely to occur.
The standard also highlights the importance of continual improvement. As stated in 10.3 of ISO 9001: “The organization shall continually improve the suitability, adequacy and e↵ectiveness of the quality management system” [40]. This continual improvement is underlined by the PDCA cycle, which is stated in the beginning of the standard and was discussed further in section 2.1.3.
Continual improvement helps optimise the system as factors influencing the system may change, such as inputs, environments, etc.
The optimisation process is visualised in figure 2.14. It shows that a perfect system can only be reached asymptotically and as factors change, the optimality of the system decreases. As the second sequence shows, not every improvement cycle will lead to close to 100% optimality, or new input can be provided before 100% has been reached. Continually evaluating ones QMS and the processes involved in it is an important aspect of any QMS itself.
Fig. 2.14: BMS optimality over time when a company follow the process described in the optimisation wheel.
Companies that have implemented ISO 9001 have shown benefits both internally and exter- nally. Some of the benefits found were improved organisation, greater opportunities, increase in reputation, increased sales, improved quality of products, increased efficiency, and many more [59, 60, 61]. Studies have also shown that the motivation behind implementing the ISO 9001 standard influences the perceived benefits, specifically if the standard was implemented for internal reasons, these internal benefits were more prevalent than in companies implementing the standard for marketing or other external benefits [59].
On the other hand, companies had also noticed significant drawbacks with implementing ISO 9001, including increased bureaucracy, high implementation and maintenance costs, and increased complexity in processes [59, 60]. While there seems to be evidence that implementing ISO 9001 benefits operational performance [62], there does not seem to be clear evidence that an ISO 9001 certification directly improves financial performance [61, 62]. Overall, the benefits seem to outweigh the drawbacks.
EN 9100
The EN 9100 standard is an extension to the ISO 9001 standard, setting quality management standards for “aviation, space and defence organisations”. There are further standards specifically for software (EN 9115), maintenance services (EN 9110) and procurement of parts, materials, etc. (EN 9120) [57]. Rather than discussing all the requirements in this standard, a select few will be highlighted that are considered to be significant.
This standard duplicates the ISO 9001 standard and adds extra requirements and comments.
These comments are stylised in bold and italic font to clearly be distinguish from the ISO 9001 text. This means that if EN 9100 standard is implemented, the ISO 9001 standard is as well.
A noteworthy point is that this standard defines a few more terms, namely: counterfeit parts, critical items, key characteristics, product safety and special requirements; along with all the other terms in (EN) ISO 9000:2015 [57].
The additional requirements in this standard are focused on the aerospace and defense industry and illustrate the extensiveness of the requirements for space organisations. One of these addi- tional requirements is “[...] the organization shall plan and manage product and service provision in a structured and controlled manner including scheduled events performed in a planned sequence to meet requirements at acceptable risk, within resource and schedule constraints” (section 8.1) [57]. This goes along with the space project planning discussed in section 2.2.2 and the ECSS standard discussed later in this chapter, ECSS-M-ST-10C.
The standard also provides a note on what should be considered when determining requirements in section 8.1, such as the “reliability, availability and maintainability”; or the “recycling or final disposal of the product at the end of its life” [57]. EN 9100 also adds a section on “operational risk management”, one on “product safety” and a few others. Reading through the standard it becomes clear that even just within the QMS there are many more requirements specific for aerospace and defence organisations.
Studies on the implementation of EN 9100 are not as common as for ISO 9001. This is expected considering the reduced sample size – rather than any company implementing a quality manage- ment system, this standard only applies to European aerospace companies. Nevertheless, one study found that of the companies participating, 68% stated to be satisfied with the positive e↵ects of implementation of EN 9100 [63]. Some of the benefits found from implementing this standard were improved organisation, improved operations execution, improved Human Resources (HR) processes, improved financial success and improved customer relations [37]. The first three are considered internal benefits, and the latter two are external benefits. These compare to the benefits from implementing ISO 9001.
However, the perception of these benefits might vary depending on a few factors. One study found that the type of motivation behind implementing the EN 9100 standard, influenced the benefits that were perceived, specifically that if the motivation was for internal improvements, those benefits would be noticed [37]. This coincides with the findings found on the implementation of ISO 9001. They also noticed that the longer a company had adhered to EN 9100, the greater the benefits were [37]. Interestingly though, the size of the company didn’t have a significant impact on the perceived benefits, implying that large and small companies can benefit from implementing EN 9100 [37]. Similar conclusions were made on the factors for satisfaction with the standard, where internal motivation and length of adherence increases satisfaction while company size does not [63].
Acquiring a certification for either ISO 9001 or EN 9100 can be done by having an external auditor verify that the requirements of the standard have been met and thus accredit the organisation with a certification. The certifications cannot be acquired directly from ISO but are done through external bodies [64]. One of these bodies is the T ¨ UV NORD CERT which can provide certifications for ISO 9001:2015 and EN 9100 to organisations [65].
ISO 14001
ISO 14001 is a standard for Environmental Management Systems (EMS). As the International Organisation for Standardisation puts it, the aim of an EMS is to “protect the environment and respond to changing environmental conditions in balance with socio-economic needs” [66]. It is regarded as one of the most important examples of environmental proactivity [67].
Similar to ISO 9001, it encourages risk-based thinking and advocates for continual improvement.
It also points out that this standard can easily be implemented alongside other ISO management systems standards such as the ISO 9001 standard. The standards also describes how a company can show it conforms to the standard, for example by making a self-declaration or by seeking certification through an external organisation [66].
It is interesting to note that this standard emphasises that the success “depends on commitment from all levels and functions [...], led by top management” [66]. This coincides with what studies have found on ISO 9001, that involvement of management is essential for successfully implementing a management system and lack thereof can be an obstacle [60]. This also agrees with liter- ature on enterprise agility and the necessity of leadership involvement and leading by example [21].
The standard is similar to ISO 9001 in its requirements and emphasises, among other things, documentation. One of the requirements as part of 6.2.1 is that the organisation shall maintain documented information on the environmental objectives. Another requirement, 7.1 states that “the organisation shall determine and provide the resources needed for the establishment, implementation, maintenance and continual improvement of the environmental management system” [66]. And in section 8.1, the standard states that “the organisation shall maintain documented information to the extent necessary to have confidence that the processes have been carried out as planned.” Documentation is evidently an important factor within an EMS (and any management system for that matter) to ensure that information is available and traceability is achieved. It also emphasises the importance of monitoring, measuring, analysing and evaluating its environmental performance.
Adopting ISO 14001 can have a positive e↵ect on decreasing financial risk [68] and seems to have a positive correlation with financial performance [69]. However, it seems that it can have a negative impact on sales growth [68]. The main e↵ort required from implementing this standard seems to be improving energy efficiency and reducing waste [70].
For companies intending to implement ISO 14001 and ISO 9001, the integrated approach has been found to be beneficial [69, 70]. By integrating both standards and thus a QMS and EMS into a shared management system, duplication of the requirements can be avoided. This goes along with the theory discussed in section 2.1, which states that it is advisable to combine the di↵erent management systems into one and ideally design and implement them alongside one another. Since ISO 14001 is more of a framework, combining it with performance measurement is beneficial [70].
Overall, implementing standards seem to have a positive e↵ect. One study found that imple- menting the standard early, might lead to a “locked” mentality as companies would not strive to see outside these standards [68]. However, a di↵erent study examining the implementation of the EN 9100 standard found that benefits increased with time [37]. This could imply that there might be a perfect time as to when to acquire a management system standard. However, that is for another thesis to determine.
2.3.2 ECSS Standards
ECSS standards are written and published by the European Cooperation for Space Standardis- ation (ECSS). ECSS currently has 7 members, including, among others, the European Space Agency (ESA), Centre National d’Etudes Spatiales (CNES) (the French Space Agency) and the Deutsche Luft-und Raumfahrt Gesellschaft (DLR) (the German Space Agency) [71].
The ECSS standards are organised according to their area of application as seen in table 2.3, where the identifier is part of the name of each standard.
Identifier M
E Q U
Explanation Management Engineering Product Assurance
Sustainability
Table 2.3: Classification and Identifiers of the ECSS standards.
Standards get reviewed and updated by ECSS, which is why some might have a ”Rev1” or end in “C” rather than “A”, in their title, indicating that it is a reviewed or updated standard, respectively. Due to the changes from reviews and updates, standards are categorised as Active or Superseded. Currently (January 2021), there are 135 Active ECSS Standards [72]. Discussing every standard would exceed the scope of this thesis, so a select few will be examined.
Unfortunately, compared to the ISO and EN standards discussed previously, no literature on implementation benefits or drawbacks could be found. Therefore, the following sections will address a selection of the standards, some of their requirements and examine di↵erent aspects of them.
ECSS-E-ST-10C-Rev1, Space engineering: System engineering general requirements This standard examines the requirements to the system engineering function of a space organ- isation. System engineering is a cross-functional e↵ort to combine requirements into a single system-based solution [46]. It is a common approach in spacecraft design and is also discussed in section 2.2.3.
The structure of this standard is similar to the ISO standards with a glossary of terms, a list of abbreviations, and more, however, it also provides a description of the roles in one section and concrete requirements in the other. It examines sub-functions to the system engineering role, which include requirement engineering, design verification and more. It also gives system engineering tasks per project phase as discussed in section 2.2.2 and defined by ECSS-M-ST-10C.
The requirements in this standard can help system engineers understand their role and the importance of requirements management and traceability. It can be recommended to any space project as it illustrates how intertwined di↵erent systems are. When not explicitly required, it can be used as a guideline to approach systems engineering in complex space projects.
