Defining Resilience for Engineered Systems

Systems Engineering and Its Application to Industrial Product Development

Incorporating Unmanned Aerial Vehicles (UAVs) into a Graduate Systems Engineering Curriculum

Human Factors and Systems Engineering Approach to Patient Safety for Radiotherapy

Systems Engineering and Business Strategy might seem to be at different sides of the Business spectrum, but in reality Systems Engineering is a vehicle for achieving the goal set by Business Strategy and obtaining a competitive advantage. It is the author's experience in both military and commercial projects, that most Systems Engineers do not have an understanding of the business principles such as marketing and economics to be taken cognizance of during the design and development of system. The current Systems Engineering standards like the INCOSE handbook, ISO/IEC 15288‐2008 and ANSI/EIA‐632‐1998 also do not always provide any standard processes or activities that could guide Systems Engineers in looking at the business case during the Systems Engineering life cycle.The top management of the organization is responsible for defining the business strategy that defines the direction to enable the organization to satisfy the market demands and subsequently make profit to build a sustainable business. In a Systems Engineering organization, market needs are satisfied through products and services that Systems Engineers are responsible for, but the author's experience has shown that Systems Engineers do not partake in development of organizational strategy. In many cases the Systems Engineers do not even know the organizational strategy. This may cause a misalignment between the organizational strategy and the products and services delivered to customers.The importance of incorporating the business strategy into the Systems Engineering process is becoming more important in order to remain competitive in the global market. The business strategy alignment of Systems Engineering projects is even more important during the current recession of the global economy. This paper investigates the relationship between Systems Engineering, business and the business case of the project the system engineer is responsible for. The relationship between Systems Engineering and Business Strategy to enable Systems Engineering to become the competitive advantage of an organization is also investigated.

Over the last decade, systems engineers have successfully created system modeling languages to communicate with other systems engineers. However, the ability to communicate an evolving system concept and design with stakeholders who are nonengineers remains an elusive goal. In large part, this inability stems from the latter having to understand complex diagrams and equations, and learn new notations employed by systems modeling languages. The problem is further exacerbated by the fact that systems today have to frequently adapt to changing operational and regulatory requirements. Thus, to effectively communicate concepts of operation (CONOPS) and evolving system design to those outside the engineering discipline requires a different approach. This paper presents an innovative approach that employs technical storytelling methods to contextualize and map systems engineering (SE) artifacts represented in SysML to virtual worlds within which various storylines can play out. This capability is intended to improve comprehensibility and transparency of CONOPS and system designs when it comes to communicating with the broader stakeholder community. At the heart of this approach is a virtual world enabled by a 3D game engine, and a mapping capability that allows translation of SE artifacts and interdependencies to virtual world entities and interactions. The key idea behind this integrated capability is to allow the broader stakeholder community to collaborate effectively on key decisions during upfront SE. The benefits of this approach are greater stakeholder satisfaction, avoidance of rework, and more responsive system design.

EXTENDED ABSTRACT As holistic thinking goes, the effects of the system on the human are well-known in the HFES community. However, many practitioners have experienced the challenges of incorporating these effects into a life cycle approach. Systems engineering seeks to model, predict, and employ holistic thinking in the development of multi-part and complex systems (NASA Systems Engineering Handbook). It is posited that a systemic approach and integration of human factors (HF) would better streamline various process pieces, thus reducing life cycle costs and risks to system and human functionality in the deployed system. Systems engineering processes and human factors philosophies have run parallel and intersecting courses, but rarely are they well-integrated. Despite the demonstrated impact of consideration on operators and users early in the design process for the reduction of system life cycle costs, and on increased adoption of systems by those users – few resources and tools exist that allow practitioners to translate human factors principles into Systems Engineering. These same practitioners are often called upon as experts within a systems development process. Limited participation on integrated product teams (IPTs), constrained and niche issue studies, and late life cycle validation all contribute to the challenges of holistic system integration, eventually passing frustration on to the users. The recent introduction of Human Readiness Levels (HRLs), which provide corresponding metrics to the well-established Technology Readiness Levels (TRLs), is one critical tool that will be faciliatory for appropriate consideration of human capabilities and limitations as part of system design (ANSI- HFES 400-2021). Tools like these that can become standard practices will be invaluable for inclusion of the human element into programs of record. However, in many instances, the practical considerations of conducting engineering design are often left to the individual practitioner to figure out. While many academic resources highlight the importance of including HF into system design and development, few resources exist to support in-the-trenches development efforts. In addition, communication of the value of human systems engineering across disciplines is consistently and persistently a challenge and incorporated as part of project contracts and plans to only a limited extent. This panel explores the issue, tales from the jungle, and success stories from multiple points of view, including practitioners of Human Factors, Systems Engineers, and Academics.

The International Council on Systems Engineering (INCOSE) defines system engineering as an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, and then proceeding with design synthesis and system validation.The main challenges of System Engineering are related to providing non-ambiguous and coherent specification, making all relevant information readily available to all stakeholders, establishing traceability between all activities, and providing the appropriate level of verification and validation. Model Based technology can play a central role in System Engineering. Among the benefits, MBSE shall avoid duplication of information, parallel evolution of data between system teams and software teams, hence reducing the nightmare of information resynchronization.I will introduce the SCADE System product line for embedded systems modeling and generation based on the SysML standard and the Eclipse Papyrus open source technology. SCADE System has been developed in the framework of Listerel, a joint laboratory of Esterel Technologies, provider of the SCADE tools, and CEA LIST, project leader of MDT Papyrus.From an architecture point of view, the Esterel SCADE tools are built on top of the SCADE platform which includes both SCADE Suite, a model-based development environment dedicated to critical embedded software, and SCADE System for system engineering. SCADE System includes MDT Papyrus, an open source component (under EPL license) based on Eclipse. This allows system and software teams to share the same environment. Furthermore, and thanks to Eclipse, other model-based tools can be added to the environment.The SCADE System modeler focuses on ease of use, hiding the intricacies of UML profiling to the system engineers. Hence, domain views that have been consistently requested by the system engineering users, such as a tabular view to describe blocks and interfaces, are added to the tool. The core functionality of the Papyrus SysML modeler has also been augmented with requirements traceability and automatic production of system design documents.Once the system description is complete and checked, the individual software blocks in the system can be refined in the form of models in SCADE Suite and SCADE Display, or for some of them in the form of manually developed source code. SCADE System avoids duplication of efforts and inconsistencies between system structural descriptions made of SysML block diagrams, IBD and BDD, and the full software behavioral description designed through both SCADE Suite and SCADE Display models. Automatic and DO-178B Level A qualified code generation can be applied to the SCADE Suite and SCADE Display models. Moreover, the SCADE System description can be used as the basis to develop scripts that will automatically integrate the complete application software.KeywordsSystem EngineerCritical SystemComprehensive FrameworkCore FunctionalityAutomatic ProductionThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Defence Projects world-wide are undergoing a gradual transition from development projects to those involving integration of COTS and Military-Off-The-Shelf (MOTS) Systems. At the same time Requests for Tender (RFT) solicit Innovative Support Solutions to reduce Life Cycle Cost (LCC) over thirty years of operation. While there are defined processes to support both Systems Engineering and Support Engineering, these are hierarchical by engineering discipline and do not provide the means of architecting and trading off system design and support objectives concurrently. This study analyses the suitability of existing engineering processes and builds a model of the current state process set and artefact relationship and compares these with the international standards against the goals of reduced Life Cycle Cost (LCC). This reserach identifies the transitional needs and proposes changes to the Enterprise Business Management System processes, tools and work product templates to achieve concurrent system and service solution engineering.

Toward an Experiential Design Language: Augmenting Model-based Systems Engineering with Technical Storytelling in Virtual Worlds

All Systems Go: How Systems Engineering Can Improve Healthcare Technology

In FY 2004, JPL launched an initiative to improve the way it practices systems engineering. The Lab's senior management formed the systems engineering advancement (SEA) project in order to significantly advance the practice and organizational capabilities of systems engineering at JPL on flight projects and ground support tasks. The scope of the SEA project includes the systems engineering work performed in all three dimensions of a program, project, or task: 1) the full life-cycle, i.e., concept through end of operations; 2) the full depth, i.e., program, project, system, subsystem, element (SE Levels 1 to 5); 3) the full technical scope, e.g., the flight, ground and launch systems, avionics, power, propulsion, telecommunications, thermal, etc. The initial focus of their efforts defined the following basic systems engineering functions at JPL: systems architecture, requirements management, interface definition, technical resource management, system design and analysis, system verification and validation, risk management, technical peer reviews, design process management and systems engineering task management. They also developed a list of highly valued personal behaviors of systems engineers, and are working to inculcate those behaviors into members of their systems engineering community. The SEA project is developing products, services, and training to support managers and practitioners throughout the entire system life-cycle. As these are developed, each one needs to be systematically deployed. Hence, the SEA project developed a deployment process that includes four aspects: infrastructure and operations, communication and outreach, education and training, and consulting support. In addition, the SEA project has taken a proactive approach to organizational change management and customer relationship management - both concepts and approaches not usually invoked in an engineering environment. This paper describes JPL's approach to advancing the practice of systems engineering at the Lab. It describes the general approach used and how they addressed the three key aspects of change: people, process and technology. It highlights a list of highly valued personal behaviors of systems engineers, discusses the various products, services and training that were developed, describes the deployment approach used, and concludes with several lessons learned.

Over the past ten years there has been a steady growth in attention to issues related to systems of systems (SoS) and systems engineering, particularly in Defense in the United States. This attention has focused on how to apply SE principles and practices to SoS, considering the differences between systems and SoS. For many organizations, however, despite recognition of SoS considerations, the focus of investment and development continues to be on individual systems. This paper looks at SoS and SE from the perspective of constituent systems and examines impacts on systems engineering of systems in light of the increased prevalence of SoS. The paper addresses these issues based on the experience and viewpoint of the U.S. Department of Defense and identifies areas for further attention in systems engineering research and practice.

1 - The analytical design process and diesel engine system design

We introduce and demonstrate ROSE – risk-oriented systems engineering, a new approach that integrates risk aspects with system analysis, modelling and design. ROSE is designed to improve the integration and coordination of system design and risk management by fusing robust design paradigms with risk analytic techniques in a model-based environment. While system design and risk management are two critical systems engineering processes, their integration is loose, because too often systems engineers and risk analysts use different semantics, techniques, and tools. This unfortunate disconnects renders risk management efforts detached from system design and management. Object-process methodology (OPM) is a bimodal visual and textual conceptual modelling language and an emerging ISO Standard (19450) for system modelling and design. Making use of OPM, ROSE integrates risk identification, modelling, analysis, mitigation, and control aspects into the robust system design process, and later into system deployment, configuration, and management. Using a commercial airliners defence system against shoulder missiles as a case in point, we demonstrate the principles and benefits of ROSE in risk-oriented systems.

The Air Traffic Control industry is being increasingly exposed to rising levels of risk, as criminals and cyber‐attackers look to exploit system vulnerabilities. Air Navigation Service Providers become more demanding regarding cybersecurity concerns in the products they acquire. Consequently, systems engineers need to consider cyber security concerns early in their system's development life cycle. Model‐Based Systems Engineering methodologies are widely used to manage complex engineering projects in terms of system requirements, design, analysis, verification, and validation activities, leaving cyber security aspects aside. This paper presents a conceptual solution of a model‐based security method that aims to enable systems engineers to perform threat modeling analysis of cyber‐physical systems early and incorporate mitigation strategies into the system design, thereby reducing the cyber‐physical system's overall security‐related risks. Based on a real‐life case study the method will be validated later during execution period from Jan. – May 2022.