6,453 research outputs found

    Engineering the System and Technical Integration

    Get PDF
    Approximately 80% of the problems encountered in aerospace systems have been due to a breakdown in technical integration and/or systems engineering. One of the major challenges we face in designing, building, and operating space systems is: how is adequate integration achieved for the systems various functions, parts, and infrastructure? This Contractor Report (CR) deals with part of the problem of how we engineer the total system in order to achieve the best balanced design. We will discuss a key aspect of this question - the principle of Technical Integration and its components, along with management and decision making. The CR will first provide an introduction with a discussion of the Challenges in Space System Design and meeting the challenges. Next is an overview of Engineering the System including Technical Integration. Engineering the System is expanded to include key aspects of the Design Process, Lifecycle Considerations, etc. The basic information and figures used in this CR were presented in a NASA training program for Program and Project Managers Development (PPMD) in classes at Georgia Tech and at Marshall Space Flight Center (MSFC). Many of the principles and illustrations are extracted from the courses we teach for MSFC

    Systems Engineering and Integration for Advanced Life Support System and HST

    Get PDF
    Systems engineering (SE) discipline has revolutionized the way engineers and managers think about solving issues related to design of complex systems: With continued development of state-of-the-art technologies, systems are becoming more complex and therefore, a systematic approach is essential to control and manage their integrated design and development. This complexity is driven from integration issues. In this case, subsystems must interact with one another in order to achieve integration objectives, and also achieve the overall system's required performance. Systems engineering process addresses these issues at multiple levels. It is a technology and management process dedicated to controlling all aspects of system life cycle to assure integration at all levels. The Advanced Integration Matrix (AIM) project serves as the systems engineering and integration function for the Human Support Technology (HST) program. AIM provides means for integrated test facilities and personnel for performance trade studies, analyses, integrated models, test results, and validated requirements of the integration of HST. The goal of AIM is to address systems-level integration issues for exploration missions. It will use an incremental systems integration approach to yield technologies, baselines for further development, and possible breakthrough concepts in the areas of technological and organizational interfaces, total information flow, system wide controls, technical synergism, mission operations protocols and procedures, and human-machine interfaces

    Using Extensible Modeling in Systems Engineering and Architectural Search

    Get PDF
    The system architecting process is the hierarchical reduction of ambiguity associated with user needs and system design. Design allocation, and subsequent integration, implicitly requires a mechanism by which levels of detail can be added and removed from a decision scenario. This paper addresses the idea of engineering model sharing through the concept of vertical and horizontal extensibility as one mechanism by which hierarchical reduction in ambiguity can be facilitated. Extensible modeling introduces a systems architecting approach to the modeling community by identifying model interfaces and carefully decomposing the model domain. While the actual system hardware is not known at the time of initial design, performance sensitivities can be explored and formally communicated back to the system architect by determining membership in a fuzzy performance metric such as an architectural safety factor. This paper uses a notional vehicle mounted wireless communication system to illustrate the importance of considering environmental coupling variables through the use of extensible modeling and illustrates how fuzzy thinking can communicate the sensitivity of a system design

    An Empirical Methodology for Engineering Human Systems Integration

    Get PDF
    The systems engineering technical processes are not sufficiently supported by methods and tools that quantitatively integrate human considerations into early system design. Because of this, engineers must often rely on qualitative judgments or delay critical decisions until late in the system lifecycle. Studies reveal that this is likely to result in cost, schedule, and performance consequences. This dissertation presents a methodology to improve the application of systems engineering technical processes for design. This methodology is mathematically rigorous, is grounded in relevant theory, and applies extant human subjects data to critical systems development challenges. The methodology is expressed in four methods that support early systems engineering activities: a requirements elicitation method, a function allocation method, an input device design method, and a display layout design method. These form a coherent approach to early system development. Each method is separately discussed and demonstrated using a prototypical system development program. In total, this original and significant work has a broad range of systems engineer applicability to improve the engineering of human systems integration

    Improving System Design Through the Integration of Human Systems and Systems Engineering Models

    Get PDF
    The human is a critical aspect of many systems, but frequently there is a failure to properly account for human capabilities and involvement during system design. This inattention results in systems with higher lifecycle costs, decreased user compatibility, and the potential to produce disastrous consequences. This research presents an approach to integrating the human into system models by using two methods: static and dynamic modeling. The static method uses a user-centered design framework to create system- and human-centered models that deconstruct the system and user into their respective components. These models are integrated to create system models that include relevant information about the human and highlight potentially conflicting tasks. The dynamic method uses a human performance modeling tool to create a discrete event simulation (DES) of the system. This DES model is used to perform an analysis between system trades, by which constraints and assumptions placed on the human are verified. Data gained from the analysis are integrated back into system models in order to reflect true system performance. By applying these two integration methods early in the system’s lifecycle, system models can more effectively account for the human as a critical component of the system, thus improving system design

    Pattern-Based Systems Engineering (PBSE) - Product lifecycle Management (PLM) integration and validation

    Get PDF
    Mass customization, small lot sizes, reduced cost, high variability of product types and changing product portfolio are characteristics of modern manufacturing systems during life cycle. A direct consequence of these characteristics is a more complex system and supply chain. Product lifecycle management (PLM) and model based system engineering (MBSE) are tools which have been proposed and implemented to address different aspects of this complexity and resulting challenges. Our previous work has successfully implemented a MBSE model into a PLM platform. More specifically, Pattern based system engineering (S* pattern) models of systems are integrated with TEAMCENTER to link and interface system level with component level, and streamline the lifecycle across disciplines. The benefit of the implementation is two folded. On one side it helps system engineers using system engineering models enable a shift from learning how to model to implementing the model, which leads to more effective systems definition, design, integration and testing. On the other side the PLM platform provides a reliable database to store legacy data for future use also track changes during the entire process, including one of the most important tools that a systems engineer needs which is an automatic report generation tool. In the current work, we have configured a PLM platform (TEAMCENTER) to support automatic generation of reports and requirements tables using a generic Oil Filter system lifecycle. There are three tables that have been configured for automatic generation which are Feature definitions table, Detail Requirements table and Stakeholder Feature Attributes table. These tables where specifically chosen as they describe all the requirements of the system and cover all physical behaviours the oil filter system shall exhibit during its physical interactions with external systems. The requirement tables represent core content for a typical systems engineering report. With the help of the automatic report generation tool, it is possible to prepare the entire report within one single system, the PLM system, to ensure a single reliable data source for an organization. Automatic generation of these contents can save the systems engineers time, avoid duplicated work and human errors in report preparation, train future generation of workforce in the lifecycle all the while encouraging standardized documents in an organization

    Towards a method to quantitatively measure toolchain interoperability in the engineering lifecycle: A case study of digital hardware design

    Get PDF
    The engineering lifecycle of cyber-physical systems is becoming more challenging than ever. Multiple engineering disciplines must be orchestrated to produce both a virtual and physical version of the system. Each engineering discipline makes use of their own methods and tools generating different types of work products that must be consistently linked together and reused throughout the lifecycle. Requirements, logical/descriptive and physical/analytical models, 3D designs, test case descriptions, product lines, ontologies, evidence argumentations, and many other work products are continuously being produced and integrated to implement the technical engineering and technical management processes established in standards such as the ISO/IEC/IEEE 15288:2015 "Systems and software engineering-System life cycle processes". Toolchains are then created as a set of collaborative tools to provide an executable version of the required technical processes. In this engineering environment, there is a need for technical interoperability enabling tools to easily exchange data and invoke operations among them under different protocols, formats, and schemas. However, this automation of tasks and lifecycle processes does not come free of charge. Although enterprise integration patterns, shared and standardized data schemas and business process management tools are being used to implement toolchains, the reality shows that in many cases, the integration of tools within a toolchain is implemented through point-to-point connectors or applying some architectural style such as a communication bus to ease data exchange and to invoke operations. In this context, the ability to measure the current and expected degree of interoperability becomes relevant: 1) to understand the implications of defining a toolchain (need of different protocols, formats, schemas and tool interconnections) and 2) to measure the effort to implement the desired toolchain. To improve the management of the engineering lifecycle, a method is defined: 1) to measure the degree of interoperability within a technical engineering process implemented with a toolchain and 2) to estimate the effort to transition from an existing toolchain to another. A case study in the field of digital hardware design comprising 6 different technical engineering processes and 7 domain engineering tools is conducted to demonstrate and validate the proposed method.The work leading to these results has received funding from the H2020-ECSEL Joint Undertaking (JU) under grant agreement No 826452-“Arrowhead Tools for Engineering of Digitalisation Solutions” and from specific national programs and/or funding authorities. Funding for APC: Universidad Carlos III de Madrid (Read & Publish Agreement CRUE-CSIC 2023)

    Integrating models and simulations of continuous dynamic system behavior into SysML

    Get PDF
    Contemporary systems engineering problems are becoming increasingly complex as they are handled by geographically distributed design teams, constrained by the objectives of multiple stakeholders, and inundated by large quantities of design information. According to the principles of model-based systems engineering (MBSE), engineers can effectively manage increasing complexity by replacing document-centric design methods with computerized, model-based approaches. In this thesis, modeling constructs from SysML and Modelica are integrated to improve support for MBSE. The Object Management Group has recently developed the Systems Modeling Language (OMG SysML ) to provide a comprehensive set constructs for modeling many common aspects of systems engineering problems (e.g. system requirements, structures, functions). Complementing these SysML constructs, the Modelica language has emerged as a standard for modeling the continuous dynamics (CD) of systems in terms of hybrid discrete- event and differential algebraic equation systems. The integration of SysML and Modelica is explored from three different perspectives: the definition of CD models in SysML; the use of graph transformations to automate the transformation of SysML CD models into Modelica models; and the integration of CD models and other SysML models (e.g. structural, requirements) through the depiction of simulation experiments and engineering analyses. Throughout the thesis, example models of a car suspension and a hydraulically-powered excavator are used for demonstration. The core result of this work is the provision of modeling abilities that do not exist independently in SysML or Modelica. These abilities allow systems engineers to prescribe necessary system analyses and relate them to stakeholder concerns and other system aspects. Moreover, this work provides a basis for model integration which can be generalized and re-specialized for integrating other modeling formalisms into SysML.M.S.Committee Chair: Chris Paredis; Committee Member: Dirk Schaefer; Committee Member: Russell Pea

    A REPEATABLE THREAT-BASED REQUIREMENTS GENERATION PROCESS LEVERAGING MODEL-BASED SYSTEMS ENGINEERING FOR JOINT EXPLOSIVE ORDNANCE DISPOSAL AND AN ANALYSIS OF RAPID LARGE AREA CLEARANCE

    Get PDF
    The mission of the Joint Explosive Ordnance Disposal (JEOD) program is to reduce or eliminate explosive hazards that jeopardize personnel, operations, installations, or materiel. The JEOD program develops equipment in support of this mission. The equipment development begins with identification of a threat. JEOD has a defined process for threat analysis and capability gap assessment but lacks a process for the generation of system requirements for the Joint Capabilities Integration and Development System (JCIDS). This thesis studied the shortcomings of the current JEOD requirements generation process and developed a new repeatable threat-based process based on a comprehensive review of systems engineering requirements processes. The new JEOD requirements process incorporates model-based systems engineering (MBSE) to analyze the threat and capability gaps and translate them into quantifiable requirements. The thesis applied this new process using MBSE tools and Monterey Phoenix behavior modeling to the JEOD mission of Rapid Large Area Clearance (RLAC) as a case study to identify common mission scenarios and stakeholder requirements that can be used to develop system requirements. The new process can be used for future JEOD requirements development to reduce the burden on JEOD technicians, shorten the requirements development timeline, and produce more comprehensive and accurate requirements. The new process is extensible to the broader DOD requirements generation community.Civilian, Department of the NavyApproved for public release. Distribution is unlimited
    corecore