Systems Engineering Life Cycle Research Articles

Measuring the Uncertainty Impacts During the Systems Engineering Lifecycle

AbstractUncertainty is a large part of the Systems Engineering (SE) development process. Particularly absent is the quantification of uncertainty of the threat, operating environment, and friendly force factors at each step of this lifecycle. This paper will explore a methodology to quantify the amount of uncertainty and the interdependencies of the uncertainty factors during the development. Included for consideration are internal and external factors and their contribution to the overall system uncertainty. An illustrative example is provided to exercise this methodology.

Implementation of Human System Integration (HSI) and ‘Non-functional Characteristics’ into the Systems Engineering Lifecycle - A Practical Approach at Airbus Defence and Space

This paper provides an overview of the process, practices, developments and synergies that Airbus Defence and Space are implementing Human System Integration (HSI) into the Continuous Engineering /Model Based System Engineering (MBSE) throughout the company. The paper highlights these developments, which include internal research programmes, European Union funded research projects, Airbus internal Synergy project. This research includes an EU funded 3 year project HoliDes - Holistic Human Factors and System Design of Adaptive Cooperative Human Machine Systems. Continuous engineering within Airbus has included various corporate and divisional Synergy programs and lean and agile initiatives. As our business is defined by Multiple Portfolio products, supplied from multi countries, the MBSE process had to speed up delivery and reduce overall cost. The Airbus process models needed significant amendment due to products supplied via multiple business lines throughout the company. This problem is exacerbated by varying requirements of four national defence requirements, who impose restrictions on the use of Architectural Frameworks (NAF/MODAF/DODAF) and supporting tools. Our Human System Integration (HSI) is continuing from the initial Human View Architectural Framework research to include the nine HSI domains. These nine domains overlap with our current Human factors research and will now allow us to pull in our Non-functional work into our Systems Engineering lifecycle. This paper highlights the research projects Airbus Space and Defence are incorporating in to our overall strategy, these include internal R&D funding and European Union funded research programs. These research projects have highlighted several areas of interest these include, stochastic modelling with respect to Human System Integration and Human views, verification and analysis of emergent behaviour and non-functional properties, which conforms with our own work on non-functional requirements and finally the use of System of System Formal Methods for parts of the lifecycle.

A Framework for Implementing Systems Engineering Leading Indicators for Technical Reviews and Audits

Abstract This paper proposes a framework for implementing systems engineering measures at technical reviews and audits that expand upon the International Council on Systems Engineering (INCOSE) set of systems engineering leading indicators. Premature transition through key decision gates is likely to lead to cost and schedule overruns. Risks to a program can be monitored by measuring key systems engineering measures in the development of products. Decision makers need to assess uncertainty in a program's ability to meet cost, schedule and technical performance requirements at key milestones throughout the systems engineering life cycle. The paper seeks to improve and expand on the existing INCOSE systems engineering leading indicators that are significant predictors of program performance. Correlation between a set of leading indicators and technical reviews to support successful program performance is evaluated. Further research is planned to improve systems engineering by providing examples of performance measurement benchmarks that could aid technical reviews and decision gate analysis.

Assisted Assignment of Automotive Safety Requirements

ISO 26262, a functional-safety standard, uses Automotive Safety Integrity Levels (ASILs) to assign safety requirements to automotive-system elements. System designers initially assign ASILs to system-level hazards and then allocate them to elements of the refined system architecture. Through ASIL decomposition, designers can divide a function’s safety requirements among multiple components. However, in practice, manual ASIL decomposition is difficult and produces varying results. To overcome this problem, a new tool automates ASIL allocation and decomposition. It supports the system and software engineering life cycle by enabling users to efficiently allocate safety requirements regarding systematic failures in the design of critical embedded computer systems. The tool is applicable to industries with a similar concept of safety integrity levels.

1.2.1 Combating Uncertainty in the Workflow of Systems Engineering Projects

AbstractThroughout the Systems Engineering Lifecycle events require personnel, systems, equipment, facilities and information to converge on time and at the right place in order to achieve a program objective. Unpredictability in any predecessor event can mean unpredictability for the overall project. The Last Planner is a production and planning method initially deployed in 1992 in the building construction industry as part of an effort to reduce work flow variability and improve production efficiency in the construction industry. The two key elements of the Last Planner are (1) a change in project management from a task‐oriented to a work‐flow oriented model and (2) processes to improve reliability of the workflow within the team or group performing the work. This paper examines the systems engineering lifecycle as a production lifecycle and explores the application of key elements of the Last Planner as a tool for system engineers to address uncertainty and unpredictability in the execution of a project.

Announcing a Name Change and New Scope

our transaction���s name has changed - from IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART B: CYBERNETICS to a more concise Transactions on Cybernetics (TCyb). For the past many months, the publications of the IEEE Systems, Man, and Cybernetics Society (SMCS) have been undergoing a major reorganization. The reorganization was based on numerous discussions with the SMCS membership and positive feedback that were received and on recommendations from the 2006 IEEE Periodicals Review. In November 2011, the IEEE Technical Activities Board approved the name and scope changes of all three transactions: 1) IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART A: SYSTEMS AND HUMANS to IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS; 2) IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS to IEEE TRANSACTIONS ON HUMAN���MACHINE SYSTEMS; and 3) this transaction. The realignment of the three transactions is meant to help better situate research topics, areas, and articles for the society through its publications. Here are the associated scopes for the three transactions. IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS - The scope of the IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS: SYSTEMS includes the fields of systems engineering. It includes issue formulation, analysis and modeling, decision making, and issue interpretation for any of the systems engineering life cycle phases associated with the definition, development, and deployment of large systems. In addition, it includes systems management, systems engineering processes, and a variety of systems engineering methods such as optimization, modeling, and simulation. IEEE TRANSACTIONS ON CYBERNETICS - The scope of IEEE TCyb includes computational approaches to the field of cybernetics. Specifically, the transactions welcomes papers on communication and control across machines or between machine, human, and organizations. The scope of TCyb includes areas such as computational intelligence, computer vision, neural networks, genetic algorithms, machine learning, fuzzy systems, cognitive systems, decision making, and robotics, to the extent that they contribute to the theme of cybernetics or demonstrate an application of cybernetics principles. IEEE TRANSACTIONS ON HUMAN���MACHINE SYSTEMS - The scope of the IEEE TRANSACTIONS ON HUMAN-MACHINE SYSTEMS includes the fields of human machine systems. It covers human systems and human organizational interactions, including cognitive ergonomics, system test and evaluation, and human information processing concerns in systems and organizations.

Developing an Interactive Intervention Planner - A Systems Engineering Perspective

Intervention planning is crucial for maintenance operations in particle accelerator environments with ionizing radiation, during which the radiation dose received by maintenance workers should be reduced to a minimum. In this context, we discuss the development of a new software tool and the entailed methodology, including the visualization aspects. The software tool integrates interactive exploration of a scene depicting an accelerator facility augmented with residual radiation level simulations, with the visualization of intervention data such as the followed trajectory and maintenance tasks. Its conception allows for future inclusion of measurements performed by mobile robotic devices. In this work, we explore the systems engineering life cycle of the development process of an interactive intervention planner, which includes the needs analysis, specification explicitation, conceptual mathematical modelling, iterative implementation, design and prototype testing and usability testing.

6.4.1 Tailoring the Systems Engineering Life Cycles: Goal Oriented Engineering Phasing

AbstractAll too often engineering products are created ‘because we always do so’. Projects phases are introduced without questioning the utility, designs are being detailed without connecting to the decision process, or the preliminary research is badly matching the designers' needs. So, a big part of the systems engineers role is not only the engineering itself, but matching the engineering process with the project at hand and the goals that must be fulfilled at each design stage. In this paper, we will discuss the tailoring of the typical System Engineering life cycle and project stages onto the life cycle processes of a project at ProRail, the Dutch railway infrastructure provider. ProRail is a major government procurement organization, with revenues of over € 2,000,000,000. Typical projects range from € 100,000 to over € 100,000,000. ProRail has a large legacy system deployed, dating back over 150 years to the first railways in The Netherlands.

9.2.1 Reference Framework and Model for Integration of Risk Management in Agile Systems Engineering Lifecycle of the Defense Acquisition Management Framework

AbstractRisk management is a requirement for success of any enterprise. Despite this fact, there have been limited solutions for integrating risk management in agile life cycles. On average, 70% of all IT‐related projects fail to meet their objectives which have caused 80% of companies to reassess their process. One of these processes includes risk management where studies have shown that risks should be assessed in all dimensions of a program. We found that risk management was being conducted on the overall program with concentration in the software development phase which leaves other life cycle phases with no risk assessments and mitigation strategies. Agile systems engineering is more complex than traditional systems engineering due to events happening concurrently and non‐sequentially during the life cycle of a program. This paper will propose a framework and model for risk ‘managility’, management in an agile environment, specifically in systems engineering life cycle. We use the Department of Defense's Evolutionary Acquisition and Management Framework as a bridge to define and illustrate an agile systems engineering life cycle (ASEL) framework and an agile risk integrated engineering lifecycle (ARIEL) model.

A system maturity index for the systems engineering life cycle

In the United States (USA) National Aeronautics and Space Administration (NASA) and the USA Department of Defense (DoD) the Technology Readiness Level (TRL) scale is a measure of maturity of an individual technology, with a view towards operational use in a system context. A comprehensive set of concerns becomes relevant when this metric is abstracted from an individual technology to a system context. This paper proposes the development of a system-focused approach for managing system development and making effective and efficient decisions during a systems engineering life cycle. This paper presents a System Readiness Level (SRL) index that incorporates both the current TRL scale and an Integration Readiness Level (IRL) and provides a method for determining readiness of a system in the systems engineering life cycle. This paper concludes with a general discuss of the implication of the proposed SRL and how this may be applied to four case

Enterprise modelling and Ontology

Generally speaking, Enterprise model is used during the system engineering life cycle by other stakeholders rather than those who developed it. They do not necessarily know the context in which the model was built and quite often are not familiar with the language used for the modelling. This situation makes that the model loses its semantic during its exploitation and creates ambiguities and difficulties in its use.We will propose in this paper a methodological approach to be followed in the creation of models which would make it possible to keep their semantics during their life cycle by the use of ontologies and semantic annotations. A simplified application example is presented to illustrate the use of the proposed approach.

Comment: Expert Elicitation for Reliable System Design

This article successfully identifies and addresses some of the most important challenges in the use of elicitation as part of engineered systems analysis. The authors make two key advances to the field. The first is that they perform an exhaustive synthesis of the probability elicitation literature relevant to the engineered systems context. The second advance to the field offered by this paper is that it reframes the elicitation literature around the limits, possibilities and actual constraints posed by systems engineering practice. This latter point is no small contribution—the authors have successfully opened a much needed discussion as to why system elicitation differs fundamentally from cultural ethnography methods, and why risk estimation and “systems ethnography” (elicitation of system dependencies and evolving uncertainties) are only partially informed by methods developed for identified and stable single distribution elicitation. I like the overview of the systems engineering (SE) life cycle and the link made to reliability through the r = r(d, p,u,m, c) relationship. In a follow-up paper or discussion it would be interesting to learn more about the types of systems the authors have studied. In thinking about how to elicit system information over a complete range of engineering efforts, it quickly becomes apparent how hard it is to characterize the elicitation effort (and why this article is such a notable exception to the general lack of disciplined study of this qualitative field). Because the elicitation problem varies greatly depending on the specific form of a technical system, as well as local analytic and decision-making realities, perhaps

7.2.3 Tailoring Systems Engineering Lifecycle Processes to meet the challenges of Project and Programme applications

AbstractThe application of Systems Engineering to real world problems relies upon an understanding of lifecycle and process. Many attempts have been made to produce generic models of Systems Engineering process, which can then be applied to real world problems. More recent Systems Engineering (e.g. ISO/IEC 15288 and ANSI/EIA 632) standards have taken a more abstract approach. The standards describe a lifecycle and process framework, and give guidance on how to tailor the framework to specific problems. This paper explores the approach taken by the standards to describe Systems Engineering in this way. The difference between a project and a programme are defined; and the application of lifecycle tailoring to each is discussed. Finally, a generic lifecycle framework is described, and examples of its application given.

7.1.2 Similarity Workshops as a Project Initiation Tool

AbstractThis paper discusses the theory and initial results of the application of the ideas regarding ‘similarity’ introduced by Verma (Verma 1998) as a means of improving ‘left shift’ in the Systems Engineering lifecycle at BAE SYSTEMS. In particular, it concentrates upon the practical application of these ideas in a real world environment.

Some Systems Engineering Considerations for e‐Commerce Projects

AbstractThis article summarizes selected aspects of applying a Systems Engineering Life Cycle framework for the successful implementation of an electronic commerce (e‐commerce) web site development project. Emphasis is on articulating a variety of need, requirement, and implementation issues that typically need to be addressed in e‐commerce development projects.

3.5.3 Systems Engineering Framework for Deploying eCommerce Websites

AbstractThe more recent rise of the World Wide Web (WWW), driven by corporate acceptance and adoption, has revolutionised a new age of doing business. Companies of all types and sizes are faced with doing business via Internet or face the risk of going out of business. This has led to an exponential growth in eCommerce (Electronic Commerce) using integrated communications and electronic data interchange (EDI) technologies.This paper describes a Systems Engineering Life Cycle framework for the successful implementation of eCommerce application project. A methodology followed is based on systems engineering principles to ensure that eCommerce requirements are understood and designed properly. The highlights in support of this title include: Emphasis on eCommerce application needs analysis; Understand systems engineering framework to design, implement and maintain eCommerce applications; Understand how eCommerce technologies can be applied to achieve competitive advantage by transforming relationships with customers, suppliers and business partners.

2 Design Integration “Testing” from Concept to Support

AbstractThe value of modelling and design prototyping in the early phases of the systems engineering life cycle is well understood, as is the use of specialist test facilities for design verification during development and to confirm system behaviour and performance prior to delivery. This paper identifies that significant business advantage can be gained through the integration of these various design evaluation activities. The use of an integrated test and evaluation strategy, supported by a model integration environment, is proposed as a means of achieving this objective. The key concept discussed is that of a “virtual” rig.

5.6.3 The Systems Engineering Life‐Cycle Process Functional Working Group A Government / Industrial Partnership

ABSTRACTThe Department of Defense (DoD) has recognized the relationship between good systems engineering and products that meet the customers' needs. The DoD Joint Logistics Commanders (JLC) Joint Group on Systems Engineering (JGSE) has commissioned a new functional working group called, Systems Engineering Life Cycle Process (SELCP). In July, SELCP sponsored a Systems Engineering Workshop in San Diego. The attendees were experts in systems and software engineering from industry, academia, INCOSE, IEEE and government. The issues associated with this new paradigm were discussed, a forward action plan was developed and expectations for continued cooperation were assured.This paper will describe the motivations that led to renewed government interest in systems engineering, the results of the San Diego Workshop and future plans for SELCP to collaborate with INCOSE and other industrial organizations. Joint meetings have been held with several working groups of INCOSE and plans are in place for collaboration on new systems engineering products. This cooperation between government and industry will help to ensure high‐quality products that meet customer requirements and expectations.

SYSTEM ENGINEERING CONCEPT DEMONSTRATION (SECD) PROCESS MODEL

AbstractThis technical paper will present a summary of the SECD Process Model Task sponsored by Rome Laboratory at Griffiss Air Force Base, New York. An introduction to the SECD Program is presented in the “SECD ‐ Overview” [LaMonica 1992]. The SECD Process Model is a system acquisition and development model with emphasis on system engineering activities over the entire system life cycle. The Process Model is a graphical and textual representation of the system engineering life cycle activities, agents, flows, feedbacks, and work products. This interactive Process Model provides a multidimensional view of government acquisition and contractor development activities. In the context of the SECD Program, the Process Model validates the System /Segment Specification (SSS) requirements and demonstrates coverage and completeness of the system engineering process.