Systems Engineering Practices Research Articles

Realizing the Value of Systems Engineering

AbstractLessons learnt / observations from the implementation of Systems Engineering into organizations and development of product are presented, which show Systems Engineering to be a valuable and insightful approach to the practice of Engineering. The value comes from the Systems Engineering focus on seeing the whole, complete requirements, top down architecture, and enabling understanding / recognition of issues. The Systems Engineering approach improves the probability of success in complicated and complex situations. The approach is generic, and is able to provide ubiquitous value across a range of domains. Examples of its application are given from range of aerospace; land (products and infrastructure) and sea demonstrate how this value can be achieved.However application of Systems Engineering is not universally common, and there are a great many difficulties implementing it into an organization. Some of the problems experienced in trying to implement Systems Engineering are shared, and advice offered to Systems Advocates in a range of domains trying to implement Systems Engineering. Further, there are issues that INCOSE must address to help it achieve its vision to be “the world's authority on Systems Engineering”, and for the successful spread of Systems Engineering practice.

Systems Engineering Challenges in Simulation Based Aviation Training: A Few Insights

AbstractSimulation based training means using simulated environment to create training lessons, more focused towards interactive learning by simulating real world scenarios. Simulation based training has been used extensively in the field of aviation for many years. Flight simulator as a product is quite complex and all the lifecycle phases such as requirements, analysis, design, development, integration, verification and validation are not very well interconnected or centralized, which adds to complexity in producing an artefact in a complex system of systems environment. Moreover, the lack of integrated method for ensuring the traceability of requirements and customization, acquisition of knowledge and data, integration and changes in hardware, and the design and testing of software creates massive challenges for simulation companies developing system of systems products. The current paper provides insights into such challenges that typically exist in the Flight Simulation industry. Methods and techniques inspired from the Knowledge Based Engineering (KBE) and Model Based Systems Engineering (MBSE) aspects of Systems Engineering are proposed to evolve existing Systems Engineering practices for more efficient Requirements Management, Interface & Change propagation management and Hardware and Software integration solutions. Towards the end, results of an industry‐wide survey have been summarized, which was initiated to gather feedback from industry experts on various systems engineering practices challenges.

SYSTEMS THEORY AS A CONCEPTUAL FOUNDATION FOR SYSTEM OF SYSTEMS ENGINEERING

ABSTRACTSystems theory (ST) can provide the developing systems of systems engineering (SoSE) field and practice with a strong conceptual foundation. ST is presented as a taken for granted set of axioms and corresponding propositions that explain the phenomena, patterns, and tendencies of complex systems. The results of ST are observable in the behavior and performance of systems. We argue that ST offers a critical grounding for the future development and practice of SoSE. Our exploration examines the necessity, contributions, and implications of ST as an influential conceptual foundation to accelerate and guide SoSE development and practice.

THE SYSTEM OF SYSTEMS APPROACH (SOSA)

ABSTRACTThere are number of ways in which organisations have chosen to manage their system of systems (SoS) which suits their business environment and particular SoS challenges. The system of systems approach (SOSA) is in response to the challenges presented by an increasingly complex capability design, acquisition and operating environment. The SOSA represents the way in which UK Defence applies systems engineering and systems approaches best practice in order to achieve effective and affordable military capability.In view of the need to maximise the agility and flexibility of a smaller armed forces to meet a wide range of possible operational scenarios and commitments, as captured in Defence Strategic Direction 2016. Rather than defining specific SoS requirements to meet a distinct purpose, the MOD has chosen to manage its SoS by maximising the SoS attributes such as interoperability, openness, commonality, reusability and coherence.

An Integral Approach to Risk Management

AbstractINCOSE Vision 2025 identifies risk management as one of Systems Engineering's fundamental challenges, noting that “most major disasters such as Challenger and Columbia have resulted from failure to recognize and deal with risks” (INCOSE, 2014). At last year's INCOSE International Symposium, it was proposed that Integral Theory models could help improve both the theory and practice of systems engineering (Devaney, 2015). In this paper, the potential benefits of applying Integral Theory models to risk management are explored.

Defensibility: Legal Liabilities of Acts and Omissions in the Practice of Systems Engineering

AbstractSystems Engineers assigned to projects spend a majority of their time on technical and technical management processes. In order to produce balanced system solutions, systems engineers rely on specialty engineering activities (informally known as the “ilities” because many of them end in “ilty”) to trade performance requirements with non‐functional requirements (also known as quality attributes). The INCOSE Systems Engineering Handbook Fourth Edition (INCOSE, 2015) lists 14 “ilities” including affordability, reliability, and usability.This paper introduces defensibility, an additional “ility” that attempts to balance the legal aspects of the system and its development effort. Professional legal liabilities stem from two primary sources: acts and omissions. Breaches of acts arise when an activity has been done, but it was done poorly or an improper action was taken based on the situation. Breaches of omissions arise when an activity was not done that should have reasonably been done under the circumstances. This paper explores both of these liabilities in the context of systems engineering and provides practical advice on how individuals and companies can better protect themselves. This paper is an attempt to show practitioners how defensibility may play a role in their designs and how they may be drawn into the adjudicatory process around disputes over their work or the work of others.

Issues in Conceptual Design and MBSE Successes: Insights from the Model‐Based Conceptual Design Surveys

AbstractThe INCOSE Model‐Based Conceptual Design (MBCD) Working Group was established in 2011 with the purpose of advancing the body of knowledge and practice of systems engineering (SE), through the development and application of model‐based systems engineering (MBSE) methodologies to the concept stage of a system's life‐cycle. The Working Group strives to achieve its vision through a series of activities conducted by members of the working group. One of these activities was to conduct a survey of people involved in MBCD, with the goal: To identify the issues associated with performing Conceptual Design and areas where MBCD has been successful. As part of this activity, two surveys, one in 2014 and one during 2015, have been conducted. This paper begins with an overview of the first survey and the need for a second survey that arose from the possibility of non‐response bias being present in the first survey's results. Following this, the results obtained from the second survey are presented, compared with the results from the first survey and discussed. The key insights the authors uncovered from the results, survey workshops, and symposium presentations on both surveys are also identified. The paper concludes with a discussion on how these results are being used to inform current MBCD WG activities and strategic planning.

Systems Thinking in Systems Engineering

AbstractSystems thinking (ST) offers a holistic approach rather than a reductionist approach, through appreciating all the interrelated dimensions of complex problems. It is important for understanding and interacting with all kinds of systems, in order to manage complex problems. However, the broad range of the ST‐related literature found in various disciplines, generates a great deal of disagreement about definitions and understanding of systems thinking. Despite the current ambiguities of ST definitions, its underlying philosophy has a long history. This paper aims to clarify what ST is in the modern day and why it is defined in so many different ways. It identifies a number of interpretations of systems thinking with the purpose of clarifying what it is and why it is variously understood. The main aims of this paper is to propose a new ST construct, and to define its role in the practice of Systems Engineering (SE). This paper then draws implications of the new ST construct for SE education.

Faster is Better and Cheaper

AbstractA movement with increasing momentum in the software world is DevOps. In DevOps development staff and operations staff work together in one integrated team producing and operating software. DevOps initiatives report shorter cycle times (time to production of features) and less business disruption. Contrary to Agile, DevOps has not been initiated by a small group thought leaders communicating a manifesto. Every company doing DevOps, or wanting to do it, has its own specific definition and approach. In this paper we analyze the DevOps movement to its core values and connect it to documented Systems Engineering knowledge. We show that DevOps (extending (Scaled) Agile) is an improvement movement addressing almost all the Systems Engineering practices. Yet the (re)introduction of System Engineering processes would not provide the same effect because DevOps/Agile adds a strong drive on organizational change management with focus on cultural fit. Where in the past improvement parameters had been quality or (implementation) cost, the improvement parameter now is production speed (cycle time). Improving quality or cost can lead to slowness, focus on speed will increase quality and cost. Where the Agile movement increases speed introducing focus on stakeholder collaboration and small increments of (software) products. DevOps in its ultimate form accelerates the speed introducing a single role owning service accountability and total cost of ownership, thereby providing engineers a central place in the business.

‘Echoes from the Field’ Study Outcome and Discussion: Reflections on Software Systems Engineering Practice.

AbstractTo date, despite that various software development approaches have evolved and demonstrated success, many software development projects still fail. This paper argues that the reason for such failure is the result of not addressing the human‐side of the Software Systems Engineering (SWSE) adequately. Humans are relatively unpredictable components in the larger system of the sociotechnical environment, therefore requires adequate consideration. The study investigated the experience and perception of software engineers for the contemporary practice of SWSE. A suite of multidisciplinary theories was consulted and adapted to broaden the understanding of the role human‐element plays in SWSE, such as the Knowledge Creation Theory (KCT), Toyota Production System (TPS) known as “Lean” and Emotional Intelligence (EI). An overall conclusion is that SWSE is a human‐centric activity, and its success is heavily reliant on the human‐element and its related social dynamics. The findings can help viewing SWSE from a different prospective that could help improving the practice.

Application of Systems Engineering Principles for Concept Design of New Products

A successful engineering design is one that meets the user requirements completely. Design essentially starts with concept design followed by detailed design. The importance of concept design is brought out in this paper. Systems engineering principles and practices are used to build the concept design starting from user requirements and user specified reference scenarios. Systems engineering methodology helps in proper understanding of the user requirements, identifying multiple solutions, short listing the candidate solutions and finally selecting one or two feasible designs. A case study analysis is presented to demonstrate the systems engineering practices followed for concept abstraction and preliminary design of a typical engineering system.

An Architecture‐based Enterprise Planning Process

AbstractThere is a need to augment the traditional enterprise portfolio management process with a more robust process for managing the evolution of enterprise, program and system architectures. These architectures need to evolve towards a desired end state that best meets the needs and concerns of various stakeholders for the enterprise and the extent and variety of systems under its purview. This paper describes a six‐step process for managing architectures under these conditions. It has been implemented at some large government agencies and is based on best practices from government and industry. This process is one of those essential to implementing the relatively new practice of enterprise systems engineering.

Using Systems Engineering Practices for Distributed Control and Building Performance Simulation

AbstractA distributed simulation between control systems and building performance applications is becoming more and more an invaluable tool in the analysis of Automated Buildings (ABs) for better operation and design. Instead of costly and time‐consuming experiments, using distributed simulations can simultaneously fulfill the occupants’ needs while reducing energy consumption and greenhouse gas emissions. Distributed simulations are used to investigate the impact of advanced control systems on building performance applications. This paper describes the development and implementation of a framework for distributed simulations involving different software tools over a network. The main role of this framework is to run‐time couple one or more building performance simulation tool(s) with a control systems environment over a network, within a Building Automation and Control Systems (BACS) architecture. Finally, the paper ends with some conclusions and perspectives for future work.

Systems Engineering Practices Exhibited in the Creation of a Film Original Score

AbstractSystems engineering has been successfully applied to a wide variety of industries, which include defense, space, energy, or transportation. All those systems have in common that they are engineered systems and/or socio‐technical ones. Yet, systems engineering is considered both an art and a science. Therefore, could systems engineering be or have been applied in the domain of art, even if not done explicitly? Being one of the authors of this paper a systems engineer and the other one a music composer, this paper reports on the reflections of mutual discussions about how each of us of carried out our activities in our respective domain. Interestingly, it turns out that engineering a space system and creating a film original score abstractly follow the same set of principles and practices.

Systems engineering beliefs: Contemplating personal perceptions regarding state of the art

Systems engineering (SE) theories and practices for effectively dealing with complex systems are still evolving. Principal stakeholders are integral to complex systems, so we cannot predict or prespecify how the system changes. Every systems engineer has his own professional viewpoint derived from cultural background, upbringing/education and experience/maturation. The author has decided how all this fits his career and current ‘mindsight’. He encourages other systems’ engineers to examine and share their thoughts to help attain a more collective and forward looking view of systems engineering to advance the field. This paper provides a frame work for system engineers to contemplate whether they are of the traditional system of systems; enterprise; or the complex type. Perspectives on SE attributes are offered to assist any systems engineer in characterizing his belief system, stylistic approach, and overall effectiveness in engineering complex systems. Systems engineers might reflect on what applies to them and to what relative extent. If a particular set of attributes dominates, is that appropriate? What changes in outlook, style, and emphasis might make a more effective systems engineer? Several existence categories are suggested and proportioned through each of life’s stages. System engineers may contemplate how these trends have affected their past behaviors, and how possible re-directions might improve their future accomplishments. Thinking through what we have done, are doing, and want to do as systems’ engineers is recommended. Anyone’s chosen way is no better than any other possibility. It depends on a multitude of circumstances in each of our lives.

Systems Engineering in a Context of Systemic Cooperation (SCOOPs): Development and Implications

We present details of the development of a conceptual framework for systems engineering in a context of Systemic Cooperation, henceforth the SCOOPs model, begun at the International Federation for Systems Research (IFSR) ‘Conversation’ held in Linz in 2014. The authors constitute a group convened by the IFSR with joint sponsorship between the International Council on Systems Engineering (INCOSE) Systems Science Working Group (SSWG) and the International Society for the Systems Sciences (ISSS). The 2014 IFSR working group continued with the development of the Systems Praxis Framework (SPF), the product of the previous IFSR conversation in 2012, and focused on a pragmatic framing of Systems Engineering within its wider context. In presenting the details of the development of the SCOOPs model, we review relevant foundational work in addition to the SPF leading to a critical discussion of its implications for the theoretical underpinnings and practice of Systems Engineering. This is not a final articulation of the SCOOPs model, but a report on an important milestone in its ongoing development.

6.3.1 Shifting Decision Perspectives for the System Engineer ‐ Integrating System Security Into the Mix

AbstractSystem Engineering pursues balancing the forces that shape systems. As the basis of modern systems shift from analog technology to digital, the forces that drive how our systems look, feel, function, interact, and deliver value are changing rapidly. To be responsive to these changes, System Engineering needs to consider a “new reality” on the set of decision drivers for modern complex systems. Using transportation as a backdrop and system security as the example of how design considerations are necessarily changing, this paper explores the evolving application of System Engineering principles and practices.

9.3.2 The Use of Models across the Contractual Boundary: Past, Present and Future

AbstractModel‐Based Systems Engineering (MBSE) practices have been gathering momentum for over 20 years and are seen as the future of systems engineering. MBSE formalises the practice of systems engineering through the use of models and its aim is to overcome the limitations inherent in describing complex systems and their development and sustainment using documents. However, certain project practices, in particular the tendering and contracting processes, are still strongly tied to the use of documents. This paper identifies the challenges that need to be addressed to use MBSE across the contractual interface in a competitive tendering environment. The focus is on the transition of models created by the customer (acquirer) during the capability definition phase to the supplier both during the tendering process and through the systems architectural design and development phases. The paper unfolds with a literature survey and then progresses to surface key insights and challenges for the adoption of model‐centric acquisition, looking into the past, present and future from the Australian and Norwegian defence perspectives. This is supplemented through case studies involving the utilisation of RDD‐100 for model‐centric acquisition of Frigates by the Royal Norwegian Navy and through ongoing research by the Australian Defence Science and Technology Organisation, and the Defence and Systems Innovation Centre. The paper concludes with a summary of the achievements to date and the challenges to be addressed in order to enable and foster the widespread adoption of model‐centric tendering and equipment acquisition.

An Investigation of MBSE Practices across the Contractual Boundary

One of the key impediments to the expansion of Model-Based Systems Engineering (MBSE) practice across the lifecycle, particularly in competitive tendering environments, is the continued reliance on documents to define the contractual interface between the acquirer and the supplier. This paper describes the collaborative research project between the University of South Australia (UniSA), the Defence Systems Innovation Centre (DSIC), and the Defence Science Technology Organisation (DSTO) that is investigating the capability of the DSTO Whole-of- System Analytical Framework (WSAF) to supplant contractual documents within the tender process and the degree to which the model passed from acquirer through the contractual interface can be used by the supplier as the basis of their tender response and subsequent systems development. The paper opens with background material and then describes the “learning-by-doing” approach that is being employed. This is followed by a description of methods and tools used to support the design of the tender response and the capture of the design rationale in the same MBSE environment used to capture the project definition. The paper concludes with a discussion section that surfaces the key issues and challenges inherent in utilising this MBSE approach across the contractual boundary and ways that the selected approach could address these.

Bridging the Gap between Cognitive Systems Engineering Analysis, Design and Practice

Cognitive Systems Engineering principles and methods guide analysis and understanding of complex work domains. Taking the CSE analytic findings to the next step, design, is often not clearly specified in process form. Some reasons for a weakly specified and documented CSE analysis-to-design translation process are: (1) variations in work domain, making generalizations difficult; (2) the value of the analyses in relation to the scope of the study – analyses from better funded studies create more value propositions for a client; and (3) practical resource considerations. The panelists share their insights on tackling challenges in translating results from CSE analysis into impactful and practicable designs, and offer solutions and strategies for making effective CSE recommendations for practice.