Editing Systems engineering (section)

==Systems engineering topics==
Systems engineering tools are [[strategies]], procedures, and [[wikt:technique|techniques]] that aid in performing systems engineering on a [[project]] or [[Product (business)|product]]. The purpose of these tools varies from database management, graphical browsing, simulation, and reasoning, to document production, neutral import/export, and more.<ref>{{cite web|url=http://www.marc.gatech.edu/events/pde2005/presentations/0.2-jenkins.pdf|title=A Future for Systems Engineering Tools|author=Steven Jenkins|publisher=NASA|page=15|access-date=10 June 2007|archive-url=https://web.archive.org/web/20070926044858/http://www.marc.gatech.edu/events/pde2005/presentations/0.2-jenkins.pdf|archive-date=26 September 2007}}</ref>

===System===
{{Main|System}}
There are many definitions of what a [[system]] is in the field of systems engineering. Below are a few authoritative definitions:

* [[ANSI]]/[[Electronic Industries Alliance|EIA]]-632-1999: "An aggregation of end products and enabling products to achieve a given purpose."<ref>{{cite web|title=Processes for Engineering a System|url=http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2fEIA-632-1999|year=1999|publisher=[[Electronic Industries Alliance]]|language=en|access-date=17 June 2018|archive-date=5 July 2010|archive-url=https://web.archive.org/web/20100705203209/http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2fEIA-632-1999|url-status=dead}}</ref>
* [[Defense Acquisition University|DAU]] Systems Engineering Fundamentals: "an integrated composite of people, products, and processes that provide a capability to satisfy a stated need or objective."<ref>{{cite web|url=https://ocw.mit.edu/courses/aeronautics-and-astronautics/16-885j-aircraft-systems-engineering-fall-2005/readings/sefguide_01_01.pdf|title=Systems Engineering Fundamentals|website=OCW.MIT.edu|date=January 2001}}</ref>
* [[IEEE]] Std 1220-1998: "A set or arrangement of elements and processes that are related and whose behavior satisfies customer/operational needs and provides for life cycle sustainment of the products."<ref>{{cite web|title=Standard for Application and Management of the Systems Engineering Process|url=http://standards.ieee.org/reading/ieee/std_public/description/se/1220-1998_desc.html|archive-url=https://web.archive.org/web/20090801062355/http://standards.ieee.org/reading/ieee/std_public/description/se/1220-1998_desc.html|archive-date=2009-08-01|url-status=dead|publisher=IEEE|language=en}}</ref>
* INCOSE Systems Engineering Handbook: "homogeneous entity that exhibits predefined behavior in the real world and is composed of heterogeneous parts that do not individually exhibit that behavior and an integrated configuration of components and/or subsystems."<ref>{{cite web|title=Systems Engineering Handbook|url=http://www.incose.org/ProductsPubs/products/sehandbook.aspx|volume=3|year=2007|issue=1 |url-status=dead|publisher=[[INCOSE]]|access-date=10 July 2009|archive-date=18 March 2015|archive-url=https://web.archive.org/web/20150318022214/http://www.incose.org/ProductsPubs/products/sehandbook.aspx}}</ref>
* INCOSE: "A system is a construct or collection of different elements that together produce results not obtainable by the elements alone. The elements, or parts, can include people, hardware, software, facilities, policies, and documents; that is, all things required to produce systems-level results. The results include system-level qualities, properties, characteristics, functions, behavior, and performance. The value added by the system as a whole, beyond that contributed independently by the parts, is primarily created by the relationship among the parts; that is, how they are interconnected."<ref>{{cite web|title=A Consensus of the INCOSE Fellows|url=http://www.incose.org/practice/fellowsconsensus.aspx|year=2006|url-status=dead|publisher=[[INCOSE]]|access-date=10 July 2009|archive-date=29 October 2006|archive-url=https://web.archive.org/web/20061029124419/http://g2sebok.incose.org/app/mss/menu/index.cfm}}</ref>
* [[ISO/IEC]] 15288:2008: "A combination of interacting elements organized to achieve one or more stated purposes."<ref>{{cite web|title=Systems and software engineering - System life cycle processes|url=http://www.15288.com/|year=2008|url-status=dead|access-date=10 July 2009|archive-date=6 August 2019|archive-url=https://web.archive.org/web/20190806051950/http://www.15288.com/}}</ref>
* [[NASA]] Systems Engineering Handbook: "(1) The combination of elements that function together to produce the capability to meet a need. The elements include all hardware, software, equipment, facilities, personnel, processes, and procedures needed for this purpose. (2) The end product (which performs operational functions) and enabling products (which provide life-cycle support services to the operational end products) that make up a system."<ref>{{cite book|title=NASA Systems Engineering Handbook|id=NASA/SP-2007-6105|publisher=[[NASA]]|date=2007|url=https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301_2008008500.pdf}}</ref>

===Systems engineering processes===
Systems engineering processes encompass all creative, manual, and technical activities necessary to define the product and which need to be carried out to convert a system definition to a sufficiently detailed system design specification for product manufacture and deployment. Design and development of a system can be divided into four stages, each with different definitions:<ref name="lienig">{{Cite book|author1=J. Lienig|author2=H. Bruemmer|title=Fundamentals of Electronic Systems Design|pages=6–7|publisher=Springer International Publishing|date=2017|isbn=978-3-319-55839-4|doi=10.1007/978-3-319-55840-0}}</ref> 
* Task definition (informative definition)
* Conceptual stage (cardinal definition)
* Design stage (formative definition)
* Implementation stage (manufacturing definition)

Depending on their application, tools are used for various stages of the systems engineering process:<ref name="SEF01"/>
[[File:Systems Engineering Process.jpg|center]]

===Using models===
{{Main|Abstract model}}
[[Abstract model|Model]]s play important and diverse roles in systems engineering. A model can be defined in several
ways, including:<ref name="NASA95">{{cite web|title=System Analysis and Modeling Issues - NASA Systems Engineering Handbook|url=http://human.space.edu/old/docs/Systems_Eng_Handbook.pdf|year=1995|archive-url=https://web.archive.org/web/20081217005338/http://human.space.edu/old/docs/Systems_Eng_Handbook.pdf|pages=85|archive-date=2008-12-17|url-status=dead|language=en}}</ref>
* An abstraction of reality designed to answer specific questions about the real world
* An imitation, analog, or representation of a real-world process or structure; or
* A conceptual, mathematical, or physical tool to assist a decision-maker.
Together, these definitions are broad enough to encompass physical engineering models used in the verification of a system design, as well as schematic models like a [[functional flow block diagram]] and mathematical (i.e. quantitative) models used in the trade study process. This section focuses on the last.<ref name="NASA95"/>

The main reason for using [[mathematical model]]s and [[Mathematical diagram|diagrams]] in trade studies is to provide estimates of system effectiveness, performance or technical attributes, and cost from a set of known or estimable quantities. Typically, a collection of separate models is needed to provide all of these outcome variables. The heart of any mathematical model is a set of meaningful quantitative relationships among its inputs and outputs. These relationships can be as simple as adding up constituent quantities to obtain a total, or as complex as a set of [[differential equation]]s describing the trajectory of a spacecraft in a [[gravitational field]]. Ideally, the relationships express causality, not just correlation.<ref name="NASA95"/> Furthermore, key to successful systems engineering activities are also the methods with which these models are efficiently and effectively managed and used to simulate the systems. However, diverse domains often present recurring problems of modeling and simulation for systems engineering, and new advancements are aiming to cross-fertilize methods among distinct scientific and engineering communities, under the title of 'Modeling & Simulation-based Systems Engineering'.<ref>{{cite book|editor1-last=Gianni|editor1-first=Daniele|editor2-last=D'Ambrogio|editor2-first=Andrea|editor3-last=Tolk|editor3-first=Andreas|title=Modeling and Simulation-Based Systems Engineering Handbook|date=4 December 2014|publisher=CRC Press|isbn=9781466571457|edition=1st|url=http://www.crcpress.com/product/isbn/9781466571457|page=}}</ref>{{Page needed|date=March 2023}}

===Modeling formalisms and graphical representations===
Initially, when the primary purpose of a systems engineer is to comprehend a complex problem, graphic representations of a system are used to communicate a system's [[functional requirement|functional]] and data requirements.<ref>{{Cite web|url=http://www.vitechcorp.com/resources/technical_papers/200701031634430.CommonGraphicalRepresentations_2002.pdf|title=Relationships between Common Graphical Representations in System Engineering|last=Long|first=Jim|publisher=[[Vitech Corporation|VitechCorp]]|date=2002|archive-url=https://web.archive.org/web/20170813085941/http://www.vitechcorp.com/resources/technical_papers/200701031634430.commongraphicalrepresentations_2002.pdf|archive-date=13 August 2017}}</ref> Common graphical representations include:
* [[Functional flow block diagram]] (FFBD)
* [[Model-based design]]
* [[Data flow diagram]] (DFD)
* [[N2 chart]]
* [[IDEF0|IDEF0 diagram]]
* [[Use case|Use case diagram]]
* [[Sequence diagram]]
* [[Block diagram]]
* [[Signal-flow graph]]
* [[Universal Systems Language#Formalism for a theory of control|USL function maps and type maps]]
* [[Enterprise architecture framework]]s

A graphical representation relates the various subsystems or parts of a system through functions, data, or interfaces. Any or each of the above methods is used in an industry based on its requirements. For instance, the N2 chart may be used where interfaces between systems are important. Part of the design phase is to create [[Structural model (software)|structural]] and [[behavioral model]]s of the system.

Once the requirements are understood, it is now the responsibility of a systems engineer to refine them and to determine, along with other engineers, the best technology for a job. At this point starting with a trade study, systems engineering encourages the use of weighted choices to determine the best option. A [[decision matrix]], or Pugh method, is one way (QFD is another) to make this choice while considering all criteria that are important. The trade study in turn informs the design, which again affects graphic representations of the system (without changing the requirements). In an SE process, this stage represents the iterative step that is carried out until a feasible solution is found. A decision matrix is often populated using techniques such as statistical analysis, reliability analysis, system dynamics ([[feedback control]]), and optimization methods.

===Other tools===
====Systems Modeling Language====
{{Main|Systems Modeling Language}}
[[Systems Modeling Language]] (SysML), a modeling language used for systems engineering applications, supports the specification, analysis, design, verification and validation of a broad range of complex systems.<ref>{{cite web|url=http://www.sysml.org/docs/specs/OMGSysML-FAS-06-05-04.pdf|title=OMG SysML Specification|page=23|publisher=SysML Open Source Specification Project|access-date=3 July 2007}}</ref>

====Lifecycle Modeling Language====
{{Main|Lifecycle Modeling Language}}
[[Lifecycle Modeling Language]] (LML), is an open-standard modeling language designed for systems engineering that supports the full lifecycle: conceptual, utilization, support, and retirement stages.<ref>{{cite web|url=http://www.lifecyclemodeling.org/spec/LML_Specification_1_0.pdf|title=LML Specification|page=4|publisher=LML Steering Committee|access-date=5 June 2014|archive-date=6 May 2014|archive-url=https://web.archive.org/web/20140506233550/http://www.lifecyclemodeling.org/spec/LML_Specification_1_0.pdf|url-status=dead}}</ref>