Difference between pages "Logical Architecture" and "Emergence"

From SEBoK
(Difference between pages)
Jump to navigation Jump to search
(Byline)
 
(Tech and grammar edits as discussed with Bkcase)
 
Line 1: Line 1:
 
----
 
----
−
'''''Lead Authors:''''' ''Alan Faisandier, Garry Roedler'', '''''Contributing Author:''''' ''Rick Adcock''
+
'''''Lead Author:''''' ''Rick Adcock'', '''''Contributing Authors:''''' ''Scott Jackson, Dick Fairley, Janet Singer, Duane Hybertson''
 
----
 
----
−
Logical Architecture Model Development may be used as a task of the activity "Develop candidate architectures models and views", or a sub-process of the System Architecture Definition process (see '''[[System Architecture]]'''). Its purpose is to elaborate models and views of the functionality and behavior of the future {{Term|Engineered System (glossary)|engineered system}} as it should operate, while in service. The {{Term|Logical Architecture (glossary)|logical architecture}} model of a engineered {{Term|System of Interest (SoI) (glossary)|system of interest (SoI)}} is composed of a set of related technical concepts and principles that support the logical operation of the system. It may include a {{Term|Functional Architecture (glossary)|functional architecture}} view, a {{Term|Behavioral Architecture (glossary)|behavioral architecture}} view, and a {{Term|Temporal Architecture (glossary)|temporal architecture}} view. Other additional views are suggested in {{Term|Architecture Framework (glossary)|architecture frameworks}}, depending on the domain.
+
This topic forms part of the [[Systems Fundamentals]] knowledge area (KA). It gives the background to some of the ways in which {{Term|Emergence (glossary)|emergence}} has been described, as well as an indication of current thinking on what it is and how it influences {{Term|Systems Engineering (glossary)|systems engineering}} (SE) practice. It will discuss how these ideas relate to the general definitions of {{Term|System (glossary)|systems}} given in [[What is a System?]]; in particular, how they relate to different {{Term|Engineered System (glossary)|engineered system}} contexts. This topic is closely related to the [[Complexity|complexity]] topic that precedes it.
  
−
Note: The term ''Logical Architecture'' is a contraction of the expression ''Logical View of the System Architecture''.
+
Emergence is a consequence of the fundamental system {{Term|Concept (glossary)|concepts}} of {{Term|Holism (glossary)|holism}} and interaction (Hitchins 2007, 27).  System wholes have {{Term|Behavior (glossary)|behaviors}} and properties arising from the organization of their {{Term|Element (glossary)|elements}} and their relationships, which only become apparent when the system is placed in different {{Term|Environment (glossary)|environments}}.
  
−
==Concepts and Principles==
+
Questions that arise from this definition include: What kinds of systems exhibit different kinds of emergence and under what conditions? Can emergence be predicted, and is it beneficial or detrimental to a system? How do we deal with emergence in the development and use of engineered systems? Can it be planned for? How?
  
−
===Functional Architecture Model===
+
There are many varied and occasionally conflicting views on emergence. This topic presents the prevailing views and provides references for others.
  
−
A {{Term|Functional Architecture (glossary)|functional architecture}} model is a set of functions and their sub-functions that defines the transformations performed by the system to complete its mission.
+
==Overview of Emergence==
 +
As defined by Checkland, {{Term|Emergence (glossary)|emergence}} is “the principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts.” (Checkland 1999, 314). Emergent system {{Term|Behavior (glossary)|behavior}} can be viewed as a consequence of the interactions and relationships between {{Term|System Element (glossary)|system elements}} rather than the behavior of individual elements. It emerges from a combination of the behavior and properties of the system elements and the systems structure or allowable interactions between the elements, and may be triggered or influenced by a stimulus from the systems environment.
  
−
'''Function and Input-Output Flow''' - In the context of System Architecture, functions and input-output flows are architecture entities. A {{Term|Function (glossary)|function}} is an action that transforms inputs and generates outputs, involving data, materials, and/or energies. These inputs and outputs are the flow items exchanged between functions. The general mathematical notation of a function is '''''y''''' ''= ƒ('' '''''x''''' '',t)'', in which '''y''' and '''x''' are vectors that may be represented graphically and t = time.
+
Emergence is common in nature. The pungent gas ammonia results from the chemical combination of two odorless gases, hydrogen and nitrogen. As individual parts, feathers, beaks, wings, and gullets do not have the ability to overcome gravity; however, when properly connected in a bird, they create the emergent behavior of flight. What we refer to as “self-awareness” results from the combined effect of the interconnected and interacting neurons that make up the brain (Hitchins 2007, 7).  
  
−
In order to define the complete set of functions of the system, one must identify all the functions necessitated by the system and its derived requirements, as well as the corresponding inputs and outputs of those functions. Generally speaking, there are two kinds of functions:
+
Hitchins also notes that technological systems exhibit emergence. We can observe a number of levels of outcome which arise from interaction between elements in an {{Term|Engineered System (glossary)|engineered system}} context.  At a simple level, some system outcomes or {{Term|Attribute (glossary)|attributes}} have a fairly simple and well defined mapping to their {{Term|Element (glossary)|elements}}; for example, center of gravity or top speed of a vehicle result from a combination of element properties and how they are combined.  Other behaviors can be associated with these simple outcomes, but their value emerges in {{Term|Complex (glossary)|complex}} and less predictable ways across a system. The single lap performance of a vehicle around a track is related to center of gravity and speed; however, it is also affected by driver skill, external conditions, component ware, etc. Getting the 'best' performance from a vehicle can only be achieved by a combination of good design and feedback from real laps under race conditions.
  
−
# Functions that are directly deduced from functional and interface requirements. These functions express the expected services of a system necessary to meet its {{Term|System Requirement (glossary)|system requirements}}.
+
There are also outcomes which are less tangible and which come as a surprise to both system developers and {{Term|User (glossary)|users}}. How does lap time translate into a winning motor racing team? Why is a sports car more desirable to many than other vehicles with performances that are as good or better? 
−
# Functions that are derived and issued from the alternative solutions of {{Term|Physical Architecture (glossary)|physical architecture}} model and are dependent upon the result of the design; additionally, they rely upon on technology choice to implement the logical architecture model elements.
 
  
−
'''Functional Hierarchy/Decomposition of Functions''' - At the highest level of a hierarchy (Figure 1), it is possible to represent a system as a unique, central function (defined as the system's mission) that in many ways is similar to a "black box" ("F0" in plan A-0 in Figure 1). In order to understand, in detail, what the system does, this "head-of-hierarchy" (F0) is broken down into sub-functions (F1, F2, F3, F4) grouped to form a sub-level of the hierarchy (plan A0), and so on. Functions of the last level of a functional hierarchy can be called leaf-functions (F21, F22, F23, F24 in plan A2). Hierarchies (or breakdowns) decompose a complex or global function into a set of functions for which physical solutions are known, feasible, or possible to imagine.
+
Emergence can always be observed at the highest level of system. However, Hitchins (2007, 7) also points out that to the extent that the systems elements themselves can be considered as systems, they also exhibit emergence. Page (2009) refers to emergence as a “macro-level property.” Ryan (2007) contends that emergence is coupled to {{Term|Scope (glossary)|scope}} rather than system hierarchical levels. In Ryan’s terms, scope has to do with spatial dimensions (how system elements are related to each other) rather than hierarchical levels.
  
−
This view of functional hierarchy represents a static view of functions which would be populated at different levels over a number of iteration, depending upon the {{Term|Synthesis (glossary)|synthesis}} approach used.  In general, it is not created by a single top-down decomposition. A static functional hierarchy on its own does not represent how effectively the flows of inputs and outputs are exchanged, and may need to be viewed alongside the other models below.  
+
Abbott (2006) does not disagree with the general definition of emergence as discussed above. However, he takes issue with the notion that emergence operates outside the bounds of classical physics. He says that “such higher-level entities…can always be reduced to primitive physical forces.”
  
−
[[File:Decomposition_of_Functions_AF_071112(2).png|600px|thumb|center|'''Figure 1. Decomposition of Functions (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
+
Bedau and Humphreys (2008) and Francois (2004) provide comprehensive descriptions of the philosophical and scientific background of emergence.
  
−
===Behavioral Architecture Model===
+
==Types of Emergence==
  
−
A {{Term|Behavioral Architecture (glossary)|behavioral architecture}} model is an arrangement of functions and their sub-functions as well as interfaces (inputs and outputs) that defines the execution sequencing, conditions for control or data-flow, and performance level necessary to satisfy the system requirements ISO/IEC/IEEE 26702 (ISO 2007). A behavioral architecture model can be described as a set of inter-related scenarios of functions and/or {{Term|Operational Mode (glossary)|operational modes}}.
+
A variety of definitions of types of emergence exists. See Emmeche et al. (1997), Chroust (2003) and O’Connor and Wong (2006) for specific details of some of the variants. Page (2009) describes three types of emergence: "simple", "weak", and "strong".  
  
−
'''Control (Trigger)''' - A control flow is an element that activates a function as a condition of its execution. The state of this element, or the condition it represents, activates or deactivates the function (or elements thereof). A control flow can be a signal or an event, such as a switch being moved to the ''on'' position, an alarm, a trigger, a temperature variation, or the push of a key on a keyboard.
+
According to Page, '''simple emergence''' is generated by the combination of element properties and relationships and occurs in non-complex or “ordered”  systems (see [[Complexity]]) (2009). To achieve the emergent property of “controlled flight” we cannot consider only the wings, or the control system, or the propulsion system. All three must be considered, as well as the way these three are interconnected-with each other, as well as with all the other parts of the aircraft. Page suggests that simple emergence is the only type of emergence that can be predicted. This view of emergence is also referred to as {{Term|Synergy (glossary)|synergy}} (Hitchins 2009).
  
−
'''Scenario (of Functions)''' - A scenario of functions is a chain of functions that are performed as a sequence and synchronized by a set of control flows to work to achieve a global transformation of inputs into outputs, as seen in the figures below. A scenario of functions expresses the dynamic of an upper level function. A behavioral architecture is developed by considering both scenarios for each level of the functional hierarchy and for each level of the system hierarchy. When representing scenarios of functions and behavioral architecture models, it is appropriate to use diagrams as modeling techniques, such as functional flow block diagrams (FFBD) (Oliver, Kelliher, and Keegan 1997) or activity diagrams, developed with SysML (OMG 2010). Figures 2 and 3 provide examples of these diagrams.
+
Page describes '''weak emergence''' as expected emergence which is desired (or at least allowed for) in the system {{Term|Structure (glossary)|structure}} (2009). However, since weak emergence is a product of a complex system, the actual level of emergence cannot be predicted just from knowledge of the characteristics of the individual system {{Term|Component (glossary)|components}}.
  
−
[[File:Illustration_of_a_scenario_(eFFBD)_AF_071112.png|thumb|900px|center|'''Figure 2. Illustration of a Scenario (eFFBD).''' (SEBoK Original)]]
+
The term '''strong emergence''' is used to describe unexpected emergence; that is, emergence not observed until the system is simulated or tested or, more alarmingly, until the system encounters in operation a situation that was not anticipated during design and development.
  
−
[[File:Illustration_of_a_scenario_Activity_Diagram_AF_071112.png|thumb|900px|center|'''Figure 3. Illustration of a Scenario (Activity Diagram).''' (SEBoK Original)]]
+
Strong emergence may be evident in failures or shutdowns. For example, the US-Canada Blackout of 2003 as described by the US-Canada Power System Outage Task Force (US-Canada Power Task Force 2004) was a case of cascading shutdown that resulted from the {{Term|Design (glossary)|design}} of the system. Even though there was no equipment failure, the shutdown was systemic. As Hitchins points out, this example shows that emergent properties are not always beneficial (Hitchins 2007, 15).
  
−
'''Operational Mode''' - A scenario of functions can be viewed by abstracting the transformation of inputs into outputs of each function and focusing on the active or non-active state of the function and its controls. This view is called a ''scenario of modes'', which is a chain of modes performed as a sequence of transitions between the various modes of the system. The transition from one mode to another is triggered by the arrival of a control flow (event/trigger). An action (function) can be generated within a transition between two modes following the arrival of an event or a trigger, as demonstrated in Figure 4 below.
+
Other authors make a different distinction between the ideas of strong, or unexpected, emergence and unpredictable emergence: 
  
−
[[File:SEBoKv075_KA-SystDef_Scenario_of_Operational_Modes.png|300px|thumb|center|'''Figure 4. Scenario of Operational Modes (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
+
*Firstly, there are the unexpected properties that could have been predicted but were not considered in a systems development: "Properties which are unexpected by the observer because of his incomplete data set, with regard to the phenomenon at hand" (Francois, C. 2004, 737).  According to Jackson et al. (2010), a desired level of emergence is usually achieved by iteration. This may occur as a result of evolutionary {{Term|Process (glossary)|processes}}, in which element properties and combinations are "selected for", depending on how well they contribute to a system’s effectiveness against {{Term|Environment (glossary)|environmental}} pressures or by iteration of design parameters through {{Term|Simulation (glossary)|simulation}} or build/test cycles. Taking this view, the specific values of weak emergence can be refined, and examples of strong emergence can be considered in subsequent iterations so long as they are amenable to analysis.  
  
−
'''Behavioral Patterns''' - When defining scenarios or behavioral architecture models, architects may opt to recognize and use known models to represent the expected transformations and behaviors. Patterns are generic basic models that may be more or less sophisticated depending on the complexity of the treatment. (Gamma, Helm, Johnson, and Vlissides 1995) A {{Term|Pattern (glossary)|pattern}} can be represented with different notations. Behavioral patterns are classified into several categories, which can be seen in the following examples (see also SEBoK Part 2: [[Patterns of Systems Thinking]]):
+
*Secondly, there are unexpected properties which cannot be predicted from the properties of the system’s components: "Properties which are, in and of themselves, not derivable a priori from the behavior of the parts of the system" (Francois, C. 2004, 737).  This view of emergence is a familiar one in social or natural sciences, but more controversial in {{Term|Engineering (glossary)|engineering}}.  We should distinguish between a theoretical and a practical unpredictability (Chroust 2002). The weather forecast is theoretically predictable, but beyond certain limited accuracy practically impossible due to its {{Term|Chaos (glossary)|chaotic}} nature. The emergence of consciousness in human beings cannot be deduced from the physiological properties of the brain. For many, this genuinely unpredictable type of complexity has limited value for engineering. (See '''Practical Considerations''' below.)
−
* Basic patterns or constructs linking functions - such as sequence, iteration, selection, concurrence, multiple exits, loops with an exit, and replication.
 
−
* Complex patterns - such as monitoring a treatment, exchanging a message, man machine interfaces, modes monitoring, real-time monitoring of processes, queue management, and continuous monitoring with supervision.
 
−
* Failure detection, identification, and recovery (FDIR) patterns - such as passive redundancies, active redundancies, semi-active redundancies, and treatments with reduced performance.
 
  
−
===Temporal Architecture Model===
+
A type of system particularly subject to strong emergence is the {{Term|System of Systems (SoS) (glossary)}}. The reason for this is that the SoS, by definition, is composed of different systems that were designed to operate independently. When these systems are operated together, the interaction among the parts of the system is likely to result in unexpected emergence. Chaotic or truly unpredictable emergence is likely for this class of systems.
−
 
−
A {{Term|Temporal Architecture (glossary)|temporal architecture}} model is a classification of the functions of a system that is derived according to the frequency level of execution. Temporal architecture models include the definition of synchronous and asynchronous aspects of functions. The decision monitoring that occurs inside a system follows the same temporal classification because the decisions are related to the monitoring of functions.
 
  
−
'''Temporal and Decisional Hierarchy Concept''' - Not every function of a system is performed at the same frequency. The frequencies change depending on the time and the manner in which the functions are started and executed. One must therefore consider several classes of performance. There are synchronous functions that are executed cyclically and asynchronous functions that are executed following the occurrence of an event or trigger.
+
==Emergent Properties==
  
−
To be more specific, ''real-time'' systems and ''command-control'' systems combine cyclical operations (synchronous) and factual aspects (asynchronous). Cyclical operations consist of sharing the execution of functions according to frequencies, which depend on either the constraints of capture or dispatching the input/output and control flows. Two types of asynchronous events can be distinguished:
+
{{Term|Emergent Property (glossary)|Emergent properties}} can be defined as follows: “A property of a complex system is said to be ‘emergent’ [in the case when], although it arises out of the properties and relations characterizing its simpler constituents, it is neither predictable from, nor reducible to, these lower-level characteristics” (Honderich 1995, 224).  
  
−
# Disturbances on High Frequencies (bottom of figure 5) - Decisions that are made at either the level they occur or one level above. The goal is to deter disturbances from affecting the low frequencies so that the system continues to achieve its mission objectives. This is the way to introduce exception operations, with the typical example relating to operations concerns, breakdowns, or {{Term|Failure (glossary)|failures}}.
+
All systems can have emergent properties which may or may not be predictable or amenable to {{Term|Model (glossary)|modeling}}, as discussed above. Much of the literature on {{Term|Complexity (glossary)|complexity}} includes emergence as a defining characteristic of complex systems. For example, Boccara (2004) states that “The appearance of emergent properties is the single most distinguishing feature of complex systems.”  In general, the more ordered a system is, the easier its emergent properties are to predict. The more complex a system is, the more difficult predicting its emergent properties becomes.
−
# Changes on Low Frequencies (top of figure 5) - Decisions pertaining to changes that are made at the upper levels. The ultimate goal is to transmit them toward bottom levels to implement the modifications. A typical example relates to operator actions, maintenance operations, etc.
 
  
−
[[File:SEBoKv05 KA-SystDef Temporal and decision hierarchy levels.png|450px|thumb|center|'''Figure 5. Temporal and Decision Hierarchy Levels (Faisandier 2012).''' Permission granted by Sinergy'Com. All other rights are reserved by the copyright owner.]]
+
Some practitioners use the term “emergence” only when referring to “strong emergence”. These practitioners refer to the other two forms of emergent behavior as synergy or “system level behavior” (Chroust 2002). Taking this view, we would reserve the term "Emergent Property" for unexpected properties, which can be modeled or refined through iterations of the systems development.
  
−
==Process Approach==
+
Unforeseen emergence causes nasty shocks. Many believe that the main job of the {{Term|Systems Approach (glossary)|systems approach}} is to prevent undesired emergence in order to minimize the {{Term|Risk (glossary)|risk}} of unexpected and potentially undesirable outcomes. This review of emergent properties is often specifically associated with identifying and avoiding system failures (Hitchins 2007).
  
−
===Purpose===
+
Good SE isn't just focused on avoiding system failure, however. It also involves maximizing {{Term|Opportunity (glossary)|opportunity}} by understanding and exploiting emergence in {{Term|Engineered System (glossary)|engineered systems}} to create the required system level characteristics from synergistic interactions between the {{Term|Component (glossary)|components}}, not just from the components themselves (Sillitto 2010).
−
The purpose of the Logical Architecture Model Development is to define, select, and synthesize a system’s logical architecture model to provide a framework against which to verify that a future system will satisfy its system requirements in all operational scenarios, within which trade-offs between system requirements can be explored in developing such systems.
 
  
−
Generic inputs to the process include system requirements, generic architecture patterns that architects identify and use to answer requirements, outcomes from [[System Analysis|system analysis]] processes, and feedback from system [[System Verification|verification]] and [[System Validation|validation]] processes. Depending on the Life Cycle Model that is chosen, there will be iterations through which these inputs and outputs, and the relationships between them evolve and change throughout the process (see also [[Applying Life Cycle Processes]]).  
+
One important group of emergent properties includes properties such as {{Term|Agility (glossary)|agility}} and {{Term|Resilience (glossary)|resilience}}. These are critical system properties that are not meaningful except at the whole system level.
  
−
Generic outputs from the process are either a single logical architecture model or a set of candidate logical architecture models together with the selected independent logical architecture model and a rationale for its selection. They include, at minimum, views and models. These involve functional, behavioral and temporal views; a traceability matrix between logical architecture model elements and system requirements.
+
==Practical Considerations==
 +
 
 +
As mentioned above, one way to manage emergent properties is through iteration.  The requirements to iterate the design of an engineered system to achieve desired emergence results in a {{Term|Design (glossary)|design}} {{Term|Process (glossary)|process}} are lengthier than those needed to design an ordered system.  Creating an engineered system capable of such iteration may also require a more configurable or modular solution.  The result is that complex systems may be more costly and time-consuming to develop than ordered ones, and the cost and time to develop is inherently less predictable.
 +
 
 +
Sillitto (2010) observes that “engineering design domains that exploit emergence have good mathematical models of the domain, and rigorously control variability of components and subsystems, and of process, in both design and operation.” The iterations discussed above can be accelerated by using simulation and modeling, so that not all the iterations need to involve building real systems and operating them in the real environment.
  
−
===Activities of the Process===
+
The idea of domain models is explored further by Hybertson in the context of general models or {{Term|Pattern (glossary)|patterns}} learned over time and captured in a model space (Hybertson 2009). Hybertson states that knowing what emergence will appear from a given design, including side effects, requires hindsight. For a new type of problem that has not been solved, or a new type of system that has not been built, it is virtually impossible to predict emergent behavior of the solution or system. Some hindsight, or at least some insight, can be obtained by modeling and iterating a specific system design; however, iterating the design within the development of one system yields only limited hindsight and often does not give a full sense of emergence and side effects.
−
Major activities and tasks performed during this process include the following:
 
  
−
* Identify and analyze functional and behavioral elements:
+
True hindsight and understanding comes from building multiple systems of the same type and deploying them, then observing their emergent behavior in operation and the side effects of placing them in their environments. If those observations are done systematically, and the emergence and side effects are distilled and captured in relation to the design of the systems — including the variations in those designs — and made available to the community, then we are in a position to predict and exploit the emergence.  
−
** Identify functions, {{Term|Input-Output Flow (glossary)|input-output flows}}, {{Term|Operational Mode (glossary)|operational modes}}, {{Term|Transition of Modes (glossary)|transition of modes}}, and {{Term|Operational Scenario (glossary)|operational scenarios}} from system requirements by analyzing the functional, interface, and operational requirements.
 
−
** Define necessary inputs and controls (energy, material, and data flows) to each function and outputs that result in the deduction of the necessary functions to use, transform, move, and generate the input-output flows.
 
−
* Assign system requirements to functional and behavioral elements:
 
−
** Formally characterize functions expressions and their attributes through the assignment of performance, effectiveness, and constraints requirements. In particular, study the temporal aspects from requirements to assign duration, response time, and frequency to functions.
 
−
** Formally characterize the input, output, and control flows expressions and their attributes through assignment of interface, effectiveness, operational, temporal and constraints requirements.
 
−
** Establish traceability between system requirements and these functional and behavioral elements.
 
−
* Define candidate logical architecture models For each candidate:
 
−
** Analyze operational modes as stated in the system requirements (if any) and/or use previously defined elements to model sequences of operational modes and the transition of modes. Eventually decompose the modes into sub-modes and then establish for each operational mode one or several scenarios of functions recognizing and/or using relevant generic behavioral patterns.
 
−
** Integrate these scenarios of functions in order to get a behavioral architecture model of the system (a complete picture of the dynamic behavior).
 
−
** Decompose previously defined logical elements as necessary to look towards implementation.
 
−
** Assign and incorporate temporal constraints to previously defined logical elements, such as the period of time, duration, frequency, response-time, timeout, stop conditions, etc.
 
−
** Define several levels of execution frequency for functions that correspond to levels of decision, in order to monitor system operations, prioritize processing on this time basis, and share out functions among those execution frequency levels to get a temporal architecture model.
 
−
** Perform functional failure modes and effects analysis and update the logical architecture elements as necessary.
 
−
** Execute the models with simulators (when possible) and tune these models to obtain the expected characteristics.
 
−
* Synthesize the selected independent logical architecture model:
 
−
** Select the logical architecture by assessing the candidate logical architecture models against assessment criteria (related to system requirements) and compare them, using the system analysis process to perform assessments and decision management process for the selection (see the [[System Analysis]] and [[Decision Management]] topics). This selected logical architecture model is called ''independent logical architecture model'' because, as much as possible, it is independent of implementation decisions.
 
−
** Identify and define derived logical architecture model elements created for the necessity of design and corresponding with the derived system requirements. Assign these requirements to the appropriate system (current studied system or external systems).
 
−
** Verify and validate the selected logical architecture models (using as executable models as possible), make corrections as necessary, and establish traceability between system requirements and logical architecture model elements.
 
−
* Feedback logical architecture model development and system requirements. This activity is performed after the physical architecture model development process:
 
−
** Model the ''allocated logical architecture'' to systems and system elements, if such a representation is possible, and add any functional, behavioral, and temporal elements as needed to synchronize functions and treatments.
 
−
** Define or consolidate derived logical and physical elements induced by the selected logical and physical architecture models. Define the corresponding derived requirements and allocate them to appropriate logical and physical architectures elements. Incorporate these derived requirements into the requirements baselines of impacted systems.
 
  
−
===Artifacts, Methods and Modeling Techniques===
+
Two factors are discovered in this type of testing environment: what works (that is, what emergent behavior and side effects are desirable); and what does not work (that is, what emergent behavior and side effects are undesirable). What works affirms the design. What does not work calls for corrections in the design. This is why multiple systems, especially complex systems, must be built and deployed over time and in different environments - to learn and understand the relations among the design, emergent behavior, side effects, and environment. 
−
Logical architecture descriptions use modeling techniques that are grouped under the following types of models. Several methods have been developed to support these types of models (some are executable models):
 
  
−
* Functional Models – These include models such as the structured analysis design technique (SADT/IDEF0), system analysis & real time (SA-RT), enhanced Functional Flow Block Diagrams (eFFBD), and the function analysis system technique (FAST).
+
These two types of captured learning correspond respectively to patterns and “{{Term|Antipattern (glossary)|antipatterns}},” or patterns of failure, both of which are discussed in a broader context in the [[Principles of Systems Thinking]]  and [[Patterns of Systems Thinking]] topics.
−
* Semantic Models- These include models such as entities-relationships diagrams, class diagrams, and data flow diagrams.
 
−
* Dynamic Models – These include such models as state-transition diagrams, state-charts, eFFBDs, state machine diagrams (SysML), activity diagrams (SysML) (OMG. 2010), and petri nets.
 
  
−
Depending on the type of domain (e.g. defense, enterprise), {{Term|Architecture Framework (glossary)|architecture frameworks}}  provide descriptions that can help to represent additional aspects/views of architectures - see the section 'Enterprise Architecture Frameworks & Methodologies' in [[Enterprise Systems Engineering Key Concepts]]. See also practical means for using general templates related to ISO/IEC/IEEE 42010 (ISO 2011).
+
The use of iterations to refine the values of emergent properties, either across the life of a single system or through the development of patterns encapsulating knowledge gained from multiple developments, applies most easily to the discussion of strong emergence above. In this sense, those properties which can be observed but cannot be related to design choices are not relevant to a systems approach. However, they can have value when dealing with a combination of engineering and managed problems which occur for system of systems contexts (Sillitto 2010). (See [[Systems Approach Applied to Engineered Systems]].)
  
−
==Practical Considerations==
+
==References==  
−
As stated above, the purpose of the logical architecture model is to provide a description of what a system must be able to do to satisfy the stated need. This should help to ensure that the needs and/or concerns of all stakeholders are addressed by any solution, and that innovative solutions, as well as those based on current solution technologies, can be considered.  In practice it is human nature for problem stakeholders to push their own agendas and for solution architects or designers to offer their familiar solutions. If a logical architecture model is not properly enforced with the chosen life cycle, it is easy for both problem and solution stakeholders to ignore it and revert to their own biases (see Part 5 [[Enabling Systems Engineering]]).  This is exacerbated if the logical architecture model becomes an end in its own right or disconnected from the main lifecycle activities.  This can occur either through the use of abstract language or notations, levels of detail, time taken, or an overly complex final architecture that does not match the purpose for which it was created.  If the language, scope, and timeliness of the architecture are not matched to the problem stakeholder or solution providers, it is easier for them to overlook it. Key pitfalls and good practices which can help to avoid problems related to logical architecture model are described in the next two sections.
+
===Works Cited===
 +
Abbott, R. 2006. "Emergence explained: Getting epiphenomena to do real work". ''Complexity,'' vol. 12, no. 1 (September-October), pp. 13-26.  
  
−
===Pitfalls===
+
Bedau, M.A. and P. Humphreys, P. (eds.). 2008. "Emergence" In ''Contemporary Readings in Philosophy and Science''. Cambridge, MA, USA: The MIT Press.  
−
Some of the key pitfalls encountered in developing logical architecture are provided in Table 1.
 
  
−
<center>
+
Boccara, N. 2004. ''Modeling Complex Systems.'' New York, NY, USA: Springer-Verlag.
−
{|
 
−
|+'''Table 1. Pitfalls with Logical Architecture Development.''' (SEBoK Original)
 
−
!Pitfall
 
−
!Description
 
−
|-
 
−
|'''Problem Relevance'''
 
−
|The logical architecture model should relate back to the operational scenarios produced by {{Term|Mission Analysis (glossary)|mission analysis}}.
 
−
|-
 
−
|'''Inputs for Architecture Model'''
 
−
|The major input for architecture definition activity involves the set of system requirements and the instances in which they do not address the right level of architecture. The consequence is that the architect allows the requirements to fall to the side and invents a solution with what he or she understands through the input.
 
−
|-
 
−
|'''Decomposition Too Deep'''
 
−
| A common mistake made by many beginners in architecture consists of decomposing the functions too deeply or having too many functions and input/output flows in scenarios or in the functional architecture model of the current system block.
 
−
|-
 
−
|'''Not Considering Inputs and Outputs Together with Functions'''
 
−
|A common mistake is to consider only the actions supported by functions and decomposing them, while forgetting the inputs and the outputs or considering them too late. Inputs and outputs are integral parts of a function.
 
−
|-
 
−
|'''Considering Static Decomposition of Functions Only'''
 
−
|Static function decomposition is the smallest functional architecture model task and answers the basic question, "How is this done?" The purpose of the static decomposition is to facilitate the management or navigation through the list of functions. The static decomposition should be established only when scenarios have been created and the logical architecture is close to complete.
 
−
|-
 
−
|'''Mixing Governance, Management, and Operation'''
 
−
|Governance (strategic monitoring), management (tactical monitoring), and basic operations are often mixed in complex systems. Logical architecture model should deal with behavioral architecture model as well as with temporal architecture model.
 
−
|}
 
−
</center>
 
  
−
===Proven Practices===
+
Checkland, P. 1999. ''Systems Thinking, Systems Practice.'' New York, NY, USA: John Wiley & Sons.  
−
Some proven practices gathered from the references are provided in Table 2.
 
  
−
<center>
+
Chroust. G. 2002. "Emergent properties in software systems." 10th Interdisciplinary Information Management Talks; Hofer, C. and Chroust, G. (eds.). Verlag Trauner Linz, pp. 277-289.
−
{|
 
−
|+'''Table 2. Proven Practices with Logical Architecture Development.''' (SEBoK Original)
 
−
!Practice
 
−
!Description
 
−
|-
 
−
|'''Constitute Scenarios of Functions'''
 
−
|Before constituting a decomposition tree of functions, one must model the behavior of the system, establish scenarios of functions, and decompose functions as scenarios of sub-functions.
 
−
|-
 
−
|'''Analysis and Synthesis Cycles'''
 
−
|When facing a system that contains a large number of functions, one should attempt to synthesize functions into higher abstraction levels of functions with the assistance of criteria. Do not perform analysis only; instead, conduct small cycles of analysis (decomposition) and synthesis. The technique of using scenarios includes this design practice.
 
−
|-
 
−
|'''Alternate Functional and Behavioral Views'''
 
−
|A function (action verb; e.g. "to move") and its state of execution/operational mode (e.g. "moving") are two similar and complimentary views. Utilize this to consider a behavioral view of the system that allows for the transition from one operational mode to another.
 
−
|-
 
−
|''' The Order to Create a Scenario Of Functions'''
 
−
|When creating a scenario of functions, it is more efficient to first establish the (control) flow of functions, then to add input and output flows, and finally to add triggers or signals for synchronization.
 
−
|}
 
−
</center>
 
  
−
==References==
+
Chroust, G., C. Hofer, C. Hoyer (eds.). 2005. ''The concept of emergence in systems engineering." The 12th Fuschl Conversation, April 18-23, 2004, Institute for Systems Engineering and Automation, Johannes Kepler University Linz. pp. 49-60.
  
−
===Works Cited===
+
Emmeche, C., S. Koppe, and F. Stjernfelt. 1997. "Explaining emergence: Towards an ontology of levels." ''Journal for General Philosophy of Science,'' vol. 28, no. 1, pp. 83-119.  Accessed 3 December 2014.  Available at:http://www.nbi.dk/~emmeche/coPubl/97e.EKS/emerg.html.  
−
Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. ''Design Patterns: Elements of Reusable Object-Oriented Software''. Boston, MA, USA: Addison-Wesley.
 
  
−
Faisandier, A. 2012. ''Systems Architecture and Design''. Belberaud, France: Sinergy'Com.  
+
Francois, C. 2004. ''International Encyclopedia of Systems and Cybernetics'', 2nd edition, 2 volumes. Munich, Germany: K.G.Saur Verlag.
  
−
ISO/IEC. 2007.''Systems Engineering – Application and Management of the Systems Engineering Process.''Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.  
+
Hitchins, D. 2007. ''Systems Engineering: A 21st Century Systems Methodology''. Hoboken, NJ, USA: John Wiley & Sons.  
  
−
ISO/IEC/IEEE. 2011. ''Systems and software engineering - Architecture description.'' Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), ISO/IEC/IEEE 42010.  
+
Honderich. T. 1995. ''The Oxford Companion to Philosophy''. New York, NY, USA: Oxford University Press.
  
−
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering complex systems with models and objects''. New York, NY, USA: McGraw-Hill.  
+
Hybertson, D. 2009. ''Model-Oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems''. Boca Raton, FL, USA: Auerbach/CRC Press.
  
−
OMG. 2010. ''OMG Systems Modeling Language specification'', version 1.2, July 2010. http://www.omg.org/technology/documents/spec_catalog.htm.
+
Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE ''Insight.'' 13(1) (April 2010): 41-43.  
  
−
===Primary References===
+
O’Connor, T. and H. Wong. 2006. "Emergent Properties," in  ''Stanford Encyclopedia of Philosophy''. Accessed December 3 2014:  Available at: http://plato.stanford.edu/entries/properties-emergent/.  
−
ANSI/IEEE. 2000. ''[[IEEE 1471|Recommended practice for architectural description for software-intensive systems]]''. New York, NY: American National Standards Institute (ANSI)/Institute of Electrical and Electronics Engineers (IEEE), ANSI/[[IEEE 1471]]-2000.
 
  
−
INCOSE. 2015. ''[[INCOSE Systems Engineering Handbook|Systems Engineering Handbook]] - ''A Guide for System Life Cycle Processes and Activities<nowiki>''</nowiki>, version 4.0. Hoboken, NJ, USA: John Wiley and Sons, Inc, ISBN: 978-1-118-99940-0
+
Page, S.E. 2009. ''Understanding Complexity.'' The Great Courses. Chantilly, VA, USA: The Teaching Company.
  
−
ISO/IEC. 2007. ''Systems Engineering – Application and Management of the Systems Engineering Process.'' Geneva, Switzerland: International Organization for Standards (ISO)/International Electronical Commission (IEC), ISO/IEC 26702:2007.
+
Ryan, A. 2007. "Emergence is coupled to scope, not level." ''Complexity,'' vol. 13, no. 2, November-December.  
  
−
ISO/IEC/IEEE. 2015. ''[[ISO/IEC/IEEE 15288|Systems and Software Engineering -- System Life Cycle Processes]]''. Geneva, Switzerland: International Organisation for Standardisation / International Electrotechnical Commissions / Institute of Electrical and Electronics Engineers. ISO/IEC/IEEE 15288:2015.
+
Sillitto, H.G. 2010. "Design principles for ultra-large-scale systems". Proceedings of the 20th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 2010, Chicago, IL, USA, reprinted in “The Singapore Engineer,” April 2011.
  
−
ISO/IEC/IEEE. 2011. ''[[ISO/IEC/IEEE 42010|Systems and Software Engineering - Architecture Description]]''. Geneva, Switzerland: International Organization for Standardization (ISO)/International Electrotechnical Commission (IEC)/Institute of Electrical and Electronics Engineers (IEEE), [[ISO/IEC/IEEE 42010]].
+
US-Canada Power System Outage Task Force. 2004. ''Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations''. Washington-Ottawa. Accessed 3 December 3, 2014. Available: http://energy.gov/oe/downloads/blackout-2003-final-report-august-14-2003-blackout-united-states-and-canada-causes-and
  
−
Maier, M. and E. Rechtin. 2009. ''[[The Art of Systems Architecting]],'' 3rd ed. Boca Raton, FL, USA: CRC Press.
+
===Primary References===
  
−
===Additional References===
+
Emmeche, C., S. Koppe, and F. Stjernfelt. 1997. "[[Explaining Emergence|Explaining emergence]]: Towards an ontology of levels." ''Journal for General Philosophy of Science,'' vol. 28, no. 1, pp. 83-119. Available: http://www.nbi.dk/~emmeche/coPubl/97e.EKS/emerg.html.  
−
Alexander, C., S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, and S. Angel. 1977. ''A Pattern Language: Towns, Buildings, Construction''. New York, NY, USA: Oxford University Press.
 
  
−
Buede, D.M. 2009. ''The engineering design of systems: Models and methods''. 2nd ed. Hoboken, NJ, USA: John Wiley & Sons Inc.  
+
Hitchins, D. 2007. ''[[Systems Engineering: A 21st Century Systems Methodology]]''. Hoboken, NJ, USA: John Wiley & Sons.
  
−
Oliver, D., T. Kelliher, and J. Keegan. 1997. ''Engineering Complex Systems with Models and Objects''. New York, NY, USA: McGraw-Hill.
+
Page, S. E. 2009. ''[[Understanding Complexity]]''. The Great Courses. Chantilly, VA, USA: The Teaching Company.
  
−
The Open Group.
+
===Additional References===
−
2011. ''TOGAF'', version 9.1. Hogeweg, The Netherlands: Van Haren
 
−
Publishing. Accessed August 29, 2012. Available at: https://www2.opengroup.org/ogsys/jsp/publications/PublicationDetails.jsp?catalogno=g116.
 
  
−
Zachman, J. 2008.
+
Sheard, S.A. and A. Mostashari. 2008. "Principles of complex systems for systems engineering." ''Systems Engineering,'' vol. 12, no. 4, pp. 295-311.
−
"John Zachman's Concise Definition of The Zachman Framework™."
 
−
Zachman International Enterprise Architecture. Accessed August 29, 2012. Available at: http://www.zachman.com/about-the-zachman-framework.
 
  
 
----
 
----
−
 
+
<center>[[Complexity|< Previous Article]] | [[Systems Fundamentals|Parent Article]] | [[Fundamentals for Future Systems Engineering|Next Article >]]</center>
−
<center>[[System Architecture|< Previous Article]] | [[System Definition|Parent Article]] | [[Physical Architecture Model Development|Next Article >]]</center>
 
  
 
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
 
<center>'''SEBoK v. 2.1, released 31 October 2019'''</center>
  
−
[[Category: Part 3]][[Category:Topic]]
+
[[Category:Part 2]][[Category:Topic]][[Category:Systems Fundamentals]]
−
[[Category:System Definition]]
 

Revision as of 20:01, 28 February 2020

Lead Author: Rick Adcock, Contributing Authors: Scott Jackson, Dick Fairley, Janet Singer, Duane Hybertson

This topic forms part of the Systems Fundamentals knowledge area (KA). It gives the background to some of the ways in which emergenceemergence has been described, as well as an indication of current thinking on what it is and how it influences systems engineeringsystems engineering (SE) practice. It will discuss how these ideas relate to the general definitions of systemssystems given in What is a System?; in particular, how they relate to different engineered systemengineered system contexts. This topic is closely related to the complexity topic that precedes it.

Emergence is a consequence of the fundamental system conceptsconcepts of holismholism and interaction (Hitchins 2007, 27). System wholes have behaviorsbehaviors and properties arising from the organization of their elementselements and their relationships, which only become apparent when the system is placed in different environmentsenvironments.

Questions that arise from this definition include: What kinds of systems exhibit different kinds of emergence and under what conditions? Can emergence be predicted, and is it beneficial or detrimental to a system? How do we deal with emergence in the development and use of engineered systems? Can it be planned for? How?

There are many varied and occasionally conflicting views on emergence. This topic presents the prevailing views and provides references for others.

Overview of Emergence

As defined by Checkland, emergenceemergence is “the principle that entities exhibit properties which are meaningful only when attributed to the whole, not to its parts.” (Checkland 1999, 314). Emergent system behaviorbehavior can be viewed as a consequence of the interactions and relationships between system elementssystem elements rather than the behavior of individual elements. It emerges from a combination of the behavior and properties of the system elements and the systems structure or allowable interactions between the elements, and may be triggered or influenced by a stimulus from the systems environment.

Emergence is common in nature. The pungent gas ammonia results from the chemical combination of two odorless gases, hydrogen and nitrogen. As individual parts, feathers, beaks, wings, and gullets do not have the ability to overcome gravity; however, when properly connected in a bird, they create the emergent behavior of flight. What we refer to as “self-awareness” results from the combined effect of the interconnected and interacting neurons that make up the brain (Hitchins 2007, 7).

Hitchins also notes that technological systems exhibit emergence. We can observe a number of levels of outcome which arise from interaction between elements in an engineered systemengineered system context. At a simple level, some system outcomes or attributesattributes have a fairly simple and well defined mapping to their elementselements; for example, center of gravity or top speed of a vehicle result from a combination of element properties and how they are combined. Other behaviors can be associated with these simple outcomes, but their value emerges in complexcomplex and less predictable ways across a system. The single lap performance of a vehicle around a track is related to center of gravity and speed; however, it is also affected by driver skill, external conditions, component ware, etc. Getting the 'best' performance from a vehicle can only be achieved by a combination of good design and feedback from real laps under race conditions.

There are also outcomes which are less tangible and which come as a surprise to both system developers and usersusers. How does lap time translate into a winning motor racing team? Why is a sports car more desirable to many than other vehicles with performances that are as good or better?

Emergence can always be observed at the highest level of system. However, Hitchins (2007, 7) also points out that to the extent that the systems elements themselves can be considered as systems, they also exhibit emergence. Page (2009) refers to emergence as a “macro-level property.” Ryan (2007) contends that emergence is coupled to scopescope rather than system hierarchical levels. In Ryan’s terms, scope has to do with spatial dimensions (how system elements are related to each other) rather than hierarchical levels.

Abbott (2006) does not disagree with the general definition of emergence as discussed above. However, he takes issue with the notion that emergence operates outside the bounds of classical physics. He says that “such higher-level entities…can always be reduced to primitive physical forces.”

Bedau and Humphreys (2008) and Francois (2004) provide comprehensive descriptions of the philosophical and scientific background of emergence.

Types of Emergence

A variety of definitions of types of emergence exists. See Emmeche et al. (1997), Chroust (2003) and O’Connor and Wong (2006) for specific details of some of the variants. Page (2009) describes three types of emergence: "simple", "weak", and "strong".

According to Page, simple emergence is generated by the combination of element properties and relationships and occurs in non-complex or “ordered” systems (see Complexity) (2009). To achieve the emergent property of “controlled flight” we cannot consider only the wings, or the control system, or the propulsion system. All three must be considered, as well as the way these three are interconnected-with each other, as well as with all the other parts of the aircraft. Page suggests that simple emergence is the only type of emergence that can be predicted. This view of emergence is also referred to as synergysynergy (Hitchins 2009).

Page describes weak emergence as expected emergence which is desired (or at least allowed for) in the system structurestructure (2009). However, since weak emergence is a product of a complex system, the actual level of emergence cannot be predicted just from knowledge of the characteristics of the individual system componentscomponents.

The term strong emergence is used to describe unexpected emergence; that is, emergence not observed until the system is simulated or tested or, more alarmingly, until the system encounters in operation a situation that was not anticipated during design and development.

Strong emergence may be evident in failures or shutdowns. For example, the US-Canada Blackout of 2003 as described by the US-Canada Power System Outage Task Force (US-Canada Power Task Force 2004) was a case of cascading shutdown that resulted from the designdesign of the system. Even though there was no equipment failure, the shutdown was systemic. As Hitchins points out, this example shows that emergent properties are not always beneficial (Hitchins 2007, 15).

Other authors make a different distinction between the ideas of strong, or unexpected, emergence and unpredictable emergence:

  • Firstly, there are the unexpected properties that could have been predicted but were not considered in a systems development: "Properties which are unexpected by the observer because of his incomplete data set, with regard to the phenomenon at hand" (Francois, C. 2004, 737). According to Jackson et al. (2010), a desired level of emergence is usually achieved by iteration. This may occur as a result of evolutionary processesprocesses, in which element properties and combinations are "selected for", depending on how well they contribute to a system’s effectiveness against environmentalenvironmental pressures or by iteration of design parameters through simulationsimulation or build/test cycles. Taking this view, the specific values of weak emergence can be refined, and examples of strong emergence can be considered in subsequent iterations so long as they are amenable to analysis.
  • Secondly, there are unexpected properties which cannot be predicted from the properties of the system’s components: "Properties which are, in and of themselves, not derivable a priori from the behavior of the parts of the system" (Francois, C. 2004, 737). This view of emergence is a familiar one in social or natural sciences, but more controversial in engineeringengineering. We should distinguish between a theoretical and a practical unpredictability (Chroust 2002). The weather forecast is theoretically predictable, but beyond certain limited accuracy practically impossible due to its chaoticchaotic nature. The emergence of consciousness in human beings cannot be deduced from the physiological properties of the brain. For many, this genuinely unpredictable type of complexity has limited value for engineering. (See Practical Considerations below.)

A type of system particularly subject to strong emergence is the system of systems (sos)system of systems (sos). The reason for this is that the SoS, by definition, is composed of different systems that were designed to operate independently. When these systems are operated together, the interaction among the parts of the system is likely to result in unexpected emergence. Chaotic or truly unpredictable emergence is likely for this class of systems.

Emergent Properties

Emergent propertiesEmergent properties can be defined as follows: “A property of a complex system is said to be ‘emergent’ [in the case when], although it arises out of the properties and relations characterizing its simpler constituents, it is neither predictable from, nor reducible to, these lower-level characteristics” (Honderich 1995, 224).

All systems can have emergent properties which may or may not be predictable or amenable to modelingmodeling, as discussed above. Much of the literature on complexitycomplexity includes emergence as a defining characteristic of complex systems. For example, Boccara (2004) states that “The appearance of emergent properties is the single most distinguishing feature of complex systems.” In general, the more ordered a system is, the easier its emergent properties are to predict. The more complex a system is, the more difficult predicting its emergent properties becomes.

Some practitioners use the term “emergence” only when referring to “strong emergence”. These practitioners refer to the other two forms of emergent behavior as synergy or “system level behavior” (Chroust 2002). Taking this view, we would reserve the term "Emergent Property" for unexpected properties, which can be modeled or refined through iterations of the systems development.

Unforeseen emergence causes nasty shocks. Many believe that the main job of the systems approachsystems approach is to prevent undesired emergence in order to minimize the riskrisk of unexpected and potentially undesirable outcomes. This review of emergent properties is often specifically associated with identifying and avoiding system failures (Hitchins 2007).

Good SE isn't just focused on avoiding system failure, however. It also involves maximizing opportunityopportunity by understanding and exploiting emergence in engineered systemsengineered systems to create the required system level characteristics from synergistic interactions between the componentscomponents, not just from the components themselves (Sillitto 2010).

One important group of emergent properties includes properties such as agilityagility and resilienceresilience. These are critical system properties that are not meaningful except at the whole system level.

Practical Considerations

As mentioned above, one way to manage emergent properties is through iteration. The requirements to iterate the design of an engineered system to achieve desired emergence results in a designdesign processprocess are lengthier than those needed to design an ordered system. Creating an engineered system capable of such iteration may also require a more configurable or modular solution. The result is that complex systems may be more costly and time-consuming to develop than ordered ones, and the cost and time to develop is inherently less predictable.

Sillitto (2010) observes that “engineering design domains that exploit emergence have good mathematical models of the domain, and rigorously control variability of components and subsystems, and of process, in both design and operation.” The iterations discussed above can be accelerated by using simulation and modeling, so that not all the iterations need to involve building real systems and operating them in the real environment.

The idea of domain models is explored further by Hybertson in the context of general models or patternspatterns learned over time and captured in a model space (Hybertson 2009). Hybertson states that knowing what emergence will appear from a given design, including side effects, requires hindsight. For a new type of problem that has not been solved, or a new type of system that has not been built, it is virtually impossible to predict emergent behavior of the solution or system. Some hindsight, or at least some insight, can be obtained by modeling and iterating a specific system design; however, iterating the design within the development of one system yields only limited hindsight and often does not give a full sense of emergence and side effects.

True hindsight and understanding comes from building multiple systems of the same type and deploying them, then observing their emergent behavior in operation and the side effects of placing them in their environments. If those observations are done systematically, and the emergence and side effects are distilled and captured in relation to the design of the systems — including the variations in those designs — and made available to the community, then we are in a position to predict and exploit the emergence.

Two factors are discovered in this type of testing environment: what works (that is, what emergent behavior and side effects are desirable); and what does not work (that is, what emergent behavior and side effects are undesirable). What works affirms the design. What does not work calls for corrections in the design. This is why multiple systems, especially complex systems, must be built and deployed over time and in different environments - to learn and understand the relations among the design, emergent behavior, side effects, and environment.

These two types of captured learning correspond respectively to patterns and “antipatternsantipatterns,” or patterns of failure, both of which are discussed in a broader context in the Principles of Systems Thinking and Patterns of Systems Thinking topics.

The use of iterations to refine the values of emergent properties, either across the life of a single system or through the development of patterns encapsulating knowledge gained from multiple developments, applies most easily to the discussion of strong emergence above. In this sense, those properties which can be observed but cannot be related to design choices are not relevant to a systems approach. However, they can have value when dealing with a combination of engineering and managed problems which occur for system of systems contexts (Sillitto 2010). (See Systems Approach Applied to Engineered Systems.)

References

Works Cited

Abbott, R. 2006. "Emergence explained: Getting epiphenomena to do real work". Complexity, vol. 12, no. 1 (September-October), pp. 13-26.

Bedau, M.A. and P. Humphreys, P. (eds.). 2008. "Emergence" In Contemporary Readings in Philosophy and Science. Cambridge, MA, USA: The MIT Press.

Boccara, N. 2004. Modeling Complex Systems. New York, NY, USA: Springer-Verlag.

Checkland, P. 1999. Systems Thinking, Systems Practice. New York, NY, USA: John Wiley & Sons.

Chroust. G. 2002. "Emergent properties in software systems." 10th Interdisciplinary Information Management Talks; Hofer, C. and Chroust, G. (eds.). Verlag Trauner Linz, pp. 277-289.

Chroust, G., C. Hofer, C. Hoyer (eds.). 2005. The concept of emergence in systems engineering." The 12th Fuschl Conversation, April 18-23, 2004, Institute for Systems Engineering and Automation, Johannes Kepler University Linz. pp. 49-60.

Emmeche, C., S. Koppe, and F. Stjernfelt. 1997. "Explaining emergence: Towards an ontology of levels." Journal for General Philosophy of Science, vol. 28, no. 1, pp. 83-119. Accessed 3 December 2014. Available at:http://www.nbi.dk/~emmeche/coPubl/97e.EKS/emerg.html.

Francois, C. 2004. International Encyclopedia of Systems and Cybernetics, 2nd edition, 2 volumes. Munich, Germany: K.G.Saur Verlag.

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.

Honderich. T. 1995. The Oxford Companion to Philosophy. New York, NY, USA: Oxford University Press.

Hybertson, D. 2009. Model-Oriented Systems Engineering Science: A Unifying Framework for Traditional and Complex Systems. Boca Raton, FL, USA: Auerbach/CRC Press.

Jackson, S., D. Hitchins, and H. Eisner. 2010. "What is the Systems Approach?" INCOSE Insight. 13(1) (April 2010): 41-43.

O’Connor, T. and H. Wong. 2006. "Emergent Properties," in Stanford Encyclopedia of Philosophy. Accessed December 3 2014: Available at: http://plato.stanford.edu/entries/properties-emergent/.

Page, S.E. 2009. Understanding Complexity. The Great Courses. Chantilly, VA, USA: The Teaching Company.

Ryan, A. 2007. "Emergence is coupled to scope, not level." Complexity, vol. 13, no. 2, November-December.

Sillitto, H.G. 2010. "Design principles for ultra-large-scale systems". Proceedings of the 20th Annual International Council on Systems Engineering (INCOSE) International Symposium, July 2010, Chicago, IL, USA, reprinted in “The Singapore Engineer,” April 2011.

US-Canada Power System Outage Task Force. 2004. Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations. Washington-Ottawa. Accessed 3 December 3, 2014. Available: http://energy.gov/oe/downloads/blackout-2003-final-report-august-14-2003-blackout-united-states-and-canada-causes-and

Primary References

Emmeche, C., S. Koppe, and F. Stjernfelt. 1997. "Explaining emergence: Towards an ontology of levels." Journal for General Philosophy of Science, vol. 28, no. 1, pp. 83-119. Available: http://www.nbi.dk/~emmeche/coPubl/97e.EKS/emerg.html.

Hitchins, D. 2007. Systems Engineering: A 21st Century Systems Methodology. Hoboken, NJ, USA: John Wiley & Sons.

Page, S. E. 2009. Understanding Complexity. The Great Courses. Chantilly, VA, USA: The Teaching Company.

Additional References

Sheard, S.A. and A. Mostashari. 2008. "Principles of complex systems for systems engineering." Systems Engineering, vol. 12, no. 4, pp. 295-311.

< Previous Article | Parent Article | Next Article >
SEBoK v. 2.1, released 31 October 2019
Retrieved from "https://sandbox.sebokwiki.org/index.php?title=Logical_Architecture&oldid=57989"