SIST EN 14514:2005
(Main)Space engineering standards - Functional analysis
Space engineering standards - Functional analysis
This document defines the requirements to perform functional analysis and the information output of that analysis. It applies to all types and combinations of space systems, projects and products. It also applies to project phases 0, A, B and C and at all levels.
When viewed from the perspective of a specific project context, the requirements defined in this document should be tailored to match the genuine requirements of a particular profile and circumstances of a project.
NOTE Tailoring is a process by which individual requirements of specifications, standards and related documents are evaluated and made applicable to a specific project by selection, and in some exceptional cases, modification of existing or addition of new requirements.
Raumfahrttechnik Normen - Funktionenanalyse
Diese Norm legt die Anforderungen zur Durchführung der Funktionenanalyse und hinsichtlich der Ergebnisse dieser Analyse fest. Sie gilt für alle Arten und Kombinationen von Raumfahrtsystemen, projekten und produkten und für die Projektphasen 0, A, B und C auf allen Ebenen.
Die in dieser Norm festgelegten Anforderungen sind programm- oder projektspezifisch anzupassen, d. h. auf das Anforderungsprofil und Betriebsbedingungen des einzelnen Programms bzw. Projekts abzustimmen (tailoring).
ANMERKUNG Tailoring ist ein Prozess, in dem einzelne Anforderungen in Spezifikationen, Normen und ähnlichen Dokumenten nach Bewertung für ein bestimmtes Projekt ausgewählt und in Ausnahmefällen auch modifiziert oder indem neue Anforderungen ergänzt werden.
Normes d'ingénierie spatiale - Analyse fonctionnelle
Standardi v vesoljski tehniki – Analiza funkcij sistema
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Standardi v vesoljski tehniki – Analiza funkcij sistemaRaumfahrttechnik Normen - FunktionenanalyseNormes d'ingénierie spatiale - Analyse fonctionnelleSpace engineering standards - Functional analysis49.140Vesoljski sistemi in operacijeSpace systems and operationsICS:Ta slovenski standard je istoveten z:EN 14514:2004SIST EN 14514:2005en01-januar-2005SIST EN 14514:2005SLOVENSKI
STANDARD
SIST EN 14514:2005
EUROPEAN STANDARDNORME EUROPÉENNEEUROPÄISCHE NORMEN 14514August 2004ICS 49.140English versionSpace engineering standards - Functional analysisNormes d'ingénierie spatiale - Analyse fonctionnelleRaumfahrttechnik Normen - FunktionenanalyseThis European Standard was approved by CEN on 21 February 2003.CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this EuropeanStandard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such nationalstandards may be obtained on application to the Central Secretariat or to any CEN member.This European Standard exists in three official versions (English, French, German). A version in any other language made by translationunder the responsibility of a CEN member into its own language and notified to the Central Secretariat has the same status as the officialversions.CEN members are the national standards bodies of Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France,Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia,Slovenia, Spain, Sweden, Switzerland and United Kingdom.EUROPEAN COMMITTEE FOR STANDARDIZATIONCOMITÉ EUROPÉEN DE NORMALISATIONEUROPÄISCHES KOMITEE FÜR NORMUNGManagement Centre: rue de Stassart, 36
B-1050 Brussels© 2004 CENAll rights of exploitation in any form and by any means reservedworldwide for CEN national Members.Ref. No. EN 14514:2004: ESIST EN 14514:2005
EN 14514:2004 (E) 2 Contents page Foreword.4 1 Scope.5 2 Normative references.5 3 Terms, definitions and abbreviated terms.5 3.1 Terms and definitions.5 3.2 Abbreviated terms.6 4 Principles and methods of functional analysis.6 4.1 Principles.6 4.2 Methods.6 4.3 Objectives.7 4.4 Logic and implementation overview.7 4.4.1 Performance.7 4.4.2 Implementation.7 4.4.3 Functional status.10 5 Functional analysis process.10 5.1 Definition and identification.10 5.1.1 System definition.10 5.1.2 Definition of the level of detail.10 5.1.3 Identification of functions.10 5.2 Representation of the system.11 5.2.1 General.11 5.2.2 Function tree.11 5.2.3 Functional matrix.13 5.2.4 Functional block diagram.14 5.3 Functional analysis and engineering disciplines.16 5.3.1 General.16 5.3.2 Functional analysis and requirements.16 5.3.3 Functional specification.17 5.3.4 Off–the–shelf item assessment.17 5.3.5 Software.17 5.3.6 Operations.18 5.3.7 Traceability.18 5.3.8 Verification.18 5.4 Functional analysis and other disciplines.19 5.4.1 Dependability and safety.19 5.4.2 Functional analysis and management.19 6 Functional analysis and project phases.20 6.1 Objectives.20 6.2 Project phases.20 6.2.1 Phase 0.20 6.2.2 Phase A.20 6.2.3 Phase B.21 6.2.4 Phase C.21 Bibliography.22
SIST EN 14514:2005
EN-14514:2004 (E) 3 List of figures Figure 1 — Functional analysis implementation overview.9 Figure 2 — Function tree.12 Figure 3 — Function tree.13 Figure 4 — Functional matrix.14 Figure 5 — Functional block diagram.16 SIST EN 14514:2005
EN 14514:2004 (E) 4
Foreword This document (EN 14514:2004) has been prepared by CMC. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by February 2005, and conflicting national standards shall be withdrawn at the latest by February 2005. It is based on a previous version1) prepared by the ECSS Engineering Standard Working Group, reviewed by the ECSS Technical Panel and approved by the ECSS Steering Board. The European Cooperation for Space Standardization (ECSS) is a cooperative effort of the European Space Agency, National Space Agencies and European industry associations for the purpose of developing and maintaining common standards. This document is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications.
Requirements in this document are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards. The formulation of this document takes into account the existing ISO 9000 family of documents. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard Austria, Belgium, Cyprus, Czech Republic, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
1) ECSS-E-10-05A SIST EN 14514:2005
EN-14514:2004 (E) 5 1 Scope This document defines the requirements to perform functional analysis and the information output of that analysis. It applies to all types and combinations of space systems, projects and products. It also applies to project phases 0, A, B and C and at all levels. When viewed from the perspective of a specific project context, the requirements defined in this document should be tailored to match the genuine requirements of a particular profile and circumstances of a project. NOTE
Tailoring is a process by which individual requirements of specifications, standards and related documents are evaluated and made applicable to a specific project by selection, and in some exceptional cases, modification of existing or addition of new requirements. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. EN 13701:2001, Space systems – Glossary of terms EN 13290-4, Space project management – General requirements – Part 4: Project phasing and planning 3 Terms, definitions and abbreviated terms 3.1 Terms and definitions For the purposes of this document, the terms and definitions given in EN 13701:2001 and following apply. 3.1.1 constraint characteristic, result or design feature which is made compulsory or has been prohibited for any reason NOTE 1 Constraints are generally restrictions on the choice of solutions in a system. NOTE 2 Two kinds of constraints are considered, those which concern solutions, and those which concern the use of the system. NOTE 3 For example constraints can come from environmental and operational conditions, law, standards, market demand, investments and means availability, organization’s policy. NOTE 4 Adapted from EN 1325-1. 3.1.2 function intended effect of a system, subsystem, product or part NOTE 1 Adapted from EN 1325-1. NOTE 2 Functions should have a single definite purpose. Function names should have a declarative structure (e.g. “Validate Telecommands”), and say “what” is to be done rather than “how”. Good naming allows design components with strong cohesion to be easily derived. 3.1.3
functional analysis technique of identifying and describing all functions of a system NOTE Adapted from EN 1325-1. SIST EN 14514:2005
EN 14514:2004 (E) 6 3.1.4
operational mode manner or way of operating NOTE The mode is realized by a group of related functions or tasks required to accomplish a specific operation. 3.1.5 operational scenario summary of sequences of events and the environment for a specific operation 3.1.6 functional specification document by which the customer establishes the intended purpose of a product, its associated constraints and environment, the operational and performances features, and the permissible flexibility NOTE 1 This document contains a complete set of provisional technical requirements for a product. NOTE 2 This term is equivalent to functional performance specification as defined in EN 1325-1. 3.1.7 technical specification specification expressing technical requirements for designing and developing the solution to be implemented NOTE
The technical specification evolves from the functional specification and defines the technical requirements for the selected solution as part of a business agreement
3.2 Abbreviated terms The following abbreviated terms are defined and used within this document. Abbreviation Meaning FMECA failure modes effects and criticality analysis ROD review of design RAMS reliability, availability, maintainability and safety 4 Principles and methods of functional analysis 4.1 Principles In order to design, develop and prove any space engineering system, the mission and consequent functions, that the system shall perform, is clearly established. This functionality is distributed throughout the different design levels (e.g. systems, subsystems and units). This allocation of the system functions in a systematic way is an important step in establishing a design which meets all the design objectives. 4.2 Methods Functional analysis is the technique of identifying and describing all the functions of a system. The purpose of the analysis is to identify and partition all the functions of any system required to perform the intended mission.
The analysis is performed to establish the system functions and to control the distribution and maintenance of these functions in a systematic and useful manner. Three techniques: function tree, functional matrix and functional block diagram are described, although it is recognized that other representations can also prove suitable. SIST EN 14514:2005
EN-14514:2004 (E) 7 At the top system level, the required functions are derived from the mission statement and are the basis of the system functional specifications. All these functions can be considered ”external” functions.
The solution to meet these functions can lead to new lower level functions to be identified which are a result of the chosen solution. These new functions are either serviced at the system level where they were derived, in which case the function is satisfied, or passed to a lower level. A function, which is passed to a lower level, is a higher level function for the recipient level.
As the detail of the design progresses, each tier of the design add additional functions necessary to support the higher level functions. Both types of functions can be either solved internally within the system or refined into requirements and functions to be met at some lower level engineering unit. Thus, some functions have different levels of importance associated with them depending on how and where they originated. Some functions are readily achievable, while others are complex and expensive to meet. Often at the lower levels, solutions are available which readily meet most of the functions or during development it is established that a particular function is only met under specific conditions. The knowledge of the origins of any function allows to establish the consequences and impact of not meeting a requirement or to allow a function to be renegotiated.
Changes to requirements can arise at top system level, in which case the ”sub”-derived functions, which are affected at the lower tier level, are readily identifiable. A realistic example of top system level changes occurs when the launch vehicle is changed and as a consequence, the vibration spectrum or human factors can alter. Functional analysis includes different activities. The complexity of the analyses adapts considering the design maturity, the evolution of the design and the complexity of the mission. The ultimate aim is to achieve the simplest final design which meets all the system requirements and offers the best value by achieving that all the functions are met and also partitioned in a logical manner.
Functional analysis is performed in a systematic manner. Function are not passed from one system to another system of the same level, but are received from a higher level system and either serviced or further distributed (and divided if necessary) to lower level systems.
Functional analysis excludes the assessment of the criticality of the functions in terms of reliability and safety, but can serve as the basis of the functional failure analysis. Functional analysis also excludes any consideration of the engineering solution required to service an identified function, until ”internal” functions are identified as part of the required solution. By considering a system in terms of functions (being the problem to solve) and not in terms of technology (a possible solution), alternative technologies are not excluded, duplication can be avoided and components standardization can be improved.
4.3 Objectives The objectives of functional analysis are to: a) identify or update the functional requirements; b) ensure the functions are partitioned in an appropriate manner; c) allow the traceability of the functions; d) identify the interfaces between functions. This allows a complex engineering system to be understood and realized.
4.4 Logic and implementation overview 4.4.1 Performance Functional analysis is performed as part of the overall design development process.
4.4.2 Implementation The following functional analysis steps are implemented to: SIST EN 14514:2005
EN 14514:2004 (E) 8 a) define the system and boundaries of the system under analysis by using the relevant requirements documents; b) define the level of detail (depth of analysis); c) identify the system functions, operational modes and operational scenarios; d) represent the system by preparing the function tree(s), or functional matrix(ces), or functional block diagram(s). The sequence of steps outlined above are valid for all uses, but the steps which are applied are determined on a case by case basis. The most common representation of the system is the function tree. The whole process is illustrated in Figure 1. SIST EN 14514:2005
EN-14514:2004 (E) 9
Figure 1 — Functional analysis implementation overview SIST EN 14514:2005
EN 14514:2004 (E) 10 4.4.3 Functional status Functional analysis shall reflect the functional status of the system design. Each iteration of functional analysis shall provide more detail at lower levels of the functional system hierarchy. 5 Functional analysis process 5.1 Definition and identification 5.1.1 System definition
A system shall be designed to conform to a given objective, i.e. satisfy the requirement of the users by performing a specified set of functions. It can be affected by the environment, acted upon by external systems or act itself upon the environment or external system. The users and the environment are outside the system. 1) The boundaries of a system or a product shall be defined by its relationship with the different external elements. External elements shall be users, the environment and the external systems. The system engineering process shall begin with the identification of the requirement, which is linked to a given user in a given situation and is conditioned by place, time and environment (e.g. humidity and ice). The given situation, the place, the environment and interfaces with external systems generate constraints.
2) The requirements and the constraints shall be described in terms of functions, not in terms of solutions. During its life cycle a system or a product is placed in different situations and environments, which in turn generate constraints. Situations and environments may be characterized as nominal, worst case or contingency as relevant. 3) The different constraints generated by the different encountered conditions of a system shall be taken into account. 4) The functions and the constraints shall be completed by performance criteria. 5.1.2 Definition of the level of detail The level of detail in performing functional analysis is determined by design maturity and normally increases during the project life cycle. To avoid a non-productive level of detail, the analyst shall have a clear understanding of the analysis objectives applicable to the specific project phase for which the design is considered current. 1) The level of detail of functional analysis shall be described and documented.
2) The level of detail shall be in accordance with the contractual requirements and with the design maturity. 5.1.3 Identification of functions A function may be decomposed into lower level functions. This division of the functions of a system, which shall start from the functional specification, is an essential part of functional analysis, and results in a hierarchical structure of functions. Functional analysis shall: 1) provide the identification of the functions of the system; 2) identify the functions required to be performed in the different operational scenarios of the analysed mission; 3) identify the functions required by the different operational modes of the system. Operational modes include contingency modes induced by failures, faults or operator errors; SIST EN 14514:2005
EN-14514:2004 (E) 11 4) provide a hierarchical decomposition of the functions of the system.
A hierarchical structure of the functions of a system provides clear visibility of the large number of functional elements making up the system. A hierarchical structure enables errors, omissions, inconsistencies and duplications to be detected. A hierarchical structure starting at the higher level requirements and working down in detail, allows verification that the lower level functions are consistent with the top-level functions. 5) The hierarchical functional decomposition of the system shall ensure traceability between functional requirements throughout all the levels. Each function should not be decomposed at the next lower level into more than seven subfunctions. 6) Functions shall be appropriate to the level at which they appear. To assess if the functions are appropriate at the level at which they appear, the following questions shall be asked:
• “Why is the function required?” • “How is the function realized?” 7) Different hierarchical structures, or substructures, shall be produced when alternative functional solutions are considered.
Alternative functional solutions can meet the same functional requirements. The different functional hierarchical structures can be used to provide a better assessment of the different options. 8) Alternatives functional solutions shall be analysed and compared in a dedicated section of the functional analysis document. NOTE Functional analysis shall identify the interrelationships between the functions. 5.2 Representation of the system 5.2.1 General The following functional analysis methods to define and represent a system, i.e. the function tree, the functional matrix and the functional block diagram, overlap to some extent. This systematic sorting of the functions aids the definition of the design, verification and traceability of the requirements and also the performance of the FMECAs, safety and reliability analyses. If not specified by the customer, the most suitable method(s) shall be chosen for the specific analysis to be performed. The choice of methods and the areas of application shall be justified. 5.2.2 Function tree Tree structures provide clear visibility of the large number of functional elements making up a system. A tree structure enables errors, omissions, inconsistencies and duplications to be detected through the branches. A hierarchical structure starting at system level working down in detail, allows verification that the lower level functions are consistent with the top-level functions. A graphical hierarchical structure can be especially useful during the initial decomposition and structuring of functional requirements. The tree allows the functions to be regrouped and the relationship between functions to be established.
A lower level function can be utilized by a number of main functions and therefore it may appear several times in the function tree. Interfaces, information in and out, may be identified separately in a textual form and cross referenced to the functions in the tree representation. Function trees may be represented in many ways. Two suitable representations of the same example are given in Figure 2 and Figure 3. 1) A function tree shall be based on the system requirements, functional requirements, and already defined functions. 2) A function tree shall specify the level in the functional hierarchy used for its preparation. 3) Each functional requirement in the reference set of requirements shall be arranged in a hierarchical manner. SIST EN 14514:2005
EN 14514:2004 (E) 12 4) Functions shall be decomposed into lower level functions. At the top level, the tree shall be a graphical representation of the system requirements, with parallel hierarchies for each of the different major functions. Each level of the tree shall represent the system functions at that specific level of abstraction. It shall provide similar levels of detail for each of the functions represented at that level. Functions at level “n” shall be decomposed into functions of level “n+1”. 5) Functions different from those traceable to the reference set of requirements shall not be introduced. 6) All functions shall be numbered in a manner allowing the higher level functions to be readily identified. 7) All functions shall be numbered in a manner allowing any existing lower level functions to be readily identified. 8) Functional levels shall not be omitted. 9) No functions shall be inserted between levels of the function tree. 10) Alternative functional solutions to insure the required functions shall be investigated and represented by different function trees. 11) All apparent inconsistencies in the nomenclature, functionality and structure of the function tree shall be identified and documented. Identified inconsistencies should be removed or rational for retention should be provided. 12) Functions identified to satisfy a customer’s requirement shall be distinguished from those identified to satisfy a requirement generated by the selected functional solutions.
Figure 2 – Function tree SIST EN 14514:2005
EN-14514:2004 (E) 13
Figure 3 — Function tree 5.2.3 Functional matrix Functional matrices should be used to complement the function tree, to represent the relationship between lower and higher functions, and between functions and operational modes and operational scenarios. They may cover the complete system or some specific areas. A number of matrices at different levels may be used.
1) A functional matrix shall be based on system requirements, functional requirements, already defined functions and system functional hierarchy. 2) A functional matrix shall specify the level in the functional hierarchy used for its preparation. 3) Different functional matrices shall be prepared to investigate and represent selected alternative functional (design) solutions. 4) The scope
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.