IN THIS EDITION
1. Quotations to Open On
2. Feature Articles
2.1 The “Three Systems” Approach by Richard Beasley
2.2 A Structured Backward Search Method to Analyze Faults from an Architecture by Jens Christian Andersen
3. Notable Articles
3.1 INCOSE India Chapter Is Ten Years Old by Stueti Gupta
3.2 Educating in a World Gone Mad by Shalini Advani
4. Systems Engineering News
4.1 INCOSE IS 2020 – A Huge Success
4.2 Emerging Standards for Supporting Digital Engineering Information Exchange
4.3 Engineering X Gives £1m in Grants to Boost the Quality of Engineering Education in 14 Countries
4.4 The Institution of Engineering and Technology (IET) Encourages the UK to Establish a Systems Engineering Advisory Group for Energy
4.5 The ‘Sustainability Innovators’ Mindset
4.6 Help and Guidance for Managing Interfaces is Available!
4.7 INCOSE is kicking off a New “Smart Cities” Initiative
4.8 Capella Days Online: 12-15 October 2020
4.9 Digital Twin Webinar Series
5. Featured Organizations
5.1 International Association for Engineering, Modeling, and Simulation (NAFEMS)
5.2 The Society for Modeling and Simulation
5.3 The Institution of Engineering and Technology (IET)
6. News on Software Tools Supporting Systems Engineering
6.1 Eclipse Papyrus ™ Modeling Environment
7. Systems Engineering Publications
7.1 Systems Engineering Principles and Practice
7.2 Systems Engineering in the Fourth Industrial Revolution: Big Data, Novel Technologies, and Modern Systems Engineering
7.3 Modeling and Simulation Support for System of Systems Engineering Applications
7.4 Advances in Systems Engineering
7.5 Critical Systems Thinking and the Management of Complexity
7.6 A Journey through the Systems Landscape
7.7 DON’T PANIC – The Absolute Beginner’s Guide to Managing Interfaces
7.8 INCOSE’s Feature-based Systems and Software Product Line Engineering: A Primer
7.9 AFIS Systems Product Line Engineering Handbook
7.10 The Business Case for Systems Engineering Study
8. Education and Academia
8.1 Amid Economic Meltdown, We Must Reimagine the University
8.2 The H. Milton Stewart School of Industrial and Systems Engineering
8.3 University of Technology of Compiègne
8.4 Associate/Full Professor, Systems and Control Technology Position – Eindhoven University of Technology – The Netherlands
9. Some Systems Engineering-Relevant Websites
10. Standards and Guides
10.1 ISO/IEC 26550:2015 Software and Systems Engineering — Reference Model for Product Line Engineering and Management
10.2 ISO/ISO/IEC DIS 26580 – Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering
10.3 ISO 19450:2015 Object Process Methodology (OPM)
11. Some Definitions to Close On
11.1 Verification Requirement
11.2 Generative Design
11.3 Digital Engineering Information Exchange (DEIX)
12. Conferences and Meetings
12.1 ICSSM 2020 International Conference on Systemology and Systems Methodologies [Digital Conference] October 07-08, 2020 in Beijing, China
13. PPI and CTI News
13.1 VIDEO: PPI Launches A New Course: Interface Engineering and Management (IEM) Two Day Course
13.2 First Ever INCOSE SEP Exam Prep Workshop 12-16 October
13.3 PPI Welcomes Kim Claridge to the Team
14. PPI and CTI Events
15. Upcoming PPI Participation in Professional Conferences
“Regard the engineering system as having the same criticality as that of the system being engineered.”
“’Elegance’ in engineering design is an ineluctable concept; it is immediately
apparent when it exists, yet it is difficult to define, impossible to quantify.
It is offered here that, properly understood, systems engineering
at its core is concerned with attaining elegant designs.”
Michael Griffin, Former Administrator of the National Aeronautics and Space Administration (USA)
“How Do We Fix Systems Engineering?” Proceedings of the 61st International Congress
“To finish the moment, to find the journey’s end in every step of the road,
to live the greatest number of good hours, is wisdom.”
Ralph Waldo Emerson
2.1 The “Three Systems” Approach
by
Rolls-Royce PLC
1 August 2020
Abstract
Key aspects of systems engineering are problem framing and understanding the systems with which the system of interest (SoI) (the system being “engineered”) interacts. Classic systems engineering presumes that the SoI “looks up” to the system into which the SoI fits, which is, ultimately, the end user capability system. In addition, there is a third system which must be considered, often referred to as the realization system. This system is in reality a number of systems, including (among other systems) the business/enterprise system of the organization that is producing the SoI. Most often, the end user capability system and the realization system are complex (that is, a system of systems), whereas the SoI, at some level, is a complicated system.
Thus, with the “three system approach”, as in the classic three body problem[1], there is no defined way of addressing it. This article not does not attempt to provide a solution; rather it takes the Systems Approach of attempting to make sure that those creating a system solution (a SoI) are aware of the problem, and thus, empowered to address it as effectively as it is feasible to do so.
Copyright © 2020 by Rolls-Royce PLC. All rights reserved.
Introduction
The purpose of this article is to review the range of systems that must be understood and addressed by an organization if it is to be successful in producing a “System of Interest” (SoI) that it is seeking to create or engineer. In addition to the SoI, there is the environment into which the SoI will be placed in order to deliver its value, and the enterprise system that creates it, consisting of both its capability/realization system, and the business execution that delivers the SoI.
The intent of utilizing the Three Systems Approach is to ensure the problem is fully understood.
The value of systems engineering derives from properly and completely framing the problem, and thus, improving the probability that the system being developed is successful in terms of quality, cost, and timescale (Elm and Goldensten, 2012). Defining requirements provides the criteria for success and the constraints upon the system. Requirements elicitation practice emphasizes the need to consider all stakeholders (Walden et al, 2015). This article emphasizes the need to consider the business enterprise producing the solution, and its capability to produce systems, as a stakeholder.
This article is structured as follows. First, the different types of systems that have to be considered (the “three systems” as introduced above) are defined; and the important differences between complex and complicated systems are reviewed. Second, some issues and consequences of considering these three systems are discussed:
- Development of the organization’s capability to engineer and support SoIs.
- The concern that failing to recognize the nature and state of these three systems can lead to traps hampering innovation.
- The concern that it is to consider the “business enterprise layer” in requirements flow.
Finally, it is important to understand the author’s perspective. The author works for Rolls-Royce (RR) Defense, which supplies power systems that go into platforms such as aircraft, ships, and submarines, that provide military capabilities; and also provides support services for these power systems. This solution provision gives an implicit bias on the author’s view of Systems Engineering, rather than, say, an operator of capability.
System Consideration
The full context for the System of Interest (SoI) must be considered, and the best starting point is James Martin’s classic 7 Samurai (Martin, 2004) which defined the range of systems that are involved with a given System of Interest, including the support, competing, enterprise, and realization systems.
Figure 1 shows a simplification of the “seven samurai” into three systems (Beasley and Pickard, 2020), which are the systems referred to in the title of this article.
Figure 1: Three Systems Model
The author has extended the situation considered in the “seven samurai” paper to take into account organizations with several divisions producing a range of products (Beasley and Pickard, 2018). Figure 2 shows the full range of systems involved (a total of nine, with the outer one having potentially several layers). Note that the system numbers in Figure 2 (for the first 7 systems) match the numbers in Martin’s paper. Figure 3 shows how the how the realization system is shared across the projects, each of which is associated with a specific SoI. A key point concerning Figure 2 is the S8, the business execution system which both coordinates the use of the realization system to develop, produce, service, and dispose of the solution systems, and acts as a stakeholder of those realization systems.
Figure 2: The Range of Systems involved in Creating a System
Figure 3: Realization Systems across Multiple Customer Facing Business Units (CFBUs)
An important consideration is the difference between a complex system (a system of systems) and a complicated system. A reference for this is the Cynefin framework (Snowden and Bowden, 2007). The difference matters because a different approach is needed for complex (“probe-understand-do”) compared to complicated (“understand-plan-do”) system situations. A complicated system is a typical product with multiple layers, but making a coherent whole. Given enough time, causes can be traced to effect. A complex system (and without wanting to oversimplify, all Systems of Systems can be seen as complex) includes separate elements that are “independent” and hence cannot be controlled, and cause to effect can be unpredictable.
This difference is often not appreciated (Kemp, Beasley, and Kemp, 2015), and failure to recognize the difference can lead to either very inefficient system creation (complex methods applied to a complicated situation), or worse, dangerous failure (see Kemp et al 2014 to V or not to V). (Note that INCOSE has been advised that guidance should be developed showing how to adjust the systems approach for each of these situations [see Sillitto et al. 2018]).
From the point of view of Rolls-Royce as a power system provider, these systems can be described as:
System A – the SoI. Rolls-Royce provides physical power (complicated) power system equipment, into a platform (which is mostly complicated), which in turn informs the end-use capability (System B), which is a complicated System of Systems or a capability system. Importantly Rolls-Royce also provides service solutions related to the power systems direct to the end users. This service part of the solution is more of a complex system.
System B – the environment or context system. While the immediate environment for the power system is a platform, there must be an understanding of the end-user. The end-use is a military capability (a complex system). In the UK for example, this is made up of eight capability elements: Training, Equipment, Personnel, Infrastructure, Doctrine, Organization, Information, and Logistics (TEPIDOIL) (Kemp and Daw, 2014). Note that there is significant interaction between the platform and other platform sub-systems. These interactions are produced by different enterprises (involving contractual arrangements) and have an impact.
System C is the Rolls-Royce business enterprise. The Rolls-Royce business is itself a complex system (see Figure 3); its objective is to make money, which it does by producing a range of products and services (numerous instances of System A). It constitutes both realization systems (both architecting and developing), discussed below. Program Management must ensure that a plan to deliver System A is created, and then executed, coordinating and negotiating the allocation of the realization systems and ensuring the realization systems are capable of delivery of the desired project.
Consequences and Implications
- Enterprise capability
One part of System C is the realization system needed to create the solution. Typically, this is seen in product terms as technology readiness which is typically described as Technology Readiness Level (TRL). It is important that TRL claims are made in terms of the context in which the technology will be used (Holt and Beasley, 2011). However just as Equipment is only one element of military capability (the E in TEPIDOIL), so Technology is only one part of the enterprise realization system. This is a complex system and can be described (and architected) as a capability (Beasley and Pickard, 2020). There are three key points to consider:
- In considering capability, Figure 1 can be re-visualized with system C realization becoming the SoI, shown in Figure 4 below:
Figure 4: Three Systems shifted to Focus on Capability to Engineer Systems as SoI
- The elements of enterprise capability need to be defined. In the Rolls-Royce TEPIDOIL, this has been adjusted to conform to the Rolls-Royce engineering approach, as shown in Figure 5.
MoD TEPIDOIL Capability Elements RR TEPIDOIL
Figure 5: RR Engineering Capability Elements related to MoD TEPIDOIL Capability Elements
- To ensure a full consideration of capability, it is necessary to consider when the capability is utilized, depicted in the capability chessboard shown in Figure 6. This is used as a prompt to consider what is needed. Enterprise capability needs to be seen as a complex adaptive system. A complex adaptive system is both a system of systems and a complex system situation, but also one where it currently exists so it is being changed or adapted, rather than replaced. So it is important to recognize that the “target” for capability is always moving.
Figure 6: Generic Capability Chessboard – Provides a Prompt to Consider Capability Completely
The capability elements must not be considered in isolation. Instead, the connections between the elements, making value streams, must be considered.
- Innovation
Looking at the Three Systems Model (Figure 1) can lead to insights regarding potential hazards and traps to successful innovation (Beasley and Ingram, 2020). Two types of innovation, incremental/process and disruptive innovations, were considered. Looking at the systems involved (Figure 2) a number of traps for the innovator to beware of were identified, as shown in Figure 7.
|
Incremental/process innovations |
Disruptive innovations |
|
Trap 1 Trap 2 |
Trap 3 Trap 4 Trap 5 |
Figure 7: Common Innovation Traps
Beasley and Ingram (2020) conclude that although many innovation failures are complex and involve many factors, an ability to understand the products (Systems A), the firm and its internal capabilities (Systems B) and how these fit into the market and environment (System C) is as important for innovators as for Systems Engineers.
- Business execution layer.
This is system S8 shown in Figure 2.
There are two issues to consider:
- Where does the business layer fit into the variety of layers from end-user to power system components? The issue is important because the business enterprise is a complex system, and thus does not fit in hierarchically between the platform and the power system (as it would in a complicated system). It requires the business to be defined as a system in its own right.
- The interaction between Systems Engineering and Program Management has been discussed extensively (see Rebentinsch 2017, for example). In considering Figure 3, Program Management must include defining the activities needed to achieve the SoI (System A); integrate the business needs (including its attitude to risk) with the capability needs of the end-user (System B); coordinate the allocation of the enterprise realization systems (System C); and act as stakeholder for enhancements needed to the realization systems in order for the SoI to be successful, or ensuring constraints imposed by the realization system (which will not change) flow into the requirements for the SoI. So there needs to be controlled iteration not only between System B and System A, but also between System B and System C.
Summary and Conclusions
The author is fond of saying that everything can be thought of as a system in order to gain insight and understanding. The key point to emphasize is that all of the systems involved must be considered correctly. This may at first impression appear to make the situation more confused. However, it is vital to consider the issue and ensure that appropriate understanding is achieved. Typical problems that could result if this is not done include:
- Failure to recognize shortfall in capability. The issue of technology readiness levels (TRL) has been well understood (see for example Holt and Beasley, 2011), but the full range of capability the enterprise needs must be considered.
- Innovation traps.
- Complex and complicated – end user and business requirements are not a hierarchy.
- Design for the full lifecycle.
Epilogue
The ideas presented in Figures 1-3 do make system development seem harder than just thinking of the SoI as a system of parts fitting into a bigger system. However, in reality, considering them provides opportunity. The real problem is failing to recognize the three systems, and thus not considering the whole situation, missing key constraints and opportunities to make the solution better for all stakeholders. Moreover, by considering the full context the risk of failure or expensive rework is reduced.
List of Acronyms Used in this Paper
Acronym Explanation
PLC Public Limited Company
RR Rolls Royce
SoI System of Interest
TEPIDOIL Training, Equipment, Personnel, Infrastructure, Doctrine, Organization, Information, and Logistics
TRL Technology Reference Level
References
Beasley, R., Cardow, I., Pickard, A., and Symons, J., 2018, The Whole Nine Yards of Systems Engineering, INCOSE International Symposium, https://doi.org/10.1002/j.2334-5837.2018.00555.x.
Beasley, R., and Ingram, C., 2020, How Systems Engineering and Systems Thinking Enable Innovation, INCOSE International Symposium (virtual) (in proceedings, not presented).
Beasley, R., and Pickard, A., 2020, The Capability to Engineer Systems is a System Itself, INCOSE International Symposium (virtual) (in proceedings, not presented).
Cowper, D., Kemp, D., Elphick, J. and Evans, R., 2014, To V or not to V – That MUST be the Question,
24th International Symposium of the International Council on Systems Engineering, Las Vegas,
NV, USA.
Elm, J., & Goldenson, D. 2012. “The Business Case for Systems Engineering Study: Results of the
Systems Engineering Effectiveness Survey”. [Technical report] CMU/SEI-2012-SR-009 Soft-
ware Engineering Institute, Carnegie Mellon Univ. Available at http://resources.sei.cmu.edu/library/asset-view.cfm?AssetID= 34061.
Holt, Jonathan, and Beasley, R. 2011, “That wasn’t meant to happen!” Managing the hidden risks of system novelty” INCOSE International Symposium, 21.
Kemp, D., Beasley, R. and Williams, S., 2015, “Suits you sir! — Choosing the Right Style of SE Before Tailoring to Fit”. INCOSE International Symposium, 25: 1245–1262. http://dx.doi.org/10.1002/j.2334-5837.2015.00127.x
Kemp, D. and Daw, A., 2014, INCOSE UK Capability Systems Engineering Guide, INCOSE UK.
Martin, J. N., 2004, The Seven Samurai of Systems Engineering: Dealing with the Complexity of 7 Interrelated Systems. INCOSE International Symposium, 14: 459–470. Available at http://dx.doi.org/10.1002/j.2334-5837.2004.tb00509.x
Rebentisch, Eric, 2017. Integrating Program Management and Systems Engineering: Methods, Tools,
and Organizational Systems for Improving Performance. Hoboken, New Jersey USA: John
Wiley& Sons.
Sillitto H, Arnold E, Dori D, Godfrey P, Griego R, Jackson S, Krob D, Mckinney D, Martin J, (2018) Envisioning Systems Engineering as a Transdisciplinary Venture – INCOSE International Symposium, Washington, July 2018
Snowden, D. & Boone M., 2007, “A leader’s framework for Decision-making”, Harvard Business Re-
view, November 2007.
Walden, D. D., Roedler, G. J., Forsberg, K., Hamelin, R. D. & Shortell, T. M. (eds.) (2015). Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities. Hoboken, NJ: Wiley. ISBN: 978-1-118-99940-0.
About the Author
Richard Beasley joined Rolls-Royce in 1986 with a Physics Degree from Bristol University, and was awarded an MSc in Gas Turbine Engineering from Cranfield University in 1996 (on the job study). After working on Integration Aerodynamics, Safety, Reliability, and Life Cycle Engineering, he became Global Chief of Systems Engineering and in 2011 was made Rolls-Royce Associate Fellow in Systems Engineering. He was part of the BKCASE SEBoK author team, one of the leading authors on the INCOSE SE competency framework, and is a Past-President of the UK INCOSE Chapter, and currently on the INCOSE board as Deputy Director of Services. He is a Chartered Engineer, Fellow of the Royal Aeronautical Society, INCOSE ESEP, and was a Visiting Fellow to the Systems Centre at Bristol University.
2.2 A Structured Backward Search Method
to Analyze Faults from an Architecture
by
Jens Christian Andersen, MSc EE
Email: jcta@novonordisk.com
Novo Nordisk A/S
Denmark
Abstract
This article describes a method to analyze potential faults in a system based on an observed fault in a system output. The method uses a structured backward search method and notation to systematically identify and record causes of faults based on the system architecture. The method can be used proactively during the architecture definition process to support trade-off decisions and identify fault mitigations.
Copyright © 2020 by Jens Christian Andersen. All rights reserved.
Introduction
Analysis of a system for potential faults, consequences, and mitigations often plays an important role during the concept and development stages, especially when the system is safety critical. During the architectural definition stage, a significant amount of the life cycle cost is committed [INCOSE, ref. 1] and conceptual risk trade-offs need to be made [INCOSE, ref. 2].
As stated in [Leveson, ref. 3], one analysis method is generally not sufficient when analyzing faults. The backward search method proposed here is not new and can be found in e.g. [Leveson, ref. 4]. This article describes how to apply the method in a structured manner by traversing an architecture graph of a system and categorizing faults of interfaces and entities along the way. The faults identified can be depicted in a tree graph structure which can be used as input to a fault tree. I have found this method to be a very useful supplement to other analysis methods, especially when functional faults are considered. Structural faults, which can be considered emerging properties from the structural allocation of functions, can be analyzed too.
The method seems very natural in some everyday situations like finding a leaking pipe that causes dripping water. We will instinctively follow the dripping water backwards to the spot where it drips from, follow the flow from the dripping spot backwards along a surface, identify a crack that the water passes through, etc. all the way back to the leaking pipe.
An example
Figure 1 shows the architecture of a simplified high pressure cleaner system. The boxes depict entities in the architecture (physical modules in the product) and the arrows depict flow of mass, energy or information. The diagram could be expressed in e.g. SysML, but I often find plain graphics easier to explain to the domain experts participating in analysis workshops. The important thing is to have a consistent perspective of the system and avoid mixing e.g. functional and structural perspectives.
Figure 1: Architecture of a simplified high-pressure cleaner
The cleaner consists of the following parts:
- Switch: An electric low voltage switch that enables the user to start and stop the cleaner.
- Controller: An electronic module, powered by mains power that reads the Switch and sends a low voltage start/stop signal to the Motor. The Controller gets input from a motor temperature sensor and stops the motor if it gets too hot.
- Motor: An electric motor powered by mains power and started/stopped by a low voltage control signal. The Motor drives the Pump.
- Pump: A mechanical water pump driven by the Motor. The Pump draws in inlet water and generates a high pressure water flow on the outlet.
- Output Hose: A high pressure hose connecting the Pump to the Nozzle.
- Nozzle: A nozzle emitting the high pressure water. The Switch is structurally attached to the Nozzle without any functional coupling.
- Input Hose: A low pressure hose connecting the cleaner to a domestic water tap.
The architecture in Figure 1 is a model that will serve as input to the fault[2] analysis. For illustration, I have chosen the fault to emit water as scope of the analysis. The architecture is annotated with fault type codes (F, P, S, and C), see Figure 1 legend. In order to keep track of progress of the analysis, the annotation can be added to the architecture diagram as the analysis progresses. Alternatively, a tree structure as shown in Figure 2 can be built to depict the control structure as the analysis progresses. Of course, the tree can be annotated with primary (P) and secondary (S) faults, if desired. A third option (not shown here) is to represent the tree structure as a textual description with indentation for each backward search level.
We now start with the system level fault to be analyzed: No water from Nozzle. We denote this fault F1. The causes behind this fault can be divided into three categories [Leveson, ref. 5]:
- Primary Fault: The module fails due to reliability limitations caused by e.g. random failures or wear.
- Secondary Fault: The module fails due to use beyond specifications, e.g. low temperature.
- Control Fault: The module works correctly but is given a wrong input which consequently causes a wrong output.
A primary fault of the Nozzle could be occlusion or some internal functional failure, depending on the design. Note that occlusion could also be considered a secondary fault if we consider entry of occluding material to be use beyond specification. Any internal fault could be further analyzed by use of e.g. the Failure Modes and Effects Analysis (FMEA) method [FMEA, ref. 7]. We denote the primary fault P1.
Figure 2: Control fault tree. Nodes represent OR logic.[3]
A secondary fault of the Nozzle could be a frozen condition or incorrect attachment to the Output Hose. Note that the inclusion of secondary faults forces the analysis to consider the context and not only the system. Many risks have emerged from changes in context rather than product [Leveson, ref. 6]. The frozen condition and incorrect attachment both relate to use error and could be analyzed by the Hazard and Operability (studies) (HAZOP) method [HAZOP, ref 8]. However, the consequences often need to be analyzed in the technical domain e.g. by the FMEA method [FMEA, ref. 7].
Note that incorrect attachment can be viewed as an analysis of the interface between the Nozzle and the Output Hose and could therefore also be considered a control fault. The important thing is to remember to include the interfaces in the analysis, as interfaces often are prone to error due to the shared responsibility of the interfacing modules [Leveson, ref. 9]. We denote the secondary fault S1.
A control fault of the Nozzle is No water supplied to Nozzle. Of course, the Nozzle will fail to emit water if none is supplied. We denote the control fault C1.
The backward search now follows the control fault C1 back to the module that provides the control, in this case the Output Hose. We therefore identify the fault F2 to be analyzed: No water from Output Hose.
Primary fault P2 of the Output Hose could be a leak or occlusion.
Secondary fault S2 could be a frozen condition or kinks in the Output Hose.
Of course, different domain knowledge is needed for different types of modules. Analyzing a hose will require different skills than analyzing an electronic controller module. We can improve the efficiency of the analysis by building failure mode libraries for various types of modules. The library will serve as a corporate memory and ensure consistency and continuity over time. We can, for example, record the failure modes related to the Output Hose and use it for the Input Hose. If new knowledge about hoses is acquired during subsequent analysis, we will add that to the library and evaluate previous assessments based on the updated knowledge. As stated above, the analysis is very much about context so we cannot expect to simply push the lessons learned from the Input Hose on to the Output Hose. We should always analyse a module in context and pull the experience from previous work and evaluate it in context.
Control fault C2 of the Output Hose is No water supplied to Output Hose.
As above, the backward search now follows the control fault C2 back to the module that provides the control, in this case the Pump. We therefore identify the fault F3 to be analyzed: No water from Pump.
Primary fault P3 of the Pump could be e.g. a stuck turbine, broken turbine blades or an internal gasket leaking. If the Pump is a sourced module, it may not be productive to analyse the internals in depth as we cannot control or mitigate the failures. However, it may be useful to analyse or acquire information about the faults as observed on module level. Can the Pump fail in a way that causes free flow, meaning that we cannot stop water flow by stopping the driving motor? Will the Pump become overheated if not supplied with water?
Secondary fault S3 of the Pump could be non-horizontal orientation (if horizontal operation is required) or pumping of an incompatible fluid that causes the Pump to get stuck. We should state the fault at module level as e.g. “Pump stuck” (meaning axial movement not possible), “No water from Pump” or “Pump leaking”.
The Pump has two inputs (water from the Input Hose and mechanical energy from the Motor) and consequently two possible sources of control fault. We therefore use dot notation C3.1 and C3.2.
Control fault C3.1 of the Pump is No water supplied to Pump.
Backward search identifies fault F4 to be analyzed: No water from Input Hose.
Primary fault P4 and secondary fault S4 are similar to P2 and S2 above as the same faults are identified for the Input Hose and Output Hose. As mentioned above, there could be different faults, e.g. related to the hose attachment interfaces where the Input Hose could be attached by the end user and the Output Hose attached by the manufacturer.
Control fault C4 is No water supplied to Input Hose.
The Water Tap has two outputs (water flow and indication of open/closed state). We therefore use dot notation. F5.1 and F5.2.
Backward search identifies fault F5.1 to be analyzed: No water from Water Tap. Here we have reached the system boundary and scope of the analysis. However, it may make sense to continue the analysis to support the end user in trouble shooting the interfacing systems. We could e.g. identify the control fault C5: Tap not opened.
An interesting issue here, although beyond scope of the analysis, is that the corresponding fault F0.1: Knob not turned could be due to incorrect input to the user C0.1: Incorrect Tap state given to user. The cause could be the control fault F5.2: Knob indicates open position although Tap is closed. As can be seen, faults can propagate across technical domains and user domains. If the user is given wrong information due to a technical fault, the user will perform an incorrect action and trigger a wrong technical state. In other words, the user can be seen as an interacting controller similar to technical controllers. The example here illustrates a simple linear event chain. More complex interaction errors can emerge as well [Leveson, ref. 8].
We have now followed the C3.1 branch to the end (i.e. no more controls for backward search) and can continue with C3.2.
Control fault C3.2 of the Pump is No mechanical energy supplied to Pump.
Backward search identifies fault F7.1 to be analyzed: No Motor movement.
Primary fault P7 of the Motor could be e.g. a stuck rotor or worn out brushes needing replacement.
Secondary fault S7 of the Motor could be e.g. water ingress or too high load from the Pump. We have already identified too high load as faults P3 and S3 when we analyzed the Pump. If these faults were not already identified, we would go back and add them to the Pump analysis. It is in general not productive to analyze all faults up front as some may not be relevant in scope. For instance, a leaking gasket may be of no importance to the pumping function and only lead to minor dripping from the cleaner.
Like the Pump, the Motor has two inputs (power from the Mains Socket and a start/stop signal from the Controller) and consequently two possible sources of control fault. We therefore use dot notation C7.1 and C7.2.
It is a matter of taste whether failing mains power to the Motor is considered secondary fault or control fault. In Figure 1, the power is shown as an input to the Motor rather than an ambient condition like humidity. For that reason, the power is considered a control with the corresponding control fault C7.1: No electricity supplied to Motor.
Backward search identifies fault F8 to be analyzed: No power from Mains Socket. Here we have reached the system boundary and scope of the analysis. Again, it may make sense to continue the analysis to support the end user in trouble shooting the interfacing systems. We could e.g. identify the control error C8: Power plug not connected, or power not turned on. The corresponding use error could have the similar wording F0.2: Power plug not inserted, or power not turned on.
We have now followed the C7.1 branch to the end (i.e. no more controls for backward search) and can continue with C7.2.
Control fault C7.2 of the Motor is No start signal to Motor.
Backwards search identifies fault F9 to be analyzed: No start signal from Controller.
Primary fault P9 of the Controller could be e.g. electronic component failure or connector failure.
Secondary fault S9 of the Controller could be e.g. water ingress or too high operating temperature.
The Controller has three inputs (power from the Mains Socket, a start/stop signal from the Switch, and a temperature signal from the Motor) and consequently three possible sources of control fault. We therefore use dot notation C9.1, C9.2 and C9.3.
Control fault C9.1 of the Controller is No electricity supplied to Controller and we can therefore refer to the previous analysis of F8: No power from Mains Socket.
We have now followed the C9.1 branch to the end (i.e. no more controls for backward search) and can continue with C9.2.
Control fault C9.2 of the Controller is No start signal to Controller.
Backward search identifies fault F10 to be analyzed: No start signal from Switch.
Primary fault P10 of the Switch could be e.g. worn out electrical contact points.
Secondary fault S10 could be e.g. water ingress.
Control fault C10 of the Switch is Switch not turned on. The corresponding use error could have the wording F0.3: Cleaner not turned on.
We have now followed the C9.2 branch to the end (i.e. no more controls for backward search) and can continue with C9.3.
Control fault C9.3 of the Controller is High temperature input to Controller which causes the Controller to shut down the Motor. Note that, although being an intended function of the design, the control fault is in scope as it causes the cleaner to fail in a controlled manner.
Backward search identifies fault F7.2 to be analyzed: Too high Motor temperature.
Primary fault P7 of the Motor has been analyzed above. We could add overheating as a consequence of stuck rotor.
Secondary fault S7 of the Motor has been analyzed too. We could add overheating as a consequence of too high load from the Pump.
We have now followed the C9.3 branch to the end (i.e. no more controls for backward search) and have ended the analysis of the fault: No water from Nozzle.
Next step could be to mitigate the faults by improved design, by providing error codes for trouble shooting etc.
Summary and Conclusions
The backward search method described here has several advantages. It uses the system architecture as the starting point and therefore supports early identification of faults and corresponding trade-off decisions and mitigations. The method limits the scope of analysis to one system fault and therefore requires limited effort if only a few faults are in scope.
An interesting aspect is that the method, as part of the structured backward search process, identifies common cause failures, i.e. failures that impact more than one entity simultaneously.
The method has broad applicability and has previously been successfully applied for direct cause analysis of an embedded software system, including criticality assessment of software items and interfaces.
Context plays a big role when analyzing safety critical systems. Often, threats come from changed environment rather than changes to the system. The described method includes secondary faults (use outside intent or specifications) to support this aspect.
The method allows for inclusion of design specific failures in the architectural analysis. For example, structural knowledge, like too high load from a pump, can be fed back to the architectural analysis as secondary motor faults in a subsequent analysis iteration. These emergent properties resulting from the specific design cannot, per definition, be analyzed up front unless they are known from design constraints in the selection of the components.
A few pitfalls have been encountered when utilizing the method:
- It is tempting to stop the backward search before all paths have been followed in order to keep the analysis on a high level. This potentially leads to missed faults from downstream entities including use errors. Experience also shows that this leads to excessive work, difficulties in argumentation, and a wrong abstraction level in describing the faults.
- It is a common mistake to split into domains of e.g. mechanics, electronics, and software instead of tracking a fault through the domains. This violates the systematic nature of the analysis. The domain split is only correct if e.g. software controls hardware which controls mechanics without the complexity of feedback loops.
List of Acronyms Used in this Paper
Acronym Explanation
FMEA Failure Modes and Effects Analysis
HAZOP Hazard and Operability (studies)
INCOSE International Council on Systems Engineering
SysML Systems Modeling Language
References
- INCOSE Systems Engineering Handbook, Fourth Edition. Wiley, 2015, p 14. ISBN 978-1-118-99940-0.
- INCOSE Systems Engineering Handbook, Fourth Edition. Wiley, 2015, p 30. ISBN 978-1-118-99940-0.
- Leveson, Nancy G, Safeware: System Safety and Computers. Addison-Wesley, 1995, p. 307.
ISBN 0-201-11972-2.
- Leveson, Nancy G, Safeware: System Safety and Computers. Addison-Wesley, 1995, pp. 307-309.
ISBN 0-201-11972-2.
- Leveson, Nancy G, Safeware: System Safety and Computers. Addison-Wesley, 1995, p. 173.
ISBN 0-201-11972-2.
- Leveson, Nancy G, Safeware: System Safety and Computers. Addison-Wesley, 1995, pp. 61-63.
ISBN 0-201-11972-2.
- IEC 60812:2018 Failure modes and effects analysis (FMEA and FMECA).
- IEC 61882:2016 Hazard and operability studies (HAZOP studies) – Application Guide.
- Leveson, Nancy G, Engineering a Safer World: Systems Thinking Applied to Safety. MIT Press, 2011.
ISBN 978-0-262-01662-9.
About the Author
Jens Christian Andersen is President of INCOSE Denmark. He holds an MSc EE from the Technical University of Denmark where he has been an invited lecturer in safety risk management since 2009.
Prior to joining Novo Nordisk in 2003, he spent 15 years in embedded software engineering and co-design of electronics and software, including safety critical designs.
At Novo Nordisk, Jens is a specialist in systems engineering and process expert in safety risk management.
3.1 INCOSE India Chapter Is Ten Years Old
by
Stueti Gupta
President, INCOSE India
India is both a global IT technology hub as well as manufacturing hub for several industries. There is growing interest in the field of Systems Engineering. Some practices are driven by the organization processes and some due to adoption of complex technologies. An INCOSE India Chapter objective is to increase visibility and credibility of INCOSE in India. The Chapter has approximately 160 members, of whom more than 60 members are INCOSE SEP certified. There are three local working groups that are currently active, Architecture, Model Based Systems Engineering, and Prognostics and Health Management (PHM). This year, the India Chapter is honored to receive the Gold Circle Chapter Award and the Director’s Award for the most improved Chapter performance.
To mark the tenth anniversary, the INCOSE India Program Committee launched a webinar series for learning and networking among systems engineering professionals. Ten webinars have been organized so far and are being well attended by both industry professionals and academia with very engaging discussion – these webinars are available here:
Evolving Systems Engineers to Meet Tomorrow’s Changing Needs
Serge Landry, Director, INCOSE Asia Oceania Sector
The Story of the INCOSE Telescope Challenge Team and the OpenSE Cookbook
Robert Karban, Lead, Systems Environment, Jet Propulsion Lab, NASA
Who is an Effective Systems Engineer?
Dr. Devanandham Henry, Head of SE, General Aeronautics, Bangladore
Resiliency in Systems Engineering
Rick Hefner, Ph.D, Program Director, California Institute of Technology
Prognostics and Health Management (PHM), Systems Engineering, and Standards [see editor’s note below]
Ravi Rajamani, PhD., FSAE, FIMechE
Developing Safety Critical Systems
Dr. Yogananda Jeppu, Principal SE, Honeywell Technology Solutions and Adjunct Faculty, Manipal University
Functional Safety – Automotive Avionic Systems
Reveendra Menon, CSEP, Principal Member, Technical Staff, SENZOPT Technologies PVT LTD, Bangladore
Systematic vs. Systemic – What’s the Difference?
Jawahar Bhalla (JB), Principal, JB Engineering Systems and Technical Director, Systems Engineering Society of Australia (SESA)
A Model Centric Framework and Approach for Complex Systems Policy
Shamsnaz Virani Bhada, Ph.D, Assistant Professor in Systems Engineering, Worcester Polytechnic Institute
Machine Learning models for aiding System Architecture Design Decisions
Dr. Ramakrishnan Raman, Principal Engineer, Honeywell and Assistant Director, INCOSE Asia Oceania Sector
If you would like to connect with the INCOSE India Chapter, please email the Chapter at IncoseIndiaChapter@gmail.com.
One can follow the Chapter activities on the Chapter Website (https://www.incose.org/incose-member-resources/chapters-groups/ChapterSites/india/chapter-home) and Twitter (https://twitter.com/INCOSE_India).
Editor’s note: [Expanding on PHM] Prognostics is an engineering discipline focused on predicting the time at which a system or a component will no longer perform its intended function. This lack of performance is most often a failure beyond which the system can no longer be used to meet desired performance. The predicted time then becomes the remaining useful life (RUL), which is an important concept in decision making for contingency mitigation. The discipline that links studies of failure mechanisms to system lifecycle management is often referred to as prognostics and health management (PHM), sometimes also system health management (SHM) or—in transportation applications—vehicle health management (VHM) or engine health management (EHM). Technical approaches to building models in prognostics can be categorized broadly into data-driven approaches, model-based approaches, and hybrid approaches. Source: Wikipedia
3.2 Educating in a World Gone Mad
by
Shalini Advani
Director of Pathways School Noida and Author of Schooling the National Imagination
Source: The Times of India
This systems thinking must go alongside an active teaching of compassion. The approach is defined as a Compassionate Systems Framework
There is a word which is echoing in my head in these times. It is the Hindi word “parlay”. Smacking as it does of mythological stories my grandmother told me, or worse, the invocation of Hindu evangelists, the bizarre times we live in seem to be most appropriately encapsulated in the concept of the apocalypse, the deluge, cataclysm – parlay.
Covid-19 has had us retreating into caves of isolation. It created a world in which companions are to be feared, family exists only in the ether, and like in the medieval plague, those who fall sick are hounded from their neighborhood, a public proclamation in red on their door telling every passer-by to beware, a Covid-19 patient lurks within. As if this dystopia from an Avengers movie was not enough, the locusts moved in from west Africa, attacking 1 lakh[4] hectares so far and waiting to breed once the monsoon hits, followed quickly by not one cyclone but two at opposite ends of the country.
How do we educate in these times? What do we educate about?
The crisis for education which the pandemic has brought home, lays bare a longstanding poverty at the heart of how we think about what is worth learning. Suddenly every ten-year-old is forced to confront impermanence and death in their backyard. Poorer students have had their familiar world yanked away with teacher layoffs and school closures because of shortage of funds. Too many have been forced from the classrooms and playgrounds where they shared lives with their friends. Even middle-class children have been introduced to financial precariousness as businesses have folded and jobs are lost.
This is a level of trauma which is currently under recognized. Nothing in our education system prepares children for loss or cataclysmic change. But if we are to rescue an entire generation from this rupture of the stable and familiar, we need to urgently rethink both our systems and what we teach.
We need to recognize that Covid-19 disruptions in learning are real and need to be addressed. An inclusive education approach should ensure that all children succeed. If we do not move away from the race to complete the syllabus, where success is measured by marks, the learning gaps created over this time of closure will expand. The only way schools can navigate a time of loss and upheaval is to pay more attention to the emotions and attitudes of their students, rather than on content. For a truly healing environment, social justice, empathy, and taking care of others must move to the center of what is worth learning.
We all make sense of our lives and worlds through the stories we tell about ourselves. Education – what we learn, how we learn – is a building block of our story about ourselves. The story we have so far taught, is a story of individual success and even societal success as measured in hard currency. As a society we are educated into a narrative of hard work breeding success, the clever idea or boldness resulting in a breakthrough.
Failure, its social origins and its impact on those who fall behind, never figures. Redefining failure is important. Students are recognizing that it is no longer possible to be individually successful unless we address systemic problems. Survival will only be possible for the collective and not the individual.
What, then, is the story which our educational content should evolve out of? There are many ways we can rethink the story we need to tell. Perhaps the need for this can most easily be summed up in the images which have seared our minds and the minds of our children – that of people walking eight hundred miles, dragging a suitcase with a sleeping child. Or of once economically secure families confronting ruin as they lose jobs and businesses collapse.
This is a time which requires education to reframe its purpose to teach an understanding of the interconnectedness of our world. But how can we help our young people respond mindfully and compassionately rather than just feeling overwhelmed by the complexity of social and economic systems? Even quite young people are far from ignorant about the cataclysmic changes the world is experiencing. Most feel a profound sense of empathetic distress but they often feel helpless to alleviate or even to resist the larger engines of social systems.
At this time education needs to reformat its purpose.
When we help students reflect on the choices they are making as citizens or consumers, we help them understand larger systems. This systems thinking must go alongside an active teaching of compassion. This approach defined as a Compassionate Systems Framework developed by Peter Senge and others at the Abdul Latif Jameel World Education Lab at MIT helps them reflect on and respond mindfully and compassionately to systemic challenges in their own lives and beyond, their connections to one another and their impact on us as individuals and on our communities. Without this combination of empathy and analytic understanding, young people can only react to circumstances that seem out of their control, assign blame, missing entirely all our own agency in shaping those circumstances. Imagine instead an education system where the central story we tell, is not about content but an understanding based in a combination of compassion and systems analysis. If we began there we would change the very purpose of education.
4.1 INCOSE IS 2020 – A Huge Success
The INCOSE International Symposium, a virtual event held from July 20-22, 2020, was a huge success, thanks to many, and particularly to countless hours of hard work by the members of the organizing committee. There were 506 participants from 31 countries, 74 panel presentations and papers, and three keynote addresses, in addition to an insightful and inspirational President’s Address by Kerry Lunny. We will be reporting on several of these and other highlights of the IS in articles in this and future issues of PPI SyEN.
Highlights of selected IS 2020 events are provided in eleven short videos on YouTube.
Greg Parnell announced the 2020 INCOSE Fellows:
- Duncan Kemp
- Gerrit Muller
- “Ad” Sparrius
- Gan Wang
4.2 Emerging Standards for Supporting Digital
Engineering Information Exchange
INCOSE’s Digital Engineering Information Exchange (DEIX) Working Group (WG) has set a goal to establish a finite set of digital artifacts that acquiring organizations and their global supply chains should use to request an exchange with each other as well as internally between teams/organizational elements:
Goal 1 – Define a Finite Set of Digital Artifacts: Define a finite set of digital artifacts that take advantage of digital technology to satisfy stakeholders’ information needs as it relates to systems engineering lifecycle standards such as ISO/IEC/IEEE 15288, 15289, 15504-6, 12207, 26531 and 24748.
Goal 2 – Develop Constructs for assembling Digital Artifacts: A set of constructs and conventions that define how to select, compile, and analyze digital artifacts to produce digital engineering content for stakeholders.
Goal 3 – Identify, Leverage and Influence Standards to Improve Digital Artifact Exchange: To use the understanding of existing and missing DEIX related standards literature to evolve a consensus-based standards framework for a Digital Engineering Information Exchange Model (DEIXM). To identify existing standards and conventions that apply to Digital Artifacts Exchange, determine the needs for digital artifact related standards; and then, determine the gaps. Finally, in coordination with INCOSE Standards Initiative, liaise with foreign and domestic standards organizations to petition for changes or additions based on knowledge gained from DEIXM products.
Goal 4 – Adopt a Common Lexicon: Define concepts, achieve community acceptance, and monitor adoption of the lexicon by the global supply chain as a means to describe digital artifacts.
The INCOSE DEIX Working Group provided a presentation at the INCOSE IS 2020, “Emerging Standards for Supporting Digital Engineering Information Exchange”. The Presentation provided a wealth of information, including a detailed list of existing and planned DEIX-related products, an Information Exchange Model for the Digital Engineering Ecosystem, a list of the members of the Contributing Team, an explanation of the need for standards to facilitate data exchange in the global supply chain, a process for converting digital artifacts to digital views for consumption and exchange, digital engineering use cases, information concerning more than 50 standards that have been surveyed, lessons learned applicable to MBSE information exchange, and key areas to enable systems engineering data exchange and collaboration.
An article providing additional information is planned for a future issue of PPI SyEN.
4.3 Engineering X Gives £1m in Grants to Boost the Quality of Engineering Education in 14 Countries
Source: The Royal Academy of Engineering
Published: 31 July 2020
Engineering X – an international collaboration founded by the Royal Academy of Engineering and Lloyd’s Register Foundation – has awarded grants of up to £50,000 each to 21 projects in 14 different countries across Africa, Asia, the Middle East and South America to support the delivery of skills and education programs. The projects will help develop domestic engineering capability and ensure that critical infrastructure can be built, operated and maintained safely without an over-reliance on multinational organizations and temporary, expatriate labor.
Previous research by Engineering X published in the Global Engineering Capability Review found that for many countries there is no problem with the number of engineers they produce. However, the quality and relevance of the training of their engineers is inadequate to meet national requirements, and the engineering skills needed and training required can vary greatly between countries.
As the pace of technological change accelerates, no nation can afford to ease up on its efforts to conduct engineering in a safe and innovative way. The projects funded today are collaborative partnerships that will use potentially disruptive ideas to support domestic infrastructure and help local engineers to develop the skills and capacity to adopt emerging and life-improving technologies at scale.
Some of the projects will help to increase the uptake of engineering among school children by promoting the provision of high-quality STEM teaching. Others aim to enhance quality, challenge-oriented education in engineering institutions such as vocational/technical colleges, apprenticeship providers, and engineering universities, including furthering the impact of Africa’s first post-graduate fire safety engineering degree.
Included among those receiving grants are projects to upskill the existing engineering and technician workforce to improve safety practices and enhance their ability to use emerging technologies. These include a plan in Uganda to build entrepreneurship, leadership, and management skills of women engineers and technicians through housing innovation.
A scheme to teach cybersecurity engineering in Ghana typifies projects that support policy and partnerships to develop capacity to take advantage of opportunities to tackle existing or emerging engineering and safety challenges at scale.
A full list of all the projects can be found here.
During the application process, some applicants asked – and were granted – permission to change their projects in response to the emerging COVID-19 crisis. For example, a project in Kenya to train electrical technicians on one particular off-grid solar access project proposed instead that training should switch to the installation and maintenance of solar systems for use in healthcare facilities. The project also aims that 50% of trainees should be female.
4.4 The Institution of Engineering and Technology (IET) Encourages the UK to Establish a Systems Engineering Advisory Group for Energy
The Institution of Engineering and Technology (IET) believes that the UK must learn lessons from Covid-19 and is calling for a significant acceleration in decarbonizing its economy.
The IET is calling on the Government to:
- Establish a Systems Engineering Advisory Group for energy, to bring together the multi-disciplinary expertise required to meet the Net Zero challenge.
- Commit to and implement an agile Whole System approach to achieving Net Zero.
- Urgently review, with stakeholders, how the current legal and regulatory structure of the energy industry could be reformed to facilitate the Net Zero transition for a range of scenarios.
- Put in place arrangements to enable smaller stakeholders (supply chain, SMEs, innovation/start-ups etc.) to be actively involved in the sector.
Craig Lucas, Chair of the IET Energy Policy Panel said: “The Coronavirus pandemic has dramatically shown how interconnected our world is – internationally and locally. It has also highlighted the interdependencies, unintended consequences, resilience issues, and risks within complex systems that have multiple human, technical, regulatory, and commercial interfaces.
It has also clearly demonstrated why society needs a joined-up approach to deal with such crises, now and in the future. This learning can be applied to address the challenges of the climate emergency as we navigate a path to Net Zero.
4.5 The ‘Sustainability Innovators’ Mindset
by
I’m currently mentoring a brilliant young client keen to increase her sustainability knowledge. One thing we’ve wrestled with is how to equip ourselves with the right kind of thinking and mentality for today’s monumental sustainability challenges.
“I don’t know how to name this yet”, she explained, as we set our mentoring agenda at the start, “so I’m calling it the ‘sustainability mindset’ at the moment.”
As a terrific and well-respected Packaging Engineer working in a recognized sustainable brand leader, my mentee has bags of experience implementing things like recycled materials, clean production, sustainable design, and other relevant concepts.
Yet sustainability is a moving target and a few newer, emergent sustainable business concepts can prove more difficult to immediately place – like pre-competitive collaboration or systems change. How do these things fit and especially how do you understand what to practically do about all this?
How innovators can adopt the right mindset for 21st Century sustainability is a question that many of us are grappling with. In this blog, I share our discussions in the hope it might help others in their own journey too. Below are our four characteristics for the Sustainability Innovators Mindset.
Think Exponential
Commentators now talk of the ‘20s as the Exponential Decade, borrowing terminology from the tech and digital sphere. They argue that tomorrow’s innovations must aim for 10 times better not just 10% improvements in sustainability performance.
Sustainability is thus a revolutionary concept requiring disruptive, breakthrough, radical, game-changing innovation. We will not continuously improve our way of trouble and are seeing clear limits to an incremental redesign of what exists today.
Sustainability think tank Volans has some of the most advanced work on Exponential thinking and their own Breakthrough Business Models report summarizes this well: “we must spur a mind-set shift from incrementalism to increasingly exponential, experimental, breakthrough thinking”.
Future sustainability innovators must think differently and think big.
Think in Systems and Systemic
It’s been hard to miss sustainability calls for system change or systemic approaches, but what does it mean for everyday innovators? This shifts the focus from individual ‘things’ to wider systems that support and enable success; where a system is a set of parts connected by a web of relationships.
Two important aspects of this are, firstly, to focus change at the level of sectors, industries, categories or, at the very least, an entire value chain. Few organizations have done more to promote systems thinking than Ellen MacArthur Foundation with their own programs tackling circularity in sectors like Plastics, Fashion or Food, in just this way.
Secondly, systems-based approaches consider the related conditions that can affect or enable an innovation’s success. As an obvious example, a recyclable packaging innovation can only work in a well-functioning recovery and reprocessing infrastructure, and with an engaged public behavior and participation, all necessary parts of the system.
Successful sustainability innovators of the future will also be systems thinkers.
Early-Stage Thinking
The third characteristic is very personal to me, the importance of front-end thinking for sustainability. The much-quoted statistic is that ‘80% of the environmental impact of products and services occurs during early-stage design’ – underscoring the importance of starting with sustainability in mind.
This oft-termed the ‘fuzzy-front end’ of sustainability has important implications for where, how, and who does sustainable innovation. The phase is more traditionally the practice of R&D, strategy, or design, rather than the EHS, quality or supply chain of our traditional sustainability functions.
Much too often sustainability is integrated late-on in the process, when all important decisions are made and when there are less degrees of freedom to radically change things. Sustainability should be added to ‘the brief’ as early as possible, better still sustainability should ‘be the brief’.
Innovators of the future will have sustainability in mind from the outset.
Think Integrated
Ever started a packaging development project and soon realized the solution needs behavior change? Or started new product development only to realize the solution requires a new business model?
Companies tend to pigeon-hole innovation projects into a functional area or department to budget and manage things more easily – which can be marketing, product development, sourcing and supply chain, or others.
One problem is that environmental and social problems tend not to respect these clearly delineated functional or departmental boundaries. You soon find that what started as a packaging material problem, like plastic waste, can soon become an infrastructure, local authority, or user behavior question; who ‘owns’ the problem in this case? As a result, that packaging team leading on this may lack the skills, influence, or remit to deliver – leading to half-baked and ineffective results.
The best sustainable innovation projects are integrated into their approach exploring where product, pack, supply chain, marketing, and business model innovation overlaps.
So there you have it – these are our four characteristics for the Sustainability Innovators mindset. I’m sure there are others and I’d love to hear yours.
4.6 Help and Guidance for Managing Interfaces is Available!
Paul Davies provided a presentation at the INCOSE IS 2020 entitled “Interface Management – the Neglected Orphan of Systems Engineering”. Paul indicated that we need to change the mindset of systems engineers to make them aware that the number of interfaces goes up very quickly; that it’s not just software; and that traceability becomes a nightmare. He recommends left-shifting interface design at successive levels of analysis – requirements, architecture, logical design, and physical design.
Abstract
Every Interface is an opportunity to lose information, time, control and / or money through contention between stakeholders at either end. There are many issues surrounding Interface management, which are relatively unexplored in the engineering literature. Interface management is perceived as a critical skill in the engineering of successful systems, but finding useful material on the subject proves elusive. It is not that there is a gap in the collective Body of Knowledge (BoK) – but there is definitely a gap in the documented BoK. This paper explores some of the characteristics of this gap, and strings together some of the key concepts in best practice. Along the way, the differences between best practice for interfaces and best perceived practice for architecting systems are noted, and recommendations for changes in approach are given.
Editor’s Note: See the review provided below (in Section 7.7) of Davies’ new book, Don’t’ Panic: The Absolute Beginner’s Guide to Managing Interfaces.
Review the INCOSE IS 2020 Presentation here.
Paul Davies is presenting a course on the topic – Interface Engineering and Management offered by Project Performance International. To find out more about the course and to register for a course in your region, click here.
4.7 INCOSE is kicking off a New “Smart Cities” Initiative
INCOSE’s Deputy Technical Director Chris Hoffman advises that INCOSE is in a unique position to support our communities. Much has developed in Smart Cities (SC) initiatives, and systems engineering can contribute. The INCOSE SC Initiative has developed a draft model for stakeholder consideration and needs definition. Although Smart Cities have been evolving for ten years, they continue across the world. For example, Philadelphia’s (Pennsylvania USA) SC journey has helped COVID-19 responsiveness. We are seeking holistic and aligned solutions for overcoming challenges and realizing goals.
(INCOSE CONNECT Login Required)
From Wikipedia
A smart city is an urban area that uses different types of electronic Internet of things (IoT) sensors to collect data. Insights gained from that data are used to manage assets, resources and services efficiently; in return, that data is used to improve the operations across the city. This includes data collected from citizens, devices, buildings and assets that is then processed and analyzed to monitor and manage traffic and transportation systems, power plants, utilities, water supply networks, waste, crime detection, information systems, schools, libraries, hospitals, and other community services.
4.8 Capella Days Online
12-15 October 2020
What is Capella?
Capella is an open-source and field-proven Model-Based Systems Engineering (MBSE) solution to successfully design systems architecture.
It provides systems, software and hardware architects with rich methodological guidance relying on Arcadia, a comprehensive model-based engineering method based on both industrial experimentations and system engineers’ feedback.
Natively supporting Arcadia, Capella can be customized to fit the specific needs of many industrial domains.
What is Capella Days?
This event organized by Obeo, in partnership with Thales, Altran and TNO-ESI, brings together the community of Capella and Arcadia:
- creators of this innovative systems engineering solution,
- providers of Capella add-ons and services,
- MBSE experts and industrial users.
This year Capella Days will happen in conjunction with ESI webinar day, the 6th of October 2020.
Why you should attend?
Capella Days is your opportunity to learn from Capella ecosystem members.
Discover the roadmap, get insights about methodology, MBSE trends and latest Capella features.
Benefit from the experience of industrial adopters who have successfully deployed an MBSE approach with Arcadia and Capella on their projects.
4.9 Digital Twin Webinar Series
Digital Twin Consortium is producing a webinar series to update and educate the Digital Twin Community on current work-in-progress, road maps and goal.
Upcoming webinar topics in October and November 2020
Application of Digital Twin Technology to Infrastructure – Developing Best Practice
Digital Twins in Manufacturing – An Enormous Opportunity
Applying Digital Twin Technologies in Aerospace & Defense
Available on Demand: What is Digital Twin Consortium?
Learn more about how Digital Twin Consortium, the Authority on Digital Twin, is driving efforts to advance digital twin technology across markets, improving interoperability and influencing future standards and requirements, and how you and your company can get involved.
Speakers:
Richard Ferris, Head of Engineering, Lendlease; co-chair of Digital Twin Consortium Infrastructure Working Group; Digital Twin Consortium Steering Committee
Jordan Garrett, Digital Twin and Edge Solutions Lead Dell Technologies; co-chair Aerospace and Defense Working Group
Dan Isaacs, VP & Technical Director, Digital Twin Consortium
Sameer Kher, Senior Director, Product Development, Ansys; co-chair of Manufacturing Working Group; Digital Twin Consortium Steering Committee
Maureen Robusto. VP Marketing and Corporate Communication, Digital Twin Consortium
Pieter van Schalkwyk, CEO, XMPRO; co-chair of Natural Resources Working Group
James A. Sumpter, PhD, Air Force Research Lab; co-chair Aerospace and Defense Working Group
Dr. Said Tabet, Distinguished Engineer, Chief Architect Emerging Technology & Ecosystems, CTO Office, DELL Technologies; Digital Twin Consortium Steering Committee; co-chair of the Technology, Terminology and Taxonomy Working Group
Register for the webinars here.
5.1 International Association for Engineering, Modeling, and Simulation (NAFEMS)
NAFEMS is the International Association for the Engineering Modelling, Analysis and Simulation Community. NAFEMS is a not-for-profit organization which was established in 1983.
The principal aims of NAFEMS are to:
- Improve the professional status of all persons engaged in the use of engineering simulation.
- Establish best practice in engineering simulation.
- Provide a focal point for the dissemination and exchange of information and knowledge relating to engineering simulation.
- Promote collaboration and communication.
- Act as an advocate for the deployment of simulation.
- Continuously improve the education and training in the use of simulation techniques.
- Be recognized as a valued independent authority that operates with neutrality and integrity.
NAFEMS focuses on the practical application of numerical engineering simulation techniques such the Finite Element Method for Structural Analysis, Computational Fluid Dynamics, and Multibody Simulation. In addition to end users from all industry sectors, our stakeholders include technology providers, researchers and academics.
Priority Goals for the Development of the Organization
NAFEMS strives to continually evolve the ways in which it operates and to constantly improve the extent to which it fulfils the primary aims that are listed above. The NAFEMS Council of Management has established the following priority goals for the development of the organization:
- Increase its global reach
- Enlarge its technological breadth, strengthen its involvement in the provision of simulation training and extend the training material that is available
- Publish up to date practical simulation cases of value and substance to simulation engineers
- Expand the information that is available on different simulation techniques and the various simulation tools that are provided
- Further develop services for the exchange of simulation information between specialists worldwide on topics of particular interest
- Improve its interaction with existing member companies and communicate with an increased number of individuals within those companies.
5.2 The Society for Modeling and Simulation
The Society for Modeling & Simulation International (SCS) was established in 1952 as a nonprofit, volunteer-driven corporation called Simulation Councils, Inc. Simulation Councils, Inc. became The Society for Computer Simulation which is where we derived the acronym SCS.
SCS is the premier technical Society dedicated to advancing the use of modeling & simulation to solve real-world problems; devoted to the advancement of simulation and allied computer arts in all fields; and committed to facilitating communication among professionals in the field of simulation. To this end, SCS organizes meetings, sponsors and co-sponsors national and international conferences, and publishes the SIMULATION: Transactions of The Society for Modeling and Simulation International and the Journal of Defense Modeling and Simulation magazines. In addition to this, SCS also created The McLeod Modeling and Simulation Network (M&SNet) in 2003, which is a consortium of co-operating independent organizations active in professionalism, research, education, and knowledge dissemination in the modeling and simulation (M&S) domain. M&SNet aims to provide an organizational structure that will serve to integrate and enrich, within its organizations, modeling and simulation activities throughout the world. The M&SNet provides a framework within which organizations interested in M&S can interact, share expertise, and work on problems of common interest.
The SCS is a volunteer-driven society and is always looking for new volunteers with fresh ideas and perspectives to continue to improve our society, its benefits and our events. If you’d like to volunteer in any way, Contact SCS and we’ll find an opportunity that matches your desires and abilities.
For more information about SCS and its history, read the Current SCS Bylaws and Current SCS Policy Document.
5.3 The Institution of Engineering and Technology (IET)
The Institution of Engineering and Technology (IET) is a British multidisciplinary professional engineering institution. The IET was formed in 2006 from two separate institutions: the Institution of Electrical Engineers (IEE), dating back to 1871, and the Institution of Incorporated Engineers (IIE) dating back to 1884. Its worldwide membership is currently in excess of 168,000. The IET’s main offices are in Savoy Place in London, England and at Michael Faraday House in Stevenage, England.
In the United Kingdom, the IET has the authority to establish professional registration for the titles of Chartered Engineer, Incorporated Engineer, Engineering Technician, and ICT Technician, as a licensed member institution of the Engineering Council.
The IET represents the engineering profession in matters of public concern and assists governments in making the public aware of engineering and technological issues. It provides advice on all areas of engineering, regularly advising Parliament and other agencies.
The IET also grants Chartered Engineer, Incorporated Engineer, Engineering Technician, and ICT Technician professional designations on behalf of the Engineering Council UK. This is roughly equivalent to North American Professional Engineer designations and CEng is set at a higher level. Both designations have far greater geographical recognition. This is made possible through a number of networks for engineers established by the IET including the Professional Networks, worldwide groups of engineers sharing common technical and professional interests. Through the IET website, these networks provide up-to-date sector-specific news, stock a library of technical articles and give members the opportunity to exchange knowledge and ideas with peer groups through dedicated discussion forums. Particular areas of focus include education, IT, energy and the environment.
The IET has an educational role, seeking to support its members through their careers by offering a professional home for life, producing advice and guidance at all levels to secure the future of engineering. For instance, the IET accredits degree courses worldwide in subjects relevant to electrical, electronic, manufacturing and information engineering. In addition, it secures funding for professional development schemes for engineering graduates including awards scholarships, grants and prizes.
6. News on Software ToolS Supporting
Systems Engineering
6.1 Eclipse Papyrus ™ Modeling Environment
by
Alwyn Smit
Pr Eng CSEP
Principal Consultant and Course Presenter
https://www.eclipse.org/papyrus/
Eclipse Papyrus is an open source Model-Based Engineering tool for industrial and academic applications. Eclipse Papyrus has become a PolarSys (the Industrial Working Group of Eclipse) Solution.
In order to federate the industrial needs and efforts on MBE, a Papyrus Industry Consortium has been setup.
Eclipse Papyrus provides for the following technologies:
UML 2.5.0
Eclipse Papyrus is a graphical editing tool for UML 2 as defined by OMG. It targets to implement 100% of the OMG specification!
Eclipse Papyrus provides editors for all the following UML diagrams:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
SysML 1.1 and 1.4
Eclipse Papyrus also provides complete support to SysML in order to enable model-based system engineering. Specific tabular and graphical editors required for SysML are also provided:
- Block Definition Diagram
- Internal Block Diagram
- Requirement Diagram
- Parametric Diagram
- Requirement table
- Allocation table
Model execution
Thanks to Moka, Eclipse Papyrus can execute models using a rich and extensible animation and simulation framework. Also, as graphical modeling is not always the best way for specifying the behavior of executable models, Eclipse Papyrus provides textual notation edition with syntax highlight, completion and content assist. It is also a customizable feature of Eclipse Papyrus.
Fully customizable environment
All the modeling features of Eclipse Papyrus are designed to be customizable and to maximize reuse. You can adapt the standard configuration for a specific domain, notation, modeling practice or use the powerful customization mechanisms of Eclipse Papyrus to adapt the modeling environment to suit your needs. With many configurations in Eclipse Papyrus being model-based, the customization can be done live.
- Define your own graphical, textual or tabular notation.
- Filter existing palettes or define your own ones with a model-based configuration.
- Define dedicated properties views to present just the characteristics that are important to you.
- Read your model with dedicated model explorer structuring and rendering.
- Reuse standard languages or define your own modeling language thanks to the UML profile editor.
Eclipse Papyrus relatives
Many technologies complement, extend or use Papyrus. Following are key examples:
- Papyrus RT for Real-time Systems modeling.
- Papyrus for Robotics: a Papyrus-based modeling environment dedicated to robotics.
- Papyrus PolarSys Solution: Eclipse Papyrus packaged as a PolarSys Solution.
- Eclipse UML Profiles Repository.
- Papyrus Tools: a collection of tools that complement Eclipse Papyrus.
- Eclipse Safety Framework: a set of tools for integrating safety techniques within a model driven engineering process.
7. Systems Engineering Publications
7.1 Systems Engineering Principles and Practice (3rd Ed.)
by
Alexander Kossiakoff, Steven M. Biemer, Samuel J. Seymour, and David A. Flanigan
From the Amazon.com Website:
Systems Engineering: Principles and Practice, 3rd Edition is the leading interdisciplinary reference for systems engineers. The up-to-date third edition provides readers with discussions of model-based systems engineering, requirements analysis, engineering design, and software design. Freshly updated governmental and commercial standards, architectures, and processes are covered in-depth. The book includes newly updated topics on:
- Risk
- Prototyping
- Modeling and simulation
- Software/computer systems engineering
Examples and exercises appear throughout the text, allowing the reader to gauge their level of retention and learning. Systems Engineering: Principles and Practice was and remains the standard textbook used worldwide for the study of traditional systems engineering. The material is organized in a manner that allows for quick absorption of industry best practices and methods.
Throughout the book, best practices and relevant alternatives are discussed and compared, encouraging the reader to think through various methods like a practicing systems engineer.
Publisher: Wiley Series in Systems Engineering and Management (Book 1), 3rd Edition (July 8, 2020)
Format: Kindle, Hardcover
ISBN-10: 1119516668
ISBN-13: 978-1119516668
7.2 Systems Engineering in the Fourth Industrial Revolution:
Big Data, Novel Technologies, and Modern Systems Engineering
Edited by
Ron S. Kenett, Robert S. Swarz, and Avigdor Zonnenshain
From the Amazon.com Webpage:
Systems Engineering in the Fourth Industrial Revolution: Big Data, Novel Technologies, and Modern Systems Engineering offers a guide to the recent changes in systems engineering prompted by the current challenging and innovative industrial environment called the Fourth Industrial Revolution―INDUSTRY 4.0. This book contains advanced models, innovative practices, and state-of-the-art research findings on systems engineering. The contributors, an international panel of experts on the topic, explore the key elements in systems engineering that have shifted towards data collection and analytics, available and used in the design and development of systems and also in the later life-cycle stages of use and retirement.
The contributors address the issues in a system that involves data in its operation, contrasting with earlier approaches in which data, models, and algorithms were less involved in the function of the system. The book covers a wide range of topics including five systems engineering domains: systems engineering and systems thinking; systems software and process engineering; the digital factory; reliability and maintainability modeling and analytics; and organizational aspects of systems engineering. The book:
- Presents new and advanced approaches, methodologies, and tools for designing, testing, deploying, and maintaining advanced complex systems.
- Explores effective evidence-based risk management practices.
- Describes an integrated approach to safety, reliability, and cyber security based on system theory.
- Discusses entrepreneurship as a multidisciplinary system.
- Emphasizes technical merits of systems engineering concepts by providing technical models.
Written for systems engineers, Systems Engineering in the Fourth Industrial Revolution offers an up-to-date resource that contains the best practices and most recent research on the topic of systems engineering.
Publisher: Wiley; 1 edition (December 24, 2019)
Format: Kindle, Hardcover
ISBN-10: 1119513898
ISBN-13: 978-1119513896
7.3 Modeling and Simulation Support for System of Systems Engineering Applications
Edited by
Larry B. Rainey and Andreas Tolk
From the Amazon.com Website:
“…a much-needed handbook with contributions from well-chosen practitioners. A primary accomplishment is to provide guidance for those involved in modeling and simulation in support of Systems of Systems development, more particularly guidance that draws on well-conceived academic research to define concepts and terms, that identifies primary challenges for developers, and that suggests fruitful approaches grounded in theory and successful examples.”
Paul Davis, The RAND Corporation
Modeling and Simulation Support for System of Systems Engineering Applications provides a comprehensive overview of the underlying theory, methods, and solutions in modeling and simulation support for system of systems engineering. Highlighting plentiful multidisciplinary applications of modeling and simulation, the book uniquely addresses the criteria and challenges found within the field.
Beginning with a foundation of concepts, terms, and categories, a theoretical and generalized approach to system of systems engineering is introduced, and real-world applications via case studies and examples are presented. A unified approach is maintained in an effort to understand the complexity of a single system as well as the context among other proximate systems. In addition, the book features:
- Cutting edge coverage of modeling and simulation within the field of system of systems, including transportation, system health management, space mission analysis, systems engineering methodology, and energy
- State-of-the-art advances within multiple domains to instantiate theoretic insights, applicable methods, and lessons learned from real-world applications of modeling and simulation
- The challenges of system of systems engineering using a systematic and holistic approach
- Key concepts, terms, and activities to provide a comprehensive, unified, and concise representation of the field
- A collection of chapters written by over 40 recognized international experts from academia, government, and industry
- A research agenda derived from the contribution of experts that guides scholars and researchers towards open questions
Modeling and Simulation Support for System of Systems Engineering Applications is an ideal reference and resource for academics and practitioners in operations research, engineering, statistics, mathematics, modeling and simulation, and computer science. The book is also an excellent course book for graduate and PhD-level courses in modeling and simulation, engineering, and computer science.
Publisher: Wiley; 1 edition (February 9, 2015)
Format: Hardcover
ISBN-10: 1118460316
ISBN-13: 978-1118460313
7.4 Advances in Systems Engineering
Edited by
From the Amazon.com Website:
Traditional Systems Engineering (SE) has flourished since the United States first entered the space race and developed Intercontinental Ballistic Missiles. In ensuing decades more complex systems and/or systems-of-systems have resulted from continuous advancements in the technological world. Industry has been challenged by the constantly evolving needs for managing the growing number of systems and interfaces.
Advances in Systems Engineering helps to address these challenges by shedding light upon modern systems engineering thought processes and paradigms. Its purpose is to explore research and development advances that are at the forefront of systems engineering.iol
Publisher: American Institute of Aeronautics & Astronautics (September 30, 2016)
Format: Hardcover
ISBN-10: 1624104088
ISBN-13: 978-1624104084
7.5 Critical Systems Thinking and the Management of Complexity
by
From the Amazon.com Website:
The world has become increasingly networked and unpredictable. Decision makers at all levels are required to manage the consequences of complexity every day. They must deal with problems that arise unexpectedly, generate uncertainty, are characterized by interconnectivity, and spread across traditional boundaries. Simple solutions to complex problems are usually inadequate and risk exacerbating the original issues.
Leaders of international bodies such as the UN, OECD, UNESCO and WHO — and of major business, public sector, charitable, and professional organizations — have all declared that systems thinking is an essential leadership skill for managing the complexity of the economic, social and environmental issues that confront decision makers. Systems thinking must be implemented more generally, and on a wider scale, to address these issues.
An evaluation of different systems methodologies suggests that they concentrate on different aspects of complexity. To be in the best position to deal with complexity, decision makers must understand the strengths and weaknesses of the various approaches and learn how to employ them in combination. This is called critical systems thinking. Making use of over 25 case studies, the book offers an account of the development of systems thinking and of major efforts to apply the approach in real-world interventions. Further, it encourages the widespread use of critical systems practice as a means of ensuring responsible leadership in a complex world.
Publisher: Wiley; 1 edition (March 15, 2019)
Format: eTextbook, Hardcover
ASIN: B07PR5QR4M
7.6 A Journey through the Systems Landscape
by
From the Amazon.com Website
Learning to utilize system concepts as first class objects as well as methodologies for systems thinking and systems engineering provides a basis for removing the mystery and moving towards mastery even for complex systems. This journey through the Systems Landscape has been developed to promote learning to “think” and “act” in terms of systems. A unique aspect is the introduction of concrete system semantics provided as a “system survival kit” and based upon a limited number of concepts and principles as well as a mental model called the system-coupling diagram. This discipline independent presentation assists individuals and is essential for building a learning organization that can utilize a systems approach to achieving its enterprise goals. The eight chapters are presented as stops along a journey that successively build system knowledge. Each chapter terminates with a Knowledge Verification section that provides questions and exercises for individuals and groups. Case studies reflecting the utilization of the system related concepts, principles and methodologies are provided as chapter interludes.
Publisher: College Publications (June 8, 2010)
Format: Paperback
ISBN-10: 1848900104
ISBN-13: 978-1848900103
7.7 DON’T PANIC – The Absolute Beginner’s Guide to Managing Interfaces
by
The following review was provided by Alwyn Smit, System Engineering Principal Consultant and Course Presenter, Project Performance International (PPI)
The first time I picked up this book, I thought: “ Mmm…., very thin, it must be a beginner’s guide.” Even though the book is a beginner’s guide, I have had Master’s students in some of my classes that do not understand even the most elementary principles in this book. Do not underestimate this book it – it is full of valuable “basic” principles that are not so basic to many people.
One of the valuable features of the book is the use of icons to illustrate pitfalls, myths, key concepts, scary aspects, and benefits. The fact that it not intended as an academic textbook, probably resulted in it cutting through the fluff and addressing those issues that matter in practice. I got the distinct feeling that the book captures what works in practice.
Chapter 1 introduces interfaces in the context of a system and its elements. An important key concept is the definition of an interface: A shared boundary between two or more systems or system elements, defined by characteristics pertaining to functional or physical exchanges between them. Chapter 2, What’s Special About interfaces?, provides some critical insights into what is involved in specifying interfaces, interface complexity, and the critical aspects of interface traceability and standardisation.
The different types of interfaces are addressed in Chapter 3, with emphasis on the fact that this is about much more than just software and data. Davies offers three reasons why interfaces need to be managed as part of system design: 1) To ensure nothing is forgotten; 2) To assist in assigning interfaces of the same type to the same disciplinary group for analysis and participation in design; and 3) To help plan integration sequencing.
Chapter 4 concerns representing interfaces – how we find out what interactions are needed for the system, and how to present them intuitively to the stakeholders. The objective is to get agreement on what is, and what is not required, and who will do what to make the interaction work. The system context diagram is used to not only represent but also to help identify the external interfaces of the system and what it exchanges across those interfaces. Drawing the system context diagram at a very early stage in the project, and getting it agreed with internal and external stakeholders, greatly reduces the risk of late and costly arguments concerning interface mismatches and integration failures.
“A picture is worth a thousand words. An Interface is worth a thousand pictures”
Ben Shneiderman
Chapter 5 explains how to deal with interface complexity – through the use of sequence diagrams to capture the interactions between an actor and the system. There is no way to specify an interface if you do not understand what is exchanged across it and in what sequence. The chapter also addresses the use of standardization through patterns and layers. Internal interfaces are a product of design.
Chapter 6 provides methods to evolve an architecture that minimizes the complexity of the interfaces, which eases the burden of integration, testing, and acceptance. The chapter discusses the use of N-squared charts in identifying all the possible internal interfaces and how the chart helps to limit the number of interfaces through the smart allocation of system functions to system elements. An optimal solution minimizes connectivity, maximizes cohesion, and minimizes coupling. The chapter concludes with some beneficial architecting principles. One of the mistakes we sometimes make is to limit our design to the operational phase of the system.
Chapter 7 clearly illustrates that there is a whole set of interfaces at play in each of the system life cycle phases. The chapter further identifies minimum documentation for capturing interface requirements and interface design. The chapter concludes with advice gained from hundreds of man-years of accumulated experience in integration testing across interfaces.
Chapter 8 recommends using both documents and models to specify interfaces. A set of ten steps guides the reader through the use of a modeling approach.
Chapter 9 summarizes this valuable book, identifies additional benefits and pitfalls, and notes that a systems engineer who is experienced in interface management can help the project manager identify potential problem areas and establish an effective change management and mismatch resolution process. The author reminds the reader that everything we do must add value. If there are standard interfaces – electrical, mechanical, software, environmental, and on that are fit for purpose, use them.
Throughout the book, the author makes recommendations on books that will facilitate implementing effective systems engineering.
Publisher: INCOSE UK
ISBN 978-0-9934857-4-9
Format: Paperback
Paul Davies’ Presentation Concerning Interface Management at INCOSE IS 2020
7.8 INCOSE’s Feature-based Systems and Software Product Line Engineering: A Primer
Feature-based Product Line Engineering lets you build your product line portfolio as a single production system rather than a multitude of individual products. INCOSE’s Product Line Engineering International Working Group is supporting the ISO Standard 26580 – Feature-based Product Line Engineering. This primer is intended to serve as an introductory companion to that standard. This primer provides a starting point to learn about this powerful approach. It offers a brief introduction to PLE, explains how it works, and provides sources of information to learn more. Feature-based PLE transforms the task of engineering a plethora of products into the much more efficient task of producing a single system: The PLE Factory itself. Shared assets are the “soft” artifacts associated with the engineering life cycle of the products. A shared asset can be any artifact representable digitally: requirements, design models, source code, test cases, BoMs, wiring diagrams, documents, and more. They either compose a product or support the engineering process to create a product. To resolve the quagmire brought about by different disciplines each using its own approach to variation, a key aspect of Feature-based PLE is consistent and traceable treatment of variation across all shared asset types. Feature choices are the basis of a common language of variation across all disciplines and at all levels of the organization. Organizations that adopt PLE as a key business strategy consistently garner significant competitive advantage in the form of more wins, more innovative and higher quality systems and products, faster engineering and business velocity, and higher revenue and profits. Effectively adopting Feature-based PLE involves much more than just installing a tool to manage the Feature Catalogue and configure products. Leadership commitment — not just tacit approval — is a critical ingredient for success.
7.9 AFIS Systems Product Line Engineering Handbook
A Product Line is a set of products with common elements and variable features. Including Product Lines in an overall development strategy tailored to the commercial and/or industrial context delivers significant benefits: products that are more suitable, reduction in cost, shorter development timescales, quality improvement, etc.
This work, Systems Product Line Engineering Handbook, brings together a summary of the state-of-the-art with lessons learned from industrial experience in implementing Product Lines of various kinds, in terms of marketplace, number of applications, degree of variability, etc. It is practical, and is intended to complement existing Systems Engineering manuals; it adopts the same process structures.
It includes:
- Definitions and examples: Product Line, Product Lines organizations, Product Line Engineering.
- Processes, from needs analysis through to disposal.
- Systems Engineering methods, particularly Model-Based Product Line Systems Engineering.
- Organization: development in silos, development in platforms.
- Implementation strategies and management processes.
The book is intended for practitioners: engineers, project managers, instructors, researchers, students and developers of systems that fit into this approach.
Elected INCOSE Product of the Year – 2015.
7.10 The Business Case for Systems Engineering Study: Results of the Systems Engineering Effectiveness Survey
Joseph P. Elm and Dennis Goldenson
This report summarizes the results of a survey that had the goal of quantifying the connection between the application of systems engineering (SE) best practices to projects and programs and the performance of those projects and programs. The survey population consisted of projects and programs executed by system developers reached through the National Defense Industrial Association Systems Engineering Division (NDIA-SED), the Institute of Electrical and Electronics Engineers Aerospace and Electronic Systems Society (IEEE-AESS), and the International Council on Systems Engineering (INCOSE). Analysis of survey responses revealed strong statistical relationships between project performance and several categories of specific SE best practices. The survey results show notable differences in the relationship between SE best practices and performance between more challenging and less challenging projects. The statistical relationship with project performance is quite strong for survey data of this kind when both SE capability and project challenge are considered together.
Access this Report
8.1 Amid Economic Meltdown, We Must Reimagine the University
University World News
12 September 2020
COVID-19 has presented higher education with opportunities to replace inefficiencies with reimagined solutions.
8.2 The H. Milton Stewart School of Industrial and Systems Engineering
Georgia (USA) Institute of Technology
The H. Milton Stewart School of Industrial and Systems Engineering (ISyE) has achieved national and international prominence through its tradition of excellence and leadership in research, education, and service. This distinction is due to ISyE’s world-class faculty, students, curricula, and research focusing on improving quality of life. Working at the intersection of engineering, mathematics, computing, and business, students learn to design effective systems.
ISyE’s undergraduate program has been ranked a #1 program since 1991 according to the U.S. News & World Report. While many students seek out the program because of its high rankings, they are also attracted to the number of concentrations and academic interests offered.
Master’s degrees introduce students to advanced concepts from the fields of industrial engineering, systems engineering, operations research, statistics, and computational science through rigorous programs of coursework. Flexible curricula allow students to tailor programs to their interests. Graduates earning a general Master’s degree may choose to take a position in industry or to apply into a doctoral program to begin a career in research. Georgia Tech offers a Professional Master’s in Applied Systems Engineering.
ISyE offers two core Ph.D. degrees, one in Industrial Engineering and one in Operations Research. Most faculty in the School participate in advising students in both programs. A Ph.D. from ISyE provides students with both solid training in fundamental analytical methodology through advanced coursework and guided self-study, and also collaborative mentorship from a world-class faculty in the pursuit of cutting-edge research in industrial engineering, operations research, or statistics.
8.3 University of Technology
Compiègne, France
Relying on pedagogy that favors autonomy and interdisciplinary technological research focused on innovation, the University of Technology of Compiègne (UTC) trains engineers including offering master’s degrees and PhDs to manage the interactions of technology with mankind and society. UTC has eight research laboratories and open international vista, and ranks among the leading engineering schools in the world. UTC offers a European Master’s in Engineering for Complex and Interacting Systems, a French Master’s Degree, and UTC’s Doctoral School, “Science for Engineers”, among other offerings. UTC’s research strategy calls for technological, partnership, inter-cultural, and conduciveness to innovative development. UTC is pursuing forms of technological research that answer societal questions generated by environmental issues that are becoming increasingly acute. The aim is to bring the university’s research policy closer to real-life socio-economic problems.
8.4 Associate/Full Professor, Systems and Control Technology Position
Eindhoven University of Technology – The Netherlands
The Eindhoven University of Technology, abbreviated TU/e, is a technical university in the Netherlands, operating in English. The University has been placed in the top 200 universities in the world by five major ranking tables. TU/e has an open position at the associate/full professor level in the broad field of control in the Control Systems Technology (CST) section with the aim to address these future challenges through strengthening and extending the research in the area of systems and control.
The CST section is among the largest and high-impact research centers in control globally, where both fundamental and applied research are performed at the highest level. Current research lines include control and systems theory, cyber-physical and multi-agent systems, optimization, artificial intelligence, machine learning, systems engineering, as well as mechanical design. Applications are often done in close collaboration with industry, where the CST section is uniquely positioned in a key high-tech region (Brainport Eindhoven). Application areas include mechatronic system design and motion systems, robotics, autonomous vehicles and mobility, smart medical devices, energy systems including nuclear fusion, and agrifood.
The CST section currently consists of a diverse and committed team of 29 full-time and part-time staff members and 50+ post-doctoral and PhD researchers. The section currently consists of eight Principal Investigators (PIs), who are responsible for specific scientific research lines and act as mentor for tenure-track researchers, with the aim to promote teamwork and individual growth of tenure-track researchers into PIs. This position will start immediately at the PI level, where the candidate will perform leading research in her/his discipline and build a research group, while at the same time has a unique opportunity to enrichen her/his research with close collaboration with researchers within the section, as well as outside within our unique ecosystem. Eindhoven University of Technology’s vision is that high-quality research and teaching are strongly connected, and teaching activities are therefore strongly connected to the envisioned research lines.
Job Requirements:
- PhD degree in systems and control or another relevant engineering field.
- Proven expertise in a relevant core discipline, for instance, system theory, dynamical systems, control, optimization and optimization-based control, machine learning, artificial intelligence, data-based modeling and design, systems engineering, equipment and system design.
- Experience in a relevant application domain, for instance mechatronics, robotics, mobility and transportation systems, health applications, smart industry, energy, agricultural systems, energy systems, etc.
- An excellent track record in scientific research, acquisition of externally funded research projects, and research vision.
- Strong academic and/or industrial network.
- Promote excellence and co-operation nationally, internationally, and societally.
- Excellent communication skills, entrepreneurship, organization and leadership skills demonstrating the potential to build your own research group.
- Extensive teaching experience and proven didactic skills.
- Excellent proficiency in English (Written and verbal).
9. SOme Systems Engineering-Relevant Websites
Second Generation Product Line Engineering
Evolving from its early first generation roots, Second Generation PLE (2GPLE) is a first-class engineering practice centered on the creation of a PLE factory. This innovative, yet pragmatic, approach is experiencing mainstream adoption across industry sectors, in organizations from small to some of the largest in the world.
This website provides an overview and informational resources regarding 2GPLE. You can learn about PLE concepts such as shared assets, variation points, feature catalogue, bill-of-features, and more. Explore how PLE works and its key benefits, review notable PLE success stories, and discover approaches for adopting PLE in your organization.
http://www.productlineengineering.com/
Other related links:
INCOSE Product Line Engineering Working Group
Product-centric Development is Dead: Long Live Product Line Engineering
Partnership for Systems Approaches to Safety and Security (PSASS)
This website is the home of the PSASS. The goal of PSASS is to create and evaluate new tools and processes that use systems thinking to provide more comprehensive, more efficient, and more effective results. Ensuring safety and security in modern systems will require multi-disciplinary and collaborative research based on sound system engineering principles. PSASS uses participation from multiple MIT schools (engineering, management, social sciences, and sciences) as well as collaborators at other universities and industry partners. This site contains materials, resources, tools in the field of systems safety and security free to explore and download.
http://psas.scripts.mit.edu/home/
McLeod Modeling and Simulation Network (M&SNet)
The McLeod Modeling and Simulation Network (M&SNet) is a consortium of cooperating independent organizations active in professionalism, research, education, and knowledge dissemination in the modeling and simulation (M&S) domain. It was established in 2003 by the Society for Modeling and Simulation International (SCS). The M&SNet provides a framework within which organizations interested in M&S can interact, share expertise, and work on problems of common interest. The site contains information about the membership, conferences, projects and workshops.
10.1 ISO/IEC 26550:2015
Software and Systems Engineering — Reference Model for Product Line Engineering and Management
ISO/IEC 26550:2015 is the entry point of the whole suite of International Standards for software and systems product line engineering and management.
The scope of this International Standard is to:
- Provide the terms and definitions specific to software and systems product line engineering and management,
- Define a reference model for the overall structure and processes of software and systems product line engineering and management and describe how the components of the product line reference model fit together, and
- Define interrelationships between the components of the product line reference model.
ISO/IEC 26550:2015 does not describe any methods and tools associated with software and systems product line engineering and management. Descriptions of such methods and tools will appear in the consecutive International Standards (ISO/IEC 26551[1] to ISO/IEC 26556[2]). This International Standard does not deal with terms and definitions addressed by ISO/IEC/IEEE 24765:2010 that provides a common vocabulary applicable to all systems and software engineering work.
Whenever this International Standard refers to “products”, it means “system-level products” consisting of software systems or both hardware and software systems. It may be useful for the engineering and management of product lines that consist of only hardware systems but it has not been explicitly created to support such hardware product lines. This International Standard is not intended to help the engineering, production, warehousing, logistics, and management of physical items that, possibly combined with software, comprise the products. These processes belong to other disciplines (e.g. mechanics, electronics).
10.2 ISO/ISO/IEC DIS 26580
Software and systems engineering — Methods and tools for the feature-based approach to software and systems product line engineering
Feature-based Software and Systems Product Line Engineering (“Feature-based PLE” for short) is a specialization of Software and Systems Product Line (SSPL) engineering and management that is described in ISO/IEC 26550 (see above). That standard describes a generalized approach to SSPL, focusing on the benefits of exploiting a common platform of reusable assets for a product family. Each organization that adopts SSPL under ISO/IEC 26550 is free to do so using their preferred techniques and methods.
What is the motivation for creating a standard for a specialization of SSPL? As the SSPL field has matured and achieved widespread attention in the industry, a specific and repeatable approach to SSPL has emerged that takes advantage of commercial off-the-shelf industrial-strength tools and technology, along with robust best practices for methods and processes that automate and formalize many of the processes in domain and application engineering. The result is that less upfront analysis, design, and implementation effort is required prior to gaining the benefits from the approach.
While SSPL in general provides significant benefits, it also requires a significant investment of time and effort to adopt and to ultimately achieve those benefits. The Feature-based PLE specialization is a more narrowly defined solution that can be supported by off-the-shelf tools and methods, which has resulted in lower investments when an organization adopts SSPL. Feature-based PLE embodies lessons learned about SSPL practices that have been shown to provide some of the highest benefits and returns.
This standard provides a reference model consisting of an abstract representation of the key technical elements, tools, and methods of Feature-based PLE. The predominant specializations of general SSPL that characterize Feature-based PLE are:
- A mapping from features to asset variation points that is sufficient to drive a fully automated configurator that produces assets specific to member products; and
- A methodological shift of all design and implementation effort, change management, and configuration management to domain engineering, so that application engineering is reduced to automated configuration of member product instances and testing of configured member products and member-product-specific assets.
10.3 ISO 19450:2015
Object Process Methodology
(OPM)
ISO/PAS 19450:2015 specifies Object-Process Methodology (OPM) with detail sufficient for enabling practitioners to utilize the concepts, semantics, and syntax of Object-Process Methodology as a modelling paradigm and language for producing conceptual models at various extents of detail, and for enabling tool vendors to provide application modelling products to aid those practitioners.
While ISO/PAS 19450:2015 presents some examples for the use of Object-Process Methodology to improve clarity, it does not attempt to provide a complete reference for all the possible applications of Object-Process Methodology.
A Model Based Concurrent Engineering Framework using the ISO-19450 Standard
11. Some definitions to close on
11.1 Verification Requirement
“Verification Requirement: a requirement that defines the quality or strength of the evidence needed to satisfy a requirement owner that a specified requirement has been met.”
Source: Project Performance International
“A verification requirement provides the rules of verification for a piece of data (verifiable data item). There are many variables included in these rules including where and how the rules apply at runtime.”
Source: IBM
“Verification requirements specify the verification events needed to prove the satisfaction of the product requirements and help to define the verification process and environment.”
Source: Northrop Grumman
“A verification requirement should include an expanded test criteria description to ensure against disagreement later in the program. This can include describing the number of trials, statistical criteria to be used, conditions of the test such as simulated inputs, etc.”
Source: MITRE
11.2 Generative Design
Generative Design is the capability of Mechanical Computer-Aided Design (MCAD) applications to autonomously generate one or more geometric designs to satisfy specific objectives and constraints.
Source: Chad Jackson
Generative design is an iterative design process that involves a program that will generate a certain number of outputs that meet certain constraints, and a designer that will fine tune the feasible region by changing minimal and maximal values of an interval in which a variable of the program meets the set of constraints, in order to reduce or augment the number of outputs to choose from.
Source: Wikipedia
11.3 Digital Engineering Information Exchange (DEIX)
The exchange of digital artifacts between system engineering entities (processes, models, and organizational elements).
Source: INCOSE DEIX Working Group
For more information on systems engineering related conferences and meetings, please go to our website.
The featured event for this edition is:
ICSSM 2020 International Conference on Systemology and Systems Methodologies [Digital Conference]
October 07-08, 2020 in Beijing, China
The International Conference on Systemology and Systems Methodologies aims to bring together leading academic scientists, researchers and research scholars to exchange and share their experiences and research results on all aspects of Systemology and Systems Methodologies. It also provides an interdisciplinary platform for researchers, practitioners and educators to present and discuss the most recent innovations, trends, and concerns as well as practical challenges encountered and solutions adopted in the fields of Systemology and Systems Methodologies.
The selected papers to be presented are:
Sliding Mode Power System Stabilizer for Synchronous Generator Stability Improvement
J. Ritonja, R. Brezovnik, M. Petrun, B. Polajžer
Socio-Technical Systems: Transforming Theory into Practice
L. Ngowi, N. H. Mvungi
Systems Engineering and Project Management Process Modeling in the Aeronautics Context: Case Study of SMEs
S. Lemoussu, J. C. Chaudemar, R. A. Vingerhoeds
Tools for Analysis and Optimization of Standalone Green Microgrids
William Anderson, Kyle Kobold, Oleg Yakimenko
Design of Collaborative Web System: Based on Case Study of PBL Support Systems
Kawai Nobuaki
Case Study of the Roma Tomato Distribution Chain: A Dynamic Interface for an Agricultural Enterprise in Mexico
Ernesto A. Lagarda-Leyva, Manuel A. Valenzuela L., José G. Oshima C., Arnulfo A. Naranjo-Flores
Improvement of Ride Comfort of Turning Electric Vehicle Using Optimal Speed Control
Yingyi Zhou, Tohru Kawabe
An Ontology Model for Systems Engineering Derived from ISO/IEC/IEEE 15288: 2015: Systems and Software Engineering – System Life Cycle Processes
Lan Yang, Kathryn Cormican, Ming Yu
Systems Engineering Management Using Transdisciplinary Quality System Development Lifecycle Model
Mohamed Asaad Abdelrazek, Amir Taher El-Sheikh, M. Zayan, A.M. Elhady
Agent/Group/Role Organizational Model to Simulate an Industrial Control System
Noureddine Seddari, Mohamed Belaoued, Salah Bougueroua
Biotechonomy System Dynamics Modelling: Sustainability of Pellet Production
Andra Blumberga, Armands Gravelsins, Haralds Vigants, Dagnija Blumberga
Parameter Tuning of Complex Systems Modeled in Agent Based Modeling and Simulation
Rabia Korkmaz Tan, Şebnem Bora
Analysis of the Diffusion Behavior of an Information and Communication Technology Platform for City Logistics
Giulio Mangano, Alberto De Marco, Giovanni Zenezini
Generalized Rough Sets Applied to Graphs Related to Urban Problems
Mihai Rebenciuc, Simona Mihaela Bibic
A System Dynamic Based DSS for Ecological Urban Management in Alexandria, Egypt
Mona M. Salem, Khaled S. Al-Hagla, Hany M. Ayad
Register for the conference here
https://waset.org/systemology-and-systems-methodologies-conference-in-october-2020-in-beijing
13.1 VIDEO: PPI Launches A New Course: Interface Engineering and Management (IEM) Two Day Course
“Interfaces are the most common source of problems experienced in system integration. The good news is that most of these problems can be avoided. Learn how with PPI’s new Interface Engineering & Management Two Day or four half-day Course, delivered by Paul Davies, author of “Don’t Panic! The Absolute Beginner’s Guide to Managing Interfaces”.
Abstract:
Every interface is an opportunity to lose information, time, control and/or money through error or contention between stakeholders at each end. There are many issues surrounding interface engineering and management, which are relatively unexplored in the engineering literature. This is surprising, since integration across interfaces is nearly always a source of delays, missing functionality or poor performance in the introduction of new systems.
This course, over two days or four half-days, is simple enough to give anyone with good common sense and a modicum of technical knowledge and engineering practice a clear understanding of how to approach the definition and management of interfaces. Eight best practices are fully explained, and illustrated to give delegates the opportunity to use for themselves. These practices are exploited by leading enterprises, often without formal documentation, to give competitive advantage.
A useful set of templates and guidelines for writing interface specification documents is also included, as “handouts” and as an online resource.
The first course is taking place over four half-days from 2-5 November at:
- Europe UTC +1:00 (CET 15:00)
- United Kingdom UTC +0:00 (GMT 14:00)
- North America UTC -5:00 (EST 9:00)
- North America UTC -7:00 (MST 7:000)
Watch the introductory video where Paul Davies defines sets the scene and explains why we should be concerned about IEM and what you can expect from the course.
Find out more here.
13.2 First Ever INCOSE SEP Exam Prep Workshop 12-16 October
Over the course of five days from 12 – 16 October (3 hours each day) Certification Training International (CTI) will be hosting its first ever workshop dedicated to INCOSE SEP Certification and preparing for the INCOSE Knowledge Exam. The workshop targeted to the Asian region is a compact version of CTI’s flagship INCOSE SEP Exam Prep Course with a mixture of presentation, practical exercises, quiz questions and discussion conducive to adult-learning. Find out more about the workshop or register here.
13.3 PPI Welcomes New Office Support Administrator
Kim is based in New Zealand and has over 20 year’s experience in finance, payroll, office management and administration for small to medium businesses in the public and private sectors including Charities, Not for Profit and NGO’s.
We are pleased to have Kim onboard and we feel that Kim’s rich experience will contribute greatly to the team’s efforts to bring systems engineering to a broader and broader community.
For a full public PPI Live-Online™ training course schedule, please visit https://www.ppi-int.com/ppi-live-online/
For a full public PPI training course schedule, please visit https://www.ppi-int.com/course-schedule/
For a full public CTI Live-Online™ INCOSE SEP Exam Preparation course schedule, please visit https://certificationtraining-int.com/incose-sep-exam-prep-course/
To enquire about CTI Live-Online™ INCOSE SEP Exam Preparation Training for your organization, please visit https://certificationtraining-int.com/on-site-training/
15. Upcoming PPI Participation in Professional Conferences
PPI will be participating physically in the following upcoming events. We support the events that we are sponsoring, and look forward to meeting old friends and making new friends at the events at which we will be exhibiting.
The INCOSE International Workshop 2021
Date: 29 – 31 January, 2021
Location: Seville, Spain (now Virtual)
The INCOSE International Conference 2021
Date: 17 – 21 July, 2021
Location: Honolulu, USA
Kind regards from the PPI SyEN team:
Robert Halligan, Editor-in-Chief, email: rhalligan@ppi-int.com
Ralph Young, Editor, email: ryoung@ppi-int.com
René King, Managing Editor, email: rking@ppi-int.com
Project Performance International
2 Parkgate Drive, Ringwood, Vic 3134 Australia
Tel: +61 3 9876 7345
Fax: +61 3 9876 2664
Tel Brasil: +55 12 9 9780 3490
Tel UK: +44 20 3608 6754
Tel USA: +1 888 772 5174
Tel China: +86 188 5117 2867
Web: www.ppi-int.com
Email: contact@ppi-int.com
Copyright 2012-2020 Project Performance (Australia) Pty Ltd, trading as
Project Performance International
Tell us what you think of PPI SyEN. Email us at syen@ppi-int.info.
-
“The Three-Body Problem” is the name of a science fiction novel by Cixin Liu which traces the efforts of disillusioned Chinese scientists who implore alien life to come to Earth to forcibly redeem humanity. ↑
-
The term “fault” is used here instead of “failure” as it refers to the high level consequence observed on entity level. ↑
-
The OR gate is a digital logic gate that implements logical disjunction. A HIGH (TRUE) output results if one or both the inputs to the gate are HIGH (TRUE). If neither input is high, a LOW (FALSE) output results. ↑
-
A lakh is unit in the Indian numbering system equal to one hundred thousand ↑
