Systems Engineering Quick Check

<div class="htmlview paragraph">A major focus of many implementation discussions on Systems Engineering revolves around developing a large database of information, to be reused later, benefiting the company's product development process. Business needs for agile and flexible responses place pressure on the maintenance of the database during Sustaining Engineering of the product. The business needs of the product management functions are discussed to frame the problem of maintaining the Systems Engineering database. This paper focuses on the maintenance of the Systems Engineering database during Sustaining Engineering activities. The process for ensuring the ‘Systems Engineering Documentation Set’ is being kept current is analyzed and described. Experiences regarding the dynamics of a Matrix Organization for Sustaining Engineering are discussed.</div>

Combining REACH, environmental and economic performance indicators for strategic sustainable product development

Information systems development projects are a significant expenditure of time, effort and money for many enterprises. Historically it has been estimated that 50-80% of projects fail to achieve their objectives for a variety of reasons. Researchers have identified numerous factors associated with system development failure. In this paper, we first synthesize the vast research regarding systems development risk factors and provide a framework that illustrates interactions between risk factors. The framework was used to develop an open-ended questionnaire that was answered by an inter-industry group of experienced systems development engineers and project managers. Analysis of their reports indicates that experienced professionals perceive that all risk factors (technical, resource, etc.) ultimately derive from organizationally-oriented factors, to be solved with organizational responses. This holistic viewpoint of risk assessment is counter to that of systems professionals more involved in day-to-day development decision making. For these developers, risks are more likely to be characterized as fitting into traditional discrete categories. This apparent dichotomy of risk importance was further investigated through an intra-organizational study which directly assessed how professionals recognize and treat risks in the development process. Results illustrate that a successful project environment may be characterised as one in which all systems professionals maintain a holistic view of organizational risk and that organizational culture, as opposed to experience, may predicate such an environment. Implications and future research directions are discussed.

The new product development (NPD) is considered an important business process to determine the competitive advantage of companies. In order to launch products successfully, methods and tools have been applied by companies for improving and supporting the activities performed in that process. However, a comprehensive and integrative classification of new product development methods and tools is not clear. Beyond that, regarding how useful the practitioners consider the methods and tools, the adoption, diffusion and application dimensions of them are still research challenges. To address these issues, the aim of this research is to present a classification of methods and tools, besides to present which of them are really applied and useful in new product development of companies. The novelty of this proposal involves the practical perspective encompassing the practitioner's point of view, which goes beyond the theoretical perspective. Methods and tools identified by means of literature review were classified using a qualitative approach. The classification was validated by practitioners of ten companies specialized in product development. Key findings of the classification proposed are presented based on the following categories: performance objective related, added value, complexity and implementation cost. Finally, the research provides an overview of the usefulness and attractiveness of methods and tools. It can support a valuable guidance for companies in order to improve the use of the most useful ones.

Problems in the interplay of development and IT operations in system development projects: A Delphi study of Norwegian IT experts

The Relationship between Product Characteristics, Customer and Supplier Involvement and New Product Development

The following case study evaluates the New Product Development (NPD) techniques utilized by Forest City Technologies, Incorporated (FCT). Through insight gathered via interviews conducted with the company's product development and materials purchasing management teams, and supported by literature, this study attempts to show how Forest City Technologies, Inc. integrates specific components into its product development process to: 1. Meet its NPD goals, and 2. Achieve better supplier and customer relationships. This study focuses on the components of: NPD models employed by FCT, early customer and supplier involvement, NPD-innovation integration techniques, demand change factors during the NPD process, and risk-mitigation strategies implemented by FCT during the NPD process. The study is segmented into three main sections: Introduction to NPD and FCT, the components of FCTs new product development process, and NPD implications on FCTs supplier and customer relationships.

With the ongoing development of autonomous systems, significant attention has focused on deploying autonomous robotic systems to complete a task under human supervision. An important pillar of this interaction is a notion of human trust in the autonomous system, however the modeling of trust in such scenarios has been hampered by the lack of a standard open-access dataset with longitudinal measurements of trust. By recording measurements of trust at a single point in time (often at the end of interactions), these datasets do not capture the temporal dynamics of trust over the course of interactions. We propose to address these challenges with a novel multi-modal dataset that aggregates autonomous system status and task performance, self-reported human trust, and human interventions in the autonomous system during interactions. We collect the data using a software-based interface that simulates a swarm of autonomous robotic agents performing a foraging task in a rectangular area. By recording metrics pertaining to the autonomous robotic swarm’s task performance and human trust, the dataset provides a foundation for the modeling of human trust dynamics and their influence on human interventions. In addition, the dataset’s inclusion of timestamped human responses to a secondary task permits analysis of human attention allocation between tasks over time. It is anticipated that the dataset will provide a benchmark for human trust models, facilitating the development of more trust-aware autonomous robotic systems. IEEE SOCIETY/COUNCIL Robotics and Automation Society (RAS).

Surveying the current state of practice of spacecraft autonomy, one can detect many different attributes of the various autonomy systems currently employed to maintain the safety of the spacecraft. In an effort to move beyond the state of practice, Johns Hopkins University Applied Physics Lab has focused on three of these attributes not found together in current systems: Understandability, Flexibility and Verifiability. Understandability defines the ability to specify and review the autonomy system in such a way that any nonsoftware domain expert or system engineer can understand the design. Flexibility defines the ability to modify the design preand post-launch in parts without patching or without complete code uploads. Verifiability defines the ability to exhaustively and rapidly verify correct autonomy system behavior before it is uploaded to the spacecraft. With the goal of attaining all three of these attributes, JHU/APL has designed and developed a new autonomy system called ExecSpec (short for Executable Specification). The system has been progressed to TRL 5 and is now poised for infusion into future spacecraft programs. ExecSpec is a new visual programming approach to autonomy system development that enables any system designer or domain expert to visually create spacecraft functionality and autonomous behavior in the form of up-loadable specification diagrams. ExecSpec allows developers to interactively construct autonomy systems by drawing diagrams of individual Finite State Machines (FSM) and linking them together to form autonomy components and subsystems. The diagram components are easily understandable by non-software domain experts and system engineers, allowing for system-level review of the autonomy system design. The diagram components can either be built from scratch, or instantiated from libraries of reusable FSM components. In contrast to current software capabilities, ExecSpec is not a code generator but rather an interpreter-based system which enables the uploading diagrams directly to an on-board FSM execution engine, allowing the autonomy system to be rapidly and safely modified at any time in a project's lifecycle and thus reducing overall lifecycle and maintenance costs. This makes the system inherently flexible to post launch modifications and enables changes on the individual FSM level such that new FSM diagrams can be added or interchanged. The resulting diagram behavior produced by ExecSpec can be tested directly through interactive stimulation of system inputs or by playing back scripted input scenarios. Model checking tools can also be used to rapidly verify that the diagrams obey specified constraints and requirements, and the uploaded system behavior can be visually monitored during flight. This combination of interactive testing, model checking and in-flight monitoring ensures autonomy systems built within ExecSpec can be exhaustively verified in a rapid manner. This paper will describe in detail the three attributes chosen by JHU/APL, including the driving need for each, then go on to describe how the new ExecSpec system meets these attributes. Finally, the paper will describe the current state of the ExecSpec development and plans for infusion into future spacecraft systems.

One of the few things certain about development of complex systems is the requirements for the system will remain uncertain late into the development program. Even though we recognize this, why do many programs assume that requirements will not change (gambling) or treat requirement change as a risk rather than a certainty? An analysis of gas turbine engine control systems requirements shows that typically 50% will change between Critical Design Review and Entry into Service. This requirements uncertainty manifests as technical risk to the programme. This paper evaluates the impact of not managing these uncertainties and describes how applying Systems Engineering principles can reduce this effect.Design iterations produce rework, and without technical risk management, ~50% of the effort will be wasted in producing unacceptable designs. In turn, correction of these errors will create more rework. This results in much iteration and cumulatively twice as much work is required to produce a mature design. With technical risk management, less than 10% of the design effort will result in rework, giving a mature product with far less iteration.Investigation into the source of the product development lifecycle problems indicates many escapes occur during requirements definition and review. Around twice as many changes are driven by errors in requirement definition by the developer, compared to customer‐driven requirements changes. In addition, many of these escapes are detected later in the product development lifecycle than they could have been found, resulting in further escalation of the cost of product development. This paper compares and contrasts the root causes for these escapes during system, software and hardware development and looks at the differences in consequences.The role of the Systems Engineer is critical in addressing these problems. In addition to effective elicitation of requirements from stakeholders, the Systems Engineer must manage volatility and apply robust design principles to protect against the impact of requirements changes. The Systems Engineer must flow requirements effectively from system to sub‐system, from sub‐systems to components and provide the “glue” that results in the integrated system being more than the sum of its parts.Some tools and techniques are presented to help Systems Engineers identify probable sources of uncertainty and provide effective mitigations. An approach is also presented for assessing the technical risk management “maturity” of a project, based upon ‘best practice’ approaches taken from those projects achieving low levels of engineering scrap and rework during their development phase.

A-dec Inc. is a dental equipment manufacturer headquartered in Newberg, Oregon. A-dec implemented an innovative product development process to support the launch of a new product line. The change in process motivated the A-dec Marketing Communications team to address how to align their process with the company's product development direction. The group decided to focus on content. They faced the challenge of how to control and manage content, which started their education in the area of content management and content management systems. This ongoing case study discusses their journey towards implementing a content management system. Located in Vancouver, BC, Intentional Design Inc. is a technical communication consultancy focused on improving the performance of communication products. The strength of the organization lies in the wildbrain approach (see Dale Dauten's The Gifted Boss) to performance improvement and its impact on the solutions provided to clients.

The product reliability program was initiated to verify that the product being rushed into production is ready. That it has been through a process of analysis, testing and documentation aimed at assuring the success of the product meeting company's goals for reliability: that it will perform its functions successfully for a long time with high confidence, at a reasonable cost of ownership, and in an acceptable time to market. What is reliability, and why is it important? It differs from product quality, in that the quality program is aimed at building the best product that meets design, while reliability aims to see that the product quality is met throughout the life of the product (or some period of time). Reliability is defined as the probability that a product will operate for some period of time, under stated conditions and with a given level of confidence. Why is reliability important? If we are lacking in quality or reliability, we will have unacceptable DOAs (Dead On Arrivals) or product returns, which directly impact the bottom line (profits). Time to Market for a new design in a new market is of utmost importance, but if the products don't work, the reputation of the product and the company will suffer; consequences of this may far outweigh other financial or time to market achievements. Market pressures are forcing companies to produce products with higher reliability. How do we implement a reliability program? This will depend upon the company organizational make-up, the level of experience of the employee's in reliability, and the market demands for reliability. It would of course help to have employees experienced in reliability, but if the company lacks such skill sets, outside consultants can be brought in to give some guidance. But these consultants need to be immersed into the company's product development process and tasked with the documentation of the reliability process and training for engineers and managers. Why is there resistance to a reliability program ? The company culture is probably built on a history of product development cycles, possibly from years previous when market demands for reliability were not nearly so demanding. Also, many of the tools in reliability are built on statistics and require some skills in understanding. Reliability tools also involve testing products at stress levels beyond the product specification, and the design engineers may find this difficult to accept. In this paper, we will examine reliability engineering tools and the reliability process, and how to introduce them to a company. We will look at what elements are needed in order to create a corporate culture that supports the reliability program implementation. We will discuss some strategies on how to generate support for this reliability program. We will discuss an example in which the product is highly customized, and sold in low volume. Each product sold is based on specific requirements from the customer, and is designed to fit into the specific application from that customer. A given product would not be sold to other customers.

Systems development has often resulted as a hit-or-miss proposition before the advent of standardized analysis and design languages providing blueprints understood by both software and systems engineers. This paved the way for modeling cyber-physical systems using established, yet evolving standardized notation widely accepted by industry. In the past, system analysts would try to assess the needs of their clients, generate a requirements analysis in some notation that the analyst understood (but not always the client), give that analysis to a programmer or team of programmers, and hope that the final product was the system the client wanted (Schmuller, 2003). However, advances in UML and SysML have created new pathways to the design process when combined with Concurrent Object Modeling and Architectural Design Method (COMET) methodology that can assist in the realm of complex embedded system design for next generation cyber-physical systems (Rajhans, 2009). In order for product development to meet a desired need, communicating the vision to the developers is of utmost importance. The UML is a visual modeling language that enables system builders to create blueprints that capture their design intentions in a standardized format for effective communication of engineering detail. The paper reviews some key benefits of using UML and SysML during the product development process with COMET. The UML process steps are briefly described, followed by an introduction to the SysML language which is an extension of the UML. The paper provides a process review of embedded system development using SysML for systems engineering that can be useful for modeling aspects of cyber-physical system development during integrated product development. Realizing the fact that SysML may be considered too generic to address embedded and real-time system design, the paper provides a brief review of COMET, a UML based method for the development of concurrent applications, in particular distributed and real-time applications (Gomaa, 2008). The Artificial Intelligence Design Framework introduced as part of the thesis work supported by NASA (Tanik, 2006) can be adapted to cyber-physical system design. The published book detailing the AIDF called Architecting Automated Design Systems is based on this thesis work (Tanik, 2008) and is being used as a basis for supporting cyber-physical system design using artificial intelligence decision support with many application areas, including complex safety-critical medical and space systems design. This journal paper establishes the link between the conference paper on integrated product development (Tanik, 2010), and the previous work on the PhD thesis completed in 2006 that relates to cyber-physical system design frameworks.

This paper is a comparative study of two system development projects as a contribution to the demand for evidence of the benefits of Systems Engineering.The treatment is qualitative, but the similarities of the two systems concerned allow useful conclusions to be drawn. The projects were carried out by the same enterprise, used common subcontractors, were developed on similar technical infrastructure and were developed for the same end user. Both projects claimed to be applying Systems Engineering, however the very different outcomes conform to the old adage that says, ‘it ain't what you do, it's the way that you do it – that's what gets results‘,Both projects experienced the usual trials and tribulations that accompany engineering developments, however one system was accepted and delivered whilst the other ran significantly over‐budget and over time. This system was never delivered. The seeds of the problems that afflicted the unsuccessful project could be observed very early in the programme, and had they been addressed the outcome could have been different. The paper helps to support the hypothesis that intelligent use of SE can ensure project success.Projects may claim to use SE without actually delivering a good result. The paper addresses this problem by indicating some common sense observations that can identify weak or ineffectual SE practices.Not surprisingly the identity of the projects is not revealed, and in some cases details have been deliberately altered to ensure anonymity.

Systems engineering is a transdisciplinary scientific and applied direction that combines the principles of a systems approach, methods, tools and standards that provide an integrated methodology and relevant technologies for the design and development of complex systems, their comprehensive analysis and verification, efficient and safe use. The modern approach to systems engineering is characterized by an accentuated modeling of systems throughout their life cycle with the ultimate goal of creating their digital twins. It is called model-based systems engineering (MBSE). Consistent integration of MBSE with software engineering leads to the formation of the MBSSE (Model-Based Systems and Software Engineering) direction. This textbook is devoted to this area, the main objective of which is to study the conceptual and scientific-methodological foundations of MBSE and MBSSE, models and methods of life cycle management of systems and software, basic standards of systems engineering, study and mastery of the UML and SysML systems modeling languages and the corresponding modeling tools, study of requirements engineering methods and development of a description of the system architecture, familiarization with the concept of digital twins and their role in MBSE, study of the MBSSE reference model and its relationship with the process standards of systems engineering, study of the methodological aspects of the system and software integration process. The final chapter of the textbook is devoted to the study of the mathematical foundations of systems engineering. The main aspects of the mathematical theory of systems by A. Wayne Wymore, which became an important stimulus for the development of the model-oriented approach in systems engineering, and modern research, including the apparatus of finite automata by David Harel, the formalism of modeling of discrete systems DEVS, research into category theory as a formal mathematical basis for model-based system design are considered. The authors recommend this course as a basic course for training IT professionals.