bluuebunny/crossref_metadata_2025_split huggingface dataset:
10.3.1 The Development of Systems Engineering International Standards and Support Tools for Very Small Enterprises
Authors: Laporte Claude Y. , Ptack Ken , Fanmuy Gauthier 
Published: November 2014

AbstractIndustry recognizes that there are very small organizations that develop parts which contain software components. These organizations, those with up to 25 people, are very important to the world‐wide economy, and the parts they develop are often integrated into products made by larger enterprises. Failure to deliver a quality product on time and within budget threatens the competitiveness of both organizations. One way to mitigate these risks is for all the suppliers in a product chain put in place proven engineering practices. Many international standards have been developed to capture such proven engineering practices. However, these standards were not written for very small development organizations and are consequently difficult to apply in such settings. An ISO Working Group has been established to address these difficulties. The working group developed standards and technical reports, ISO/IEC 29110, which were published in 2011 for organizations developing software. In 2009 an INCOSE working group was established to evaluate the possibility of developing a standard, using the ISO/IEC 29110 standard as a baseline and the ISO/IEC 15288 as the framework, for organizations developing systems. At the 2011 INCOSE International Workshop, a group of systems engineers reviewed the ISO/IEC 29110 software standard and proposed modifications to meet their needs. One constraint was to develop a document which will allow an organization developing systems with software components to be able to use the actual set of ISO/IEC 29110 standards as well as the proposed systems engineering standards. The future systems engineering standard is targeted at VSEs which do not have experience or expertise in tailoring ISO/IEC 15288. A draft document has been developed and reviewed. Recently, an ISO working group has been mandated to develop the ISO standard for very small organizations developing systems. The INCOSE Systems Engineering Handbook is used as the main reference for the development of a set of systems engineering deployment packages. A deployment package is a set of artefacts developed to facilitate the implementation of a set of practices of a standard in a very small organization.
10.4.1 The Dynamics of Water, Energy, Waste and Environment (WEWE) Systems
Authors: CHIA Eng Seng , CHEN Qiaoyi 
Published: November 2014

AbstractThe application of system engineering to a single system is well established and much research is currently been done to study the systems engineering of ‘system of systems‘. However, many systems are not tightly coupled together although their relationships can be complex and changes over time. In such systems, the need for system integration is less, but there is a need to study their interactions especially the effects they have on one another. This paper is focused on the water, energy, waste and environment systems (WEWE) of Singapore. A system dynamics model of WEWE centered on the water system is created to study the tradeoffs between the systems and to evaluate the effectiveness and impact of water policies on the WEWE systems. This paper further discusses whether Singapore will be able to respond to its growing population, their rising demand for water and energy and their increasing waste level, without damaging the environment and makes recommendation on sustainable development policies based on the findings.
11.3.2 “Rework: models and metrics”: An Experience Report at Thales Airborne Systems
Authors: TONNELLIER Edmond , TERRIEN Olivier 
Published: November 2014

AbstractThis experience report illustrates the implementation of metrics about rework in Systems Engineering at Thales Airborne Systems. It explains how models and quantification of rework contribute to reduce this waste in development processes.This paper is based upon our real experiences. Therefore, it could be considered as an industrial contribution to share this method in Systems / Products Development and Engineering.This experience report describes an achieved example of metrics and its positive impacts on Defense & Aeronautics Systems. However, this document proposes a scientific way to implement our results in other companies. Clues are also given to apply this methodology through a Lean Engineering approach.Finally, Lean Enablers, key factors of success and upcoming steps are described to further improve the performance of Systems Engineering.
11.5.3 Cost‐Benefit Analysis of SysML Modelling for the Atomic Clock Ensemble in Space (ACES) Simulator
Authors: Maurandy Julien , Helm Achim , Gill Eberhard , Stalford Roland 
Published: November 2014

AbstractSystems Engineering has successfully supported the space industry since its inception with methodologies and techniques to handle complex projects. However, the conventional design approach, ‘Document‐Based Systems Engineering’ (DBSE), is more and more reaching its limits. This research evaluates the benefits and the cost associated with the paradigm of ‘Model Based Systems Engineering’ (MBSE) instead of DBSE by applying the Systems Modelling Language (SysML) in the frame of the Atomic Clock Ensemble in Space (ACES) project. ACES is indeed deemed to be a suitable project for this study as it includes both a very complex ground segment as well as a challenging space segment on board the International Space Station.Following an introduction to SysML and the ACES mission, we first develop the metrics on which the cost‐benefit analysis is based on. Then, we explain the methodology and models used to perform the analysis which targets to characterise DBSE versus MBSE based on the ACES ground segment development. Then, we use the Analytical Hierarchical Process to determine weighted criteria where attention is also given to the transitional process between DBSE and MBSE.After a critical reflection upon the analysis methodology and its results, we focus on lessons‐learned from the use of SysML for the implementation of MBSE in space projects. We have identified five key areas of lessons‐learned for using MBSE with SysML itself as well as main deficiencies for Enterprise Architect, the tool used to implement SysML. We conclude with seven suggested improvements which are considered valuable to help improving the performance and acceptance of MBSE for the development of (space) projects in the future.
Architecting Diesel Engine Control System using A3 Architecture Overview
Authors: Wiulsrød Bjørnar , Muller Gerrit , Pennotti Mike 
Published: November 2014

AbstractThe Digital Governor System from Kongsberg Maritime (KM), has had an evolution period of 25 years. Technology has changed during this period and many new features have been incorporated. Consequently the product has increased in complexity over these years and the architecture was not explicit available. We decided to do reverse architecting to be able to decide what changes are needed to the architecture to support the next generation(s) of the product. This project was an opportunity to use the reverse architecting tool described in the System Engineering tool; “A3 Architecture Overviews”. Reverse architecting aimed to recover knowledge that remained in the expert's minds, in order to understand the system and its context. By doing so we were able to visually see where appropriate changes could be made. We learned that “A3 Architecting Overview” is more usable than traditional document, and easier to use as it only required a single sheet of paper.The “A3 architecture overview” is a single page overview of the system relating several System Modeling views: a functional model, some visual aids, a physical block diagram and a quantitative section. This was important because it supported communication and gave focus during discussions.
The Architecture of the Systems Engineering Experience Accelerator
Authors: Wade Jon P. , Kamberov George , Bodner Douglas A. , Squires Alice F. 
Published: November 2014

AbstractSystems engineering educators are struggling to meet the workforce development demand for senior systems engineers. The workforce challenge is to shorten the time it takes for a systems engineer to reach the senior level. The Systems Engineering Experience Accelerator research project was conceived as a critical response to these needs and challenges. The purpose of this paper is to provide a description of the Experience Accelerator architecture which will provide the foundation for post prototype development. While the prototype is only intended as a research vehicle for conceptual design and evaluation, this architectural description should address the foreseen issues for a deployable future version of the system.
Characteristic‐based risk assessment and its relation with event‐based risk assessment
Authors: Mathot Thijs , Hamann Rob , Gill Eberhard 
Published: November 2014

AbstractCommon risk management practice is based on events. Event‐based risk management consists of identifying and mitigating the most significant events that could possibly occur during a project and will have a negative impact on the key performance parameters, development schedule and cost of the product if they occur. The shortcomings of this approach are that this list of risk events is never complete, and is only partially available for the early important design decisions. The proposed solution is to complement event‐based risk management with a so‐called characteristic‐based method. This second method estimates the total risk of the project based on project and product characteristics. The advantages of the two separate methods not only complement each other, but it will also be shown that they enhance each other.
Complex Systems Advanced Modelling
Authors: Ciambra Francesco , Nardini Manuela , Protano Adriano , Tocci Andrea 
Published: November 2014

AbstractIntegrated Systems Functional Modelling (ISFM) is a Model Driven system design method, suitable for the complete representation of the dynamic behavior of complex systems, as required by modern Naval Combat Systems (C/S).ISFM captures the whole system behaviour in a single object‐based DataBase, coded in SysML language, integrating the functional Models of each Combat System component (Sensors, Weapons, C4I capabilities), including the complete model of Combat Management System (CMS). ISFM supports the project Team during the whole project life‐cycle from the System Design to the SW definition and development, and the integration team as benchmark during integration and verification phases. The System Functional Design Test and Validation is included in the project life‐cycle at the System Design stage itself, where the early feedback gives an additional benefit to the quality of the product.
Cybernetics and SysML: First Steps
Authors: Raher Abraham , Pangaro Paul 
Published: November 2014

AbstractSystems Engineering focuses on the design of a system, and Cybernetics focuses on understanding communication and control in designed and natural systems. In Systems Engineering, views of a system are typically represented in SysML in terms of Requirements, Structure, Behavior, and Parametrics. By supporting the analysis of constraints on subsystem properties, parametrics capture whether or not a system design “works”. Cybernetics measures the difference between current state and desired goal by accounting for information returning the system – “feedback” – and for the system's corrective action as it steers towards its goal. This paper shows how (1) cybernetic concepts can help focus a SysML modeling effort on critical questions, and (2) cybernetic characteristics of systems can be modeled in SysML.
Efficiency Management in Spaceflight Systems
Authors: Murphy Karen 
Published: November 2014

AbstractEfficiency in spaceflight is often approached as “faster, better, cheaper – pick two”. The high levels of performance and reliability required for each mission suggest that planners can only control for two of the three. True efficiency comes by optimizing a system across all three parameters. The functional processes of spaceflight become technical requirements on three operational groups during mission planning: payload, vehicle, and launch operations. Given the interrelationships among the functions performed by the operational groups, optimizing function resources from one operational group to the others affects the efficiency of those groups and therefore the mission overall. This framework creates a context in which to understand the effects of resource trades on the overall system, improving the efficiency of the operational groups and the mission as a whole. This allows insight into and optimization of the controlling factors earlier in the mission planning stage.
Managing System of Systems Requirements with a Requirements Screening Group
Authors: Barden Ronald R. , Evans David D. 
Published: November 2014

AbstractFiguring out an effective and efficient way to manage not only your Requirement's Baseline, but also the development of individual requirements during a System of Systems Program's Conceptual and Developmental Life Cycle Stages can be both daunting and difficult. This is especially so when you are dealing with a complex and large System of Systems (SoS) Program with many thousands of SoS Level Requirements as well as an even larger number of System, Subsystem and Configuration Item requirements that need to be managed. This task is made even more difficult when you add in integration of the efforts of multiple requirements development teams (e.g., Integrated Product Teams (IPTs)) and numerous System/Subsystem Design Teams.One solution for tackling this difficult activity on a recent large System of Systems Program was to establish an empowered Requirements Screening Group (RSG). This group is a Team made up of co‐chairs from the Contractor, Customer, and User Stakeholders that are empowered by and accountable to the Program Manager for Requirements Development on the Program. The RSG co‐chairs, with the support of the System of System Requirements Team monitor, make decisions on, and provide guidance on all Requirements Development activities during the Conceptual and Development Life Cycle Stages of the Program. In addition, the RSG establishes and maintains the Requirements Baseline, monitors and enforces requirements traceability across the entire Program, and works with other elements of the Program to ensure integration and coordination.
Requirements Management Applied During a Campaign
Authors: Stephan Volker , Beasley Richard 
Published: November 2014

AbstractThe earlier in a programme that requirements management is applied and the higher in the document hierarchy, the bigger is the lever to achieve the potential benefits. The question is when is the right time to start ‘proper’ requirements management? The answer to this question depends on a lot of factors like size of project, number of people involved and time scales.This paper explains how the requirements are managed for a Request for Proposal (RFP), i.e. when a potential customer has sent a suite of requirements documents together with the rules how to respond with a proposal.A database is essential for the chosen process, since it allows parallel work on consistent data for all parties involved with a minimum of effort for the expert teams, rather than through documents. This does rely on committing to the effort of setting up and administrating the database properly.
Software Patterns for Traceability of Requirements to Finite State Machine Behavior: Application to Rail Transit Systems Design and Management
Authors: Delgoshaei Parastoo , Austin Mark 
Published: November 2014

AbstractThis paper describes a software design pattern (e.g., hierarchical graphs of modelview‐controllers) and models of visualization for ontology‐enabled traceability, where requirements are traced to elements of finite‐state machine behavior (e.g., actions, states, transitions and guard conditions). These ontology‐enabled traceability mechanisms will play an important role in the team‐based development of network‐enabled platforms for analysis, design, and early validation and verification of information‐age engineering systems. The application of these concepts is illustrated through the study of a simplified rail transit system.
Systems Engineering for the Design of a Smart Energy Box
Authors: Hickey Jon , Kashyap Pankaj , Moreno Jorge , Ranganath Naveen , Thomas Alex 
Published: November 2014

AbstractThis paper illustrates that the inclusion of system‐level safety analysis, in this case Systems Theoretic Accident Model and Processes (STAMP)‐based Process Analysis (STPA), in conjunction with systems engineering tools, such as Axiomatic Design, in the conceptual design phase of complex socio‐technical systems is critical to capturing key functional and non‐functional requirements early in the development lifecycle. In particular, capturing safety‐related non‐functional requirements during the conceptual design phase can help avoid operational scenarios that result in conditions hazardous to life and property. In addition, such an approach prevents costly “add‐ons” later in the design and implementation phases of the system life cycle. We illustrate this through the design of a “smart box” that enables large‐scale integration of distributed Renewable Energy Systems (RES) into the electrical power grid to more effectively and efficiently manage overall power demands across the grid. In the conceptual design of this system we arrive at a first set of functional requirements using stakeholder interviews and the Axiomatic Design approach. We then present a detailed discussion of the STPA tool and its application to our “smart box” concept, to arrive at unique safety‐related requirements identified through application of the STPA.
Topic‐based approach for contract‐based requirements development
Authors: Degen Helmut , Kaeppel Jochen G. , Laventhiran Sue 
Published: November 2014

AbstractMany large‐scale industrial projects have a signed contract with many thousand contract clauses which are the input for requirements work. The structure and content of many contracts do not meet IEEE Std 830 quality criteria. The content in the contract is often incomplete, redundant, contradictory and/or ambiguous. The effort to develop requirements from the contract can take several person years effort. It is not trivial to manage such an effort effectively and efficiently. This paper describes a topic based approach for planning and monitoring requirements work for a contract based project. The topic based approach was applied to a large scale industrial system with more than 16,000 contract clauses. However, the approach can also be applied to projects with a smaller number of contract clauses. The paper describes the challenges, the topic based approach itself and lessons learned.
Integrating Reasoning with SysML
Authors: Graves Henson 
Published: November 2014

AbstractMost engineering tasks require in‐depth reasoning. For some tasks, automated reasoning is feasible and can provide high leverage for solving difficult practical problems. Engineering questions can be represented as questions about a model, provided the model contains sufficient domain knowledge. The widely used UML family languages have been embedded within logics. By embedding a model as an axiom set within a suitable logic, engineering questions translate into questions about axiom sets. Automated reasoning can potentially be used to answer these questions. Examples of engineering questions that can be represented as logic questions include verification of a system capability (or a requirement satisfaction) and verification of whether a design change invalidates design constraints. By using this embedding engineers can use languages and tools that they are familiar with, have their models transparently translated into logic, automated inference applied, and the results be returned to their development environment. The logic embedding results of SysML, one of the UML family, is used to illustrate how engineering problems translate into logic problems and how the logic solutions translate back to engineering solutions. An engineering use case for air system capability analysis is used to show how a SysML model can be translated into an axiom set and the engineering question translates into a logic question and illustrates how formal reasoning about an axiom set can be used to answer the engineering question.
2.5.1 Functional Architecture as the Core of Model‐Based Systems Engineering
Authors: Carson Ronald S. , Sheeley Barbara J. 
Published: November 2014

AbstractThe application of functional architecture from a model‐based systems engineering process is examined throughout the product lifecycle. It is shown that focusing on the functionality of the system, in concert with the relationships to other elements of an integrated architecture, is a rich source of information for analyzing, developing, integrating, verifying, operating, and supporting a system. Lessons learned and examples from various product domains are provided.
3.1.2 Design Catalogues: An Efficient Search Approach for Improved Flexibility in Engineering Systems Design
Authors: Cardin Michel‐Alexandre , de Neufville Richard 
Published: November 2014

AbstractThis paper proposes and demonstrates design catalogues as a computationally efficient method for identifying improved designs for complex technological systems. This new process significantly speeds up the analysis of systems that will operate and will be managed under various uncertainty scenarios. It enables analysts to explore the design space more fully, taking into account a greater number of design parameters and variables. It can lead to design solutions with greatly improved lifecycle performance. The design catalogue consists of a small subset of designs that collectively perform reasonably well over a range of possible scenarios. The catalogue approach contrasts with the usual approach that optimizes designs for each scenario, and thus can only afford to examine a limited number of situations. Each design in the catalogue consists of combinations of design variables, parameters, and flexibility decision rules. The set of designs in the catalogue is determined using adaptive One‐Factor‐At‐a‐Time (aOFAT) analysis. An example demonstrates the use and how it leads to improved lifecycle performance compared to a standard benchmark design.
10.3.1 The Engaporean Air‐Defence Upgrade: A Framework for a Case Study development project
Authors: Kasser Joseph 
Published: November 2014

AbstractCase studies have been shown to be a very effective way of learning, however the few case studies available in the systems engineering literature document the ‘what’ of the situation and fail to provide the ‘why’ the insight into the reason for the decisions. This lack of the ‘why’ is an undesirable situation because students will potentially be in similar situations in their futures and need to understand the reasons behind the decisions so they can make their own informed decisions. This paper addresses that gap and instead of providing yet another case study, it provides a framework or architecture for a case in which students can perform the activities and develop an understanding of not only the ‘what's but the ‘why's as well providing a broad overview with plenty of scope for discussion and exercises in each phase of the system development lifecycle (SDLC). The bulk of this paper sets out the timeline for, and provides a high level description of, the Air‐Defence system upgrade process in the fictitious nation of Engaporia. The last section of the paper points out some of the extension opportunities currently planned as well as proving a number of discussion points and exercises.