bluuebunny/crossref_metadata_2025_split huggingface dataset:
3.2.2 A Bayesian Approach for Estimating Complex System Reliability
Authors: DOGUC Ozge , RAMIREZ‐MARQUEZ Jose Emmanuel 
Published: November 2014

AbstractAlthough a number of recent studies on using BN for system reliability estimation have been proposed, these studies are based on the assumption that a pre‐built BN was designed to represent the system. In these studies, the task of building the BN is typically left to a group of specialists who are BN and domain experts. However the process of building a system‐specific BN is generally very time consuming and may lead to incorrect deductions. As there are no existing studies to eliminate the need for a human expert in the process of system reliability estimation, this paper introduces a holistic method that uses historical data about the system to be modeled as a BN and provides efficient techniques for automated construction of the BN model and estimation of the system reliability. Moreover, very limited human intervention is sufficient for the process of BN construction and reliability estimation.
3.4.1 Global Systems Engineering at Rolls‐Royce: Using Stories to Explore Ambiguous Standards and Emergent Architecture
Authors: Atherton Malvern J. , Collins Shawn T. , Fisher Stephen A. , Hill Ralph W. , Fisher Stephen A. 
Published: November 2014

AbstractThis paper discusses Rolls‐Royce' experience in implementing a standardized set of roles and control system requirements for its product development projects. It reviews the responsibilities of systems and software engineers, the task of system architecture and its implications on documentation structures. Industry guidelines allow for the definition of more detailed item‐level requirements arising from the system architecture process. However, there is considerable ambiguity in the information transfers to the component life cycle processes and the distinction between these “item/ derived requirements” and “system requirements” in general. A review of projects shows that Rolls‐Royce programs have developed different approaches to the system architecting process. This demonstrates the variety of interpretations for the industry standards such as DO‐178B and ARP‐4754. It also provides a broad set of potential resources for a globally managed development program. However, the ambiguity in the industry standards means that the system architecting process is not always straightforward (as evidenced by its varying Rolls‐Royce embodiments). The paper concludes by developing stories and use cases that help to address differing cultural perspectives, and to replace existing local stories with a new set of stories that can be globally recognized and adopted.
3.4.3 A Comparative Analysis of Project Management and Systems Engineering Techniques in CubeSat Projects
Authors: Elstak Joost , Amini Rouzbeh , Hamann Robbert 
Published: November 2014

AbstractIn the year 2000, California Polytechnic State University and Stanford University issued a new standard for small satellites: The CubeSat standard. This standard allowed universities to design, build, test and operate affordable, small, satellites within a time span of two to three years. Both Delft University of Technology (DUT) and Aalborg University (AAU) have used the CubeSat standard to develop a student satellite. In Delft, the Delfi‐C3 and in Aalborg AAUSAT‐II satellites were developed. This paper evaluates the different techniques that are used in the Project Management and Systems Engineering of CubeSats. The satellite projects of DUT and AAU, which are highly different in setup, will be used as reference points for this evaluation. AAU has a strong pragmatic approach, while DUT uses a structured industrial standard approach.
4.2.1 Business meets Systems Engineering: Facing and Handling Collaboration Challenges in Requirements Analysis
Authors: Laudan Timo , Mauritz Axel , Tollenaere Michel , Gardoni Mickaël 
Published: November 2014

AbstractTraditional requirements analysis models focused on system‐ and user interactions. Whereas, much effort – in particular industrial – is devoted to the logical breakdown, management, dissemination and proof on the level of implementation of requirements without being strongly connected to the organization and its business intents. Recent works focus on “front‐end negotiations”, i.e. early requirements analysis activities concerned with reconciling business problems, opportunities and high‐level product/system requirements. Literature shows that communication and coordination is challenging in conjunction with the visualization and representation of knowledge in a cross‐community/domain constellation of Business and Product Development (PD) teams concerned with early requirements analysis. In this context, we present our research results (within an empirical context) with emphasis on establishing interactivity structures and creating group‐awareness at the interface of Business and Systems Engineering (BSE). Our work articulates a knowledge‐driven concept that anchors a value‐oriented organization of intentional structures (i.e. business needs and expectations) and traces to engineering definitions (in our case with a focus on product/system requirements). In addition, this concept serves the organization, representation and deployment of BSE knowledge illustrating how to perform valuation and verification of intentional structures implemented in forms of specified product/system requirements.
5.1.1 Systems Engineer your Retirement by Simply Implementing a Verification Plan
Authors: Pietras Sherry L. 
Published: November 2014

AbstractOf course what comes to mind is ‘how can you perform verification without requirements?’ Obviously one must develop their retirement requirements but as you do keep verification in mind for several reasons: First, requirements must be written to be verifiable. Secondly, requirements that will not be verified, i.e., included in a planned verification event or activity, are useless rubbish. Thirdly, through identification of verification events or activities it is often realized that requirements are either missing, incorrect, or should be deleted. Finally, when new system designs or services to be provided are the same or similar to what has been done before the requirements most likely already exist and have been verified; therefore they may be borrowed and used with minimal alterations.Certified scuba divers are taught this rule: Plan your dive and dive your plan. This is the key to a successful gratifying dive experience. It is no coincidence that a successful gratifying retirement experience must also be planned. As System Engineers (SEs) we know a lot about planning and every program we work has several types of plans: Concept of Operations, Program Execution, SE Management Plan, Requirement Development, Requirement Management ‐ just to name a few. I propose if you only use one SE plan for your retirement the best plan to select is a verification plan. I say this because the quality of your life is based on what you do. Verification demands awareness as to what you are doing or not doing. It provides a necessary check as to whether or not precious time is being wasted on projects that are off track from your intended retirement pursuits.As you increase your skill in writing necessary verifiable requirements, verification events, approaches, success criteria, closure statements, and verification reports, for your own life the better qualified you will become in your SE career. Remember, it is never too soon to begin planning for your retirement. Also, based on the evidence from human behavior research, too many workers fail to plan appropriately for their retirement. Therefore, the development of a prime SE retirement verification plan template may serve as a beneficial INCOSE technical working group project for the benefit our INCOSE membership and beyond.
5.1.2 A Study on effective Design Review of Urban MAGLEV Program case
Authors: Song Seonho , Park Chulho , Chung Kyung‐Ryul , Choi Chunho 
Published: November 2014

AbstractTo reduce the risk of failure in a project of development of complex system, clear definition and verification of system requirements (SR) are very important. It is known that around 50% of project failures are originated to the failure of SR. Therefore, SR should be verified by reviewing design in each development stages. To perform the design reviews (DRs) effectively, the verification concept for the SR should be established in the view of system integration and adequate tools or templates for DR should be prepared. In this paper, a template for effective DR on large complex system is suggested, with references to the Urban MAGLEV Development Program in Korea.
5.2.1 Task‐oriented System Engineering
Authors: Zonnenshain Avigdor , Harel Avi 
Published: November 2014

AbstractTraditional system engineering (SE) is technology driven. In the design of interactive systems we typically assume that the human operator traces the changes in the system states and operates the system correctly. However, the human operator obeys different rules. The difference between the designers' and the operator's rules often results in loss of productivity, decreased performance and accidents, and eventually, loss of market share. In special cases, it makes sense to demand that the user follows the designers' logic. However, in most projects, it is the designer who needs to adapt to the user's logic. The article analyzes the limitations of common design practices in resolving mismatches between the system and the user states. Complex system engineering (CSE) is a framework suitable for handling the human operator as a critical system component. This article presents a methodology for handling the human attributes in this framework. The methodology extends the capability of common practices of user‐centered design and usability testing, which miss critical interdisciplinary issues. To resolve state mismatches, the system engineers must be aware of the user's logic. Such knowledge should be reflected in the system architecture, to ensure that the user interface provides protection against unexpected user events and to facilitate the system operation in new situations, such as in emergency. The methods and guidelines presented here are applicable to the whole development cycle.
5.2.3 Taiwanese Engineering Process Survey Results — A Preliminary Study
Authors: Peng Willy Y.S. , Ferris Timothy L.J. , Wang T.J. 
Published: November 2014

AbstractThe authors have administered a survey to explore certain issues in the management of engineering processes in Taiwan. The results of the survey are reported in this paper along with indications of future research which are suggested by the results obtained. The survey was developed in order to explore the manner in which engineering work is organized and led in Taiwan. The immediate goal of the work is to explore the interaction of Chinese culture and engineering process. The purpose of the work is to develop an understanding of the interaction of Chinese culture and engineering processes in order to provide a foundation to develop a culturally sensitive approach to the management of engineering work that is appropriate in the Chinese context. The survey explores a number of issues around the effect of corporate and project governance and the kinds of management processes used. The survey was developed with closed form questions to enable data analysis independent of language and to provide data which can be analyzed quickly in the development of sufficient empirical understanding to develop future research approaches. The survey deliberately used common language to describe the issues about which questions were asked to avoid any difficulty with alienating respondents who do not overtly practice or use the technical vocabulary of systems engineering. The results we obtained show that systems level issues are important in most of the companies surveyed.
5.3.1 Development of healthcare service management system using systems engineering and RFID technology
Authors: Kuan Jyh‐Horng 
Published: November 2014

AbstractThe purpose of this research is to apply systems engineering and RFID technology to develop a service management information system, which includes the functions of operation revenue, operation expenditure, service timing and account balance enquiry, and management related statistics and analysis. This research is separated in two stages. In the first stage, Delphi software technology and SQL database are used to develop the management system, whereas in the second stage RFID technology is added in to the customer consumption record management and enquiry system to improve management efficiency. The development of the system is based on systems engineering and Delphi software. The process of systems engineering includes demand estimation, conceptual design, preliminary design, detailed design and development, logistic support and maintenance. Integrating systems engineering with Delphi software technology can facilitate to develop new product at low cost and upon customer's need. Blanchard and Fabrycky are applied in the development of our product, including demand analysis, functional analysis, function configuration and system design. Four main parts in the service management information system, including operation revenue, has been finalized. And we also assisted the enterprise to launch the system, which now has used for two years. The system performs stably and the functions we develop cater the customer's need completely.
5.3.2 A Generic Method for Defining Viewpoints in SysML
Authors: Yamada Takahiro 
Published: November 2014

AbstractIt is important for system engineers to present the information on the systems that they are developing in a precise way so that the information can be understood by as many people as possible. The OMG Systems Modeling Language (SysML) (OMG 2008) was developed to meet that kind of needs of system engineers. It is a common practice to present descriptions of large systems using multiple views, each of which addresses one or more of the concerns of the system stakeholders. SysML has the concepts of view and viewpoint and it requires that a view conform to a viewpoint, which specifies conventions and rules for constructing and using the view, but it does not specify any method for specifying viewpoints.One of the examples of specifying viewpoints in a particular problem domain is an ISO/IEC standard called the Reference Model of Open Distributed Processing (RM‐ODP). This standard specifies five viewpoints to describe distributed processing systems, but it does not provide generic rules on how to construct viewpoints.This paper proposes a generic method for defining viewpoints in SysML by generalizing the concepts used in defining viewpoints in RM‐ODP. By using this method, viewpoints to be used in different problem domains can be defined in a systematic way, and reuse and/or sharing of viewpoints across different problem domains can also be facilitated.
6.2.1 Foundations of Value Based Gap Analysis: Commercial and Military Developments
Authors: Langford Gary 
Published: November 2014

AbstractGap Analysis is widely regarded as a useful tool to facilitate commercial and defense system acquisitions. This paper presents a rethinking of the theoretical foundations and systematics of Gap Analysis with practical extensions to illustrate its utility and limitations. The growing sophistication and complexity of new systems or system of systems have resulted in a dramatic increase in time and money to reach operational capability. Gap Analysis, properly defined and enacted, clarifies goals, appropriate investments and the end‐use. This paper introduces the concept of thinking in terms of value and worth, termed Value Systems Thinking; and the concept of analyses and judgments for acquisition and product development – termed Value Systems Engineering.
6.2.3 Coping with System Evolution ‐ Experiences in Reverse Architecting as a Means to Ease the Evolution of Complex Systems*
Authors: Borches P. Daniel , Bonnema G. Maarten 
Published: November 2014

AbstractCreating systems from scratch is time consuming and costly, therefore companies often choose to evolve existing systems. The understanding that a company has about the impact that a change has in the system architecture determines their ability to cope with system evolution.System architects and designers need to have an architecture representation that enables them to understand and to foresee consequences of evolving the system. This representation however is often not documented. Reverse architecting enables to recover the architecture representation. In this paper, experiences in reverse architecting in a industrial case at Philips Healthcare MRI Group is presented. We show that the proposed approach provides an effective framework to reason about evolvability and impact that design changes has on the system.
6.3.2 The Systems Engineer: a Communicating Saté Skewer
Authors: Schreinemakers Paul J.P. , Elich Erik H.J. 
Published: November 2014

AbstractCommunication is recognised as an important ingredient to execute projects. It is not just a single capacity, but can be drawn along multiple dimensions. This paper describes the Systems Engineer as a ‘Communicating Saté Skewer’, addressing his ability to concatenate different aspects (people, means and content) to secure that the system becomes successful. To be able to act as a good Systems Engineer, this paper describes six dimensions that are important for optimal communication and to fulfil the role of ‘concatenater’ of content. These dimensions range from the organisational‐ and system hierarchy to the intercultural aspects of communication within and between teams or organisations. Moreover these dimensions vary from East to West. Trying to find a person who meets the needs along all dimensions may result in looking for the impossible. Some thoughts are given that may help constructing a balanced team that meets the project needs.
7.1.3 Fault Propagation and Sensitivity Analysis to Support Counterterrorism Activities
Authors: Nagel Robert L. , (Monty) Greer James L. , Stone Robert B. , McAdams Daniel A. 
Published: November 2014

AbstractThis paper discusses research on fault propagation analysis and two associated fault sensitivity measurement approaches for the investigation of faults in human‐centric processes. The techniques presented grew out of a joint project between the U.S. Air Force Academy and Missouri University of Science and Technology to investigate terrorist activities involving improvised explosive devices. Two potential counterterrorism activities related to improvised explosive devices are developed through the paper to demonstrate the application and usefulness of the methodologies. Provided with the examples is a discussion of fault propagation, the sensitivity analysis performed, an interpretation of the results, and an overview of anticipated future applications in system design.
7.2.3 Thermal/Acoustic trade‐off design for Consumer Electronics in a distributed design environment
Authors: Seki Kenichi , Nishimura Hidekazu , Ishii Kosuke , Balmelli Laurent 
Published: November 2014

AbstractToday's market demand for smaller, more powerful consumer electronics poses a major challenge to the rapid design of products. In addition, the ability to perform strategic coordination amongst different stakeholders within the enterprise increasingly becomes an important criterion to enable global engineering. We begin the paper with an introduction to a typical design process involving distributed design teams In particular the process allows the thermal‐acoustic design of cavities, i.e. air space inside the enclosure, in terms of flow rate and acoustic radiation resistance. Then we proceed with the investigation of an approach leveraging recent modelling technology to support such a process efficiently. The process makes use of the system modelling language (SysML.) as product description support and the Design Structure Matrix as an analytical design tool. We use the model and the DSM as a means to drive numerical simulation and perform trade‐off studies. Simulation results show that performing trade‐off study in the early system design phase leads to a potentially optimal module layout for the problem studied.
7.3.1 The Impact of Technical Regulation on the Technical Integrity of Complex Engineered Systems
Authors: Edwards Michael 
Published: November 2014

AbstractThe explicit aim of the application of technical regulation is to ensure that the requisite Technical Integrity of the developed system is achieved. Technical Integrity encompasses fitness for service, system safety and minimised environmental impact. The beginnings of a program of research to test the hypothesis that “The application of technical regulation yields improved technical integrity of the complex engineered system” are established. It is shown that only the intended emergent properties of a complex engineered system and its unintended hazards are directly addressed by technical regulation. A candidate set of measures to assess technical integrity is proposed. The methods that may enhance technical integrity of complex systems are reviewed. The degrees to which technical regulatory frameworks actually enforce methods known to have a contribution to technical integrity are also reviewed resulting in a list of corollary questions to be considered by future research.
7.3.3 Claim‐Payment Failures Of Japan's Insurance Companies And Designing Better Payment Architecture: Finding A Standard Solution To Socio‐Critical Systems By Applying the System Engineering Vee Model Approach (First Report)
Authors: Yasui Toshiyuki 
Published: November 2014

AbstractSociology, political science, economics and international relations traditionally deal with social systems. However, they have not proposed a solution to fix problems when they fail. This paper identifies the scope of social systems in which we can find a solution to cure such failures through three tests; the externality test, mission‐criticality test and controllability test. We name these a socio‐critical system (SCS). Architecture Vee Model can be applied as the standard method to fix failures in an SCS.Massive claim‐payment failures were found in Japan's private insurance companies and they became big social issues in 2005–2008. Japan's financial services supervision authorities identified failures to the full extent and issued successive administrative actions against most insurance companies to encourage them to improve their governance and overall solicitation‐to‐payment systems. This FSA's action, even though it was not necessarily aware of such methodology, proved to be positive in applying Architecture Vee Model to solve failures in those claim‐payment systems, which are typically categorized in SCS.
8.1.1 People, Policy and Technology: Considerations in Designing a Robust Security Framework
Authors: Reed Michael 
Published: November 2014

AbstractThis paper analyses the process which was employed in defining the security architecture for a latest‐generation Electronic Toll Collection (ETC) system. It focuses on one fundamental operational requirement – the non‐repudiation of transactional data and the evidence of travel in support of the enforcement of tolling events – and uses this to highlight the essential integration between technological capability and operational processes in delivering a secure solution.Put simply: in a market of off‐the‐shelf security “solutions”, it is essential at the enterprise level to recognise that security is a process, not a product.The interactions between technical and technological capabilities, operational policies, people and business processes must be tightly aligned in order to demonstrate that the enterprise has achieved the non‐repudiation of transactional data, and has a sound basis for tolling.