bluuebunny/crossref_metadata_2025 huggingface dataset:
1.4.1 Mixed‐Occupancy Vertical Urban Farm Systems
Authors: Nguyen Phuoc‐Hai , Weiss Stanley
Published: November 2014

A mixed‐use vertical farm is a high‐rise structure that is a combination of residences and agricultural subsystems situated near or within urban centers and serving as a localized food production facility. Plants of different varieties are grown year‐round in high density hydroponics/aeroponics modules. Vertical urban farming takes advantage of the ability to control the weather and lighting environments to maximize plants growth, yield, and quality. A systems approach is needed to understand and simplify the complex system considering whole life‐cycle costs, design, construction, operation, and infrastructure integration for environmental management and residences. Overall, the mixed‐use vertical farm is conceived as a high‐tech solution for countries or cities that have shortages in water, extremely limited arable space, and the need for competitively‐priced farm products. Singapore, a nation incorporating many of these factors, is an example of an excellent candidate for such a system.
1.4.2 Planet Systems Engineering Use = Reuse
Authors: van ‘t Hek Irma
Published: November 2014

Planet Systems Engineering (Planet SE) aims for 100% compensation and reusability of all products to meet the requirement of a balanced planet under the continuing growth of human need. To close the reusability loop in biosphere and technosphere, cooperation is needed between producer and consumer. To be succesful, this cooperation should become attractive both to producer and consumer. If sustainability values are experienced as a threat to an organization, these values will be blocked. Therefore Planet SE consultants should support organizations and government in their mission for 100% compensation and reusability. Planet SE: Use = Reuse for a sustainable planet.
2.4.2 Principled systems engineering for the planet
Authors: Haskins Cecilia
Published: November 2014

The discipline of systems engineering continues to mature, but no systems engineer has ever been awarded the Nobel Peace Prize. In their subtle way the Nobel committee have been encouraging economists, politicians and others to put more attention to the global socio‐technical challenges that face the planet today. This paper will explore the essence of the systems engineering framework and suggest ways in which systems engineering practitioners, researchers and educators can rise to meet these challenges.
3.2.1 Issues with Third Party Maintenance of Software Intensive Legacy Systems: A Case Study – Avionic Mission Systems
Authors: Kennedy Damian , Nesterov Sergey
Published: November 2014

The software maintenance burden in military and industrial applications is well known. A variety of factors influence the evolution of large legacy systems, and system upgrades have always been a challenge in terms of avoiding schedule and cost overruns. This evolution becomes even more of a challenge when it is implemented by an organisation other than the original developers. When maintaining complex legacy systems, third party maintenance organisations are placed under additional constraints. Some of these additional constraints come from the decisions made by the Original Equipment Manufacturer (OEM) on the development processes they use and the Computer Aided Software Engineering (CASE) tools that were used to aid in the system development. This paper will describe and analyse a particular case where this occurred with the maintenance of the AP‐3C Orion fleet for the Australia Defence Force by Tenix Aerospace and Defence.
3.3.2 Systems Decision Making Failures in Replacing the World Trade Center
Authors: Benjamin Donald
Published: November 2014

This paper is my senior honors project for the Department of Systems Engineering at West Point. Dr. Gregory Parnell, Professor of Systems Engineering at West Point, is my advisor. This paper directly addresses multiple topics of interest of the symposium including system safety and security, managing environmental impacts, use of human resources, and continuous systems development.

This paper examines, from a system engineer's perspective, why six years after 9/11 no above ground construction on the Freedom Tower has occurred and how systems engineering should have been used to start rebuilding faster and with a better design. Three issues impeded the development of the Freedom Tower. First, battles for decision making authority continually halted the progress of the project. Second, the exclusion of stakeholders upset many who felt they should have had a say in the rebuilding process. Third, the decision makers did not always consider the values and objectives of the stakeholders. An adequate understanding of stakeholder values would have improved the process of replacing the World Trade Center.
4.4.2 Making Decisions That Have Global Impact
Authors: (Hal) Mooz Harold , Forsberg Kevin
Published: November 2014

Making good decisions is fundamental to everyone's personal and business success. Yet most of us pass through life unskilled in making decisions. Our actions often result in poor choices and undesirable outcomes. Moreover, when the world's situation is critically examined it is obviously fraught with poorly made decisions that will continue to impact entire societies for some time to come. (Consider foreign policies, war, economic tactics, etc.) Globally applied system engineering begs for the application of sound decision making that is rooted in logic, based on facts, and is consistent with high standards of global morals and ethics.

This paper examines decisions, decision significance, the many decision influencers, and the available alternative selection methods. The objective is to enlighten decision makers to become decision fit and to be sufficiently skilled to reliably make quality decisions.
5.2.1 On the Various Conceptualizations of Systems and Their Impact on the Practice of Systems Engineering
Authors: Martin James N. , Ferris Timothy L.J.
Published: November 2014

We all have a tendency to confuse an object we observe with the conceptualization of that object. Most of us would not consider this to be a fatal flaw, but when it comes to systems thinking and applying this to systems engineering this tendency could have serious consequences. The object we observe that we call the “system” is not really the system itself. The system is really the “point of view” we take when we properly deal with engineering of what is commonly called “the system”. We will explore in this paper what it means to think of something “as a system” and how we can avoid the common tendencies that get in the way of truly holistic thinking.
5.4.2 The Impact of Environmental Issues on Rolls‐Royce Design Systems and Solutions
Authors: Beasley Richard , Clifton Andrew
Published: November 2014

The prime function of a Power System (e.g. a gas turbine) is to produce power. However, an important side effect of producing and operating such a system is an impact upon the environment. Noise has long been a significant factor, and has been made the subject of firm regulation in Civil Aerospace. More general environmental impact is increasingly becoming the subject of similar concern and regulation. This paper describes how Rolls‐Royce is translating environmental issues into understood and quantifiable requirements, and creating design systems to allow environmental attributes to be assessed. This approach is enabling Rolls‐Royce to organise itself (in terms of process, tools and understanding) to take proper account of environmental issues during the creation of Power Systems.
6.2.2 The Role of Lifecycle Systems in the Through‐life Engineering of System Solutions
Authors: Mackley Tim
Published: November 2014

There are many examples of failures of systems both in terms of their operation and acquisition. In many of these cases, not enough consideration was given to the system context and the needs/ requirements that these place on the system. These wider contextual aspects, how are they identified and where the system boundary should be defined to enable a whole system approach is key.

This paper attempts to identify the following:

the key aspects of a system to consider in order to achieve a whole system approach

the key dependencies on the wider context in order to identify the important tradeoffs to be considered when developing and operating a system

how these wider aspects might need to be considered for different acquisition approaches

The conduct of the analysis in this paper uses a traditional Systems Engineering approach to the problem. It examines the functionality required, identifies the associated form and reviews this against the broader context and required behaviour.

A Whole Systems Model (WSM) is proposed that helps focus attention on the broader aspects that need to be considered for a system throughout its life.
6.4.1 Managing Ports and Harbours as Sustainable Complex Systems
Authors: Allan Lucy , Godfrey Patrick , Allan Jeff
Published: November 2014

Ports and harbours are very large infrastructure projects which have great impact on the community, environment and the economy of a country. Ports are not only a vital lifeline link between water‐side and land‐side traffic, but are also sources of national wealth, pride and concern. Stakeholders now want requirements to be described in a creative, rigorous, and policy‐relevant manner and for critical issues such as sustainable development to be incorporated into developments. This paper looks at the issue of sustainable development for ports and harbours as potentially being one of managing complexity, and it considers how holistic system requirements may be accommodated in this process. It also suggests that currently not enough use is being made of stakeholder data – economic, social, and environmental ‐ and that significant operational improvements could result from closer attention to this issue.

Most of the problems related to sustainability and sustainable development are typically complex and inter‐related. It has been shown that the more complex a system the harder it is to manage, although a certain system complexity is needed for both short and long‐term functionality. By having insights into the causes of complexity in systems enables decisions to be made and actions to be taken where otherwise there may be lost opportunities and ultimately reduced profits, or damage to social and environmental networks. Ports have to achieve a harmonious balance between the local community, the environment and economic issues. By applying systems engineering techniques and ideas surrounding complexity management this paper looks at the designing and subsequent management of ports & harbours and in so doing to develop better overall strategies. Research work into a number of operational sub‐processes is used to gain insights into where measures of complexity may be further developed.
7.2.1 Building Bridges Between Systems and Software with SysML and UML
Authors: Hause Matthew , Thom Francis
Published: November 2014

Systems are becoming increasingly reliant on software. One of the roles of the systems engineer is to perform a trade‐off analysis of the different architectural solutions to a problem, and allocate requirements to different engineering domains within that solution, including software. It is important to investigate effective ways of establishing traceability from the system definition to the software and other requirements. The Systems Engineering Language, (SysML), which is based on the Unified Modeling language (UML), is being increasingly used by systems engineers to model systems. As well as providing system requirements, SysML models can be used to define the system architecture to be used by the software engineers. In this paper, we will demonstrate how SysML and UML can effectively work together to provide an effective handover between systems and software.
7.2.3 On enabling a model‐based systems engineering discipline
Authors: Denno Peter , Thurman Thomas , Mettenburg John , Hardy Dwayne
Published: November 2014

This paper considers the requirements of a model‐based systems engineering (MBSE) discipline and the benefits that would be realized from it. A premise of MBSE is that the technical environment supporting systems engineering has evolved, and is still evolving. We analyze the basis of systems engineering decision making in conjunction with the technical environment in which it may soon be performed. The analysis provides insight into the requirements that, when met, enable a model‐based systems engineering discipline. We report on our practical experience toward meeting the requirements using UML, SysML, AADL, AP233, and a systems engineering tool interoperability testbed.
7.3.2 Systems Engineering Technical Authority: A Path to Mission Success
Authors: Andary James F. , So Maria M. , Breindel Barry
Published: November 2014

The systems engineering of space missions to study planet Earth has been an important focus of the National Aeronautics and Space Administration (NASA) since its inception. But all space missions are becoming increasingly complex and this fact, reinforced by some major mishaps, has caused NASA to reevaluate their approach to achieving safety and mission success.

A new approach ensures that there are adequate checks and balances in place to maximize the probability of safety and mission success. To this end the agency created the concept of Technical Authority which identifies a key individual accountable and responsible for the technical integrity of a flight mission as well as a project‐independent reporting path. At the Goddard Space Flight Center (GSFC) this responsibility ultimately begins with the Mission Systems Engineer (MSE) for each satellite mission.

This paper discusses the Technical Authority process and then describes some unique steps that are being taken at the GSFC to support these MSEs in meeting their responsibilities.
7.6.0 How to Engineer the Emergent Behavior of a System of Systems
Authors: Hsu J , Axelband E , Rouse B , Madni A , Sheard S
Published: November 2014

Emergent behaviors exist in biological systems, physical systems and human performance. Little is currently known about constructing an interoperable network of systems and the incorporation of known emergent behaviors. The purpose of this panel is to explore the methods and principles in developing an architecture including the emergent behavior.

SoS displays a global complexity that cannot be adequately managed by hierarchical structures and central control; therefore, traditional systems engineering and management approaches are inadequate and insufficient for a SoS.

The challenge is how to understand the initiation mechanisms of the emergent behaviors for a particular system architecture model so that the resident beneficial or harmful emergent behaviors can be enhanced or mitigated with selected changes in the current system architectural model. Is model‐based the only feasible approach to develop the architecture model with emergent behavior? If this is the answer, what kind of modeling methodology? Should it be solely based on agent‐based modeling? or combination of SysMl and agent‐based? Is SysML ready to deal with emergent behavior?

For a non‐modeling consideration, can we plan for the beneficial or harmful emergent properties? How do we overcome development friction that is bound to arise when there are complex, independent, overlapping governances? We may need experiment with “guided” emergence that help produce the desired SoS capabilities and behaviors.

The customer requirements for systems‐of‐systems evolve over time. There may only be system‐of‐system modeling at the level of the government agency, who actually procures but does not build, and not at the level of contractors who build the next generation of technologies.

Even we have methodology to build SoS architecture, whether model‐base or non model‐base. How do we train systems engineers to understand the emergent behavior to be incorporated in a newly designed SoS?
8.2.2 A Project‐Product Lifecycle Management approach for improved systems engineering practices
Authors: Sharon Amira , Perelman Valeria , Dori Dov
Published: November 2014

Developing and sustaining complex systems requires collaboration of multidisciplinary teams, coordination of processes, methods and tools, allocation of resources, and utilization of adequate facilities within enterprises. Engineering and management of a system comprises three intertwined domains: the product, the project and the enterprise. Despite the obvious links between them, each domain is distinct and uses its own ontology and toolset. This conceptual separation hinders effective handling of the project and product lifecycle activities within the enterprise. The unified Product‐Project Lifecycle Management (PPLM) collaborative research project aims to establish, implement, and evaluate a methodology for managing and engineering complex enterprise‐wide systems. The resulting software environment will serve as a test bed for proof‐of‐concept of the PPLM vision and approach. The comprehensive PPLM methodology with its software implementation is expected to enhance enterprise‐level systems engineering and management by unifying the product and the project within which it is developed. The paper presents and illustrates the PPLM vision and framework.
9.3.1 Prime Value Method to Prioritize Risk Handling Strategies
Authors: Venkatesh Srini , Noller David K.
Published: November 2014

Funding for implementing risk handling strategies typically is allocated according to either the risk‐averse approach (the worst risk first) or the cost‐effective approach (the greatest risk reduction per implementation dollar first). This paper introduces a prime value approach in which risk handling strategies are prioritized according to how nearly they meet the goals of the organization that disburses funds for risk handling. The prime value approach factors in the importance of the project in which the risk has been identified, elements of both risk‐averse and cost‐effective approaches, and the time period in which the risk could happen. This paper also presents a prioritizer spreadsheet, which employs weighted criteria to calculate a relative rank for the handling strategy of each risk evaluated.
10.1.1 Toward an Evolutionary System of Systems Architecture
Authors: Selberg Scott A. , Austin Mark A.
Published: November 2014

While recent advances in computing/communications technology have enabled the development and managed evolution of large scale system of systems (SoS) applications, lessons learned from industry indicate that these projects are not always successful. A key problem is the lack of a formal framework from which the development and management of SoS architectures can be studied. This paper describes the key ingredients and approaches to formal analysis that we believe will end up in this architectural infrastructure.
10.1.2 The Applicability of Architecture Reference Models
Authors: Hsu John C. , Raghunathan S. , Curran R.
Published: November 2014

Network communications transmit data as the foundation for the deployment of Net‐Centric Operations (NCO). The data are transferred through a series of layers. These layers form the Architecture Reference Model (ARM). The applicability of several ARMs were presented and discussed. The ARMs can be classified to internet application, military/government application, general (commercial and military) application and company/organizational application. Some of the ARMs are related and augmented each other. Each ARM was developed for a different purpose. There are no good or bad ARMs. The architecture models are developed from the ARM. It is necessary to understand the modeling techniques and systems architecting methods to develop architecture models.
10.4.1 Transitioning to Biofuels: A System‐of‐Systems Perspective
Authors: Riley Cynthia , Sandor Debra
Published: November 2014

Today, almost 60% of the petroleum consumed in the United States is imported. The U.S. transportation sector currently consumes for over two‐thirds of the 11 million barrels of oil used in the U.S. each day. Global demand for transportation fuels is increasing dramatically as developing countries expand their economies and become more energy intensive. Clean energy systems are needed to support sustainable global economic growth while mitigating impacts on air quality and greenhouse gas emissions. Biofuels offer a near‐term solution for reducing U.S. oil consumption. Transitioning to a significantly larger biofuels industry will require the creation of a robust biomass‐to‐biofuels system of systems that operates in concert with the existing agriculture, forestry, energy and transportation markets. Using the fuel supply chain infrastructure as a framework, the current petroleum‐based transportation economy, a vision for biomass‐based fuels and the challenges associated with such a massive market and infrastructure transformation are discussed.
11.1.3 Medical Device Development Process
Authors: Jones David J. , Masters Melissa T.
Published: November 2014

Medical devices of increasing complexity are central to mankind's continuously expanding ability to save lives and improve the quality of life. Within our business, we often reflect on how fortunate we are to have the opportunity to work on a variety of these remarkable devices. We believe that such rewarding experiences are made possible through the application of a rigorous system engineering process, ensuring that the resulting devices are safe, effective, and successful.

This paper describes a deployed System Engineering process tailored for Medical Device Development. This process (based on ISO 15288:2002, the INCOSE System Engineering Handbook and a Legacy Process), integrates compliance to international regulations, embeds a Safety Risk Management process as defined in ISO 14971:2007, and assures adherence to ISO 13485:2003 Quality management systems. Based on the classification and complexity of the device the process is scalable, may be tailored, and supports iterative design and development activities.
11.3.2 Verification Closure Strategies – A Collaborative Systems Engineering Approach
Authors: Haskins Bill
Published: November 2014

A collaborative systems engineering approach to verification planning was used to develop verification closure strategies for large complex systems. Verification closure strategies (e.g., Verification Logic Networks) ensure that each Section 3 requirement in a specification is ultimately satisfied. The verification planning process begins with an assignment of a verification method for each applicable Section 3 requirement and developing the associated Section 4 verification text for each verifiable requirement in Section 3 of the specification. Following the development of the Section 4 verification text, a detailed verification closure strategy is developed. Completing the verification closure strategy requires developing the applicable verification objectives to prove compliance with the applicable Section 3 requirement.
KR19 Applying the Sensor Web Enablement Architecture to Reliable Fire Detection
Authors: Echterhoff Johannes , Hahn Daniel , Jirka Simon
Published: November 2014

Current fire detection systems sense a fire by responding to the by‐products or symptoms of fire like heat, smoke and light radiation. Our aim is to increase the reliability of fire alarms and to eliminate nuisance alarms. A quick incident assessment by continuous tracking of the fire spread and knowledge about the incident location enables the decision making about the fire fighting strategy and adequate resource strategy and resource mitigation planning. In this paper we show an approach how to apply the emerging Sensor Web Enablement technology to this use case for implementing an improved fire detection system in a very efficient manner. A comprehensive description of the architecture of Sensor Web Enablement is given in order to explain how the system is built.
KR24 Use of QRA in Supporting a System Safety Case for the Victoria Line Upgrade
Authors: Regan Lucy , Lucic Ivan
Published: November 2014

In the support of a safety case for a complex system, there is often the need to gain an understanding of the overall risk for the system and the way in which this risk will change. To do this in quantitative terms requires a system quantitative risk model. There are a number of such models available for use in the UK railway domain: for heavy rail, the Railway Safety and Standards board (RSSB) has developed a Safety Risk Model (SRM) which is available to stakeholders, and for the London Underground (LU), a London Underground QRA model (LU QRA) has been developed for each underground line which can be used in support of safety cases.

This paper describes the use of the LU QRA in supporting the safety case for the Victoria Line Upgrade (VLU), which involved an upgrade to rolling stock and signalling systems. It describes the primary uses of the model, the main issues involved and the techniques developed in the course of the task.
1.2.3 Systems Engineering Application to Community Innovative Diagnosis System Development
Authors: Wang T.J. , Chin David , Chang Larry
Published: November 2014

The community building is a comprehensive transformation process and the long‐term project for the local community's cultural form, the landscape environment and the life quality. The purpose of community building is to arouse the cooperation consciousness, participation in mutual resolve the society problems for the civil organization. At present, the Taiwan government supports and strengthens the welfares and service functions of the community through this process. Although the appraisal mechanism has the advantage to select a good community, but it also creates problems such as the difference between the appraisal items and community actual results, and individual standards for appraisal reviewers. Other problem such as taking strives for the government funds primarily but the community inhabitants as the auxiliary phenomenon has also appeared.

The present study applies an innovation concept in the community building process through the systematic innovation think, methodology and process which combines system engineering technique and information technology to construct a community innovation service platform in order to provide an innovation service environment for the diagnosis and dialogue communication of the community.

The present study explores community research papers including community definitions, category and measurement index. It then designs a community innovative index questionnaire. With the help of the result of this questionnaire, statistics analysis, and AHP, this study reveals the community innovative index and the weight factors. The study also gives quantify diagnose results and with the application of system engineering technique and process to construct this e‐platform from the diagnose model.
2.1.3 Managing Systems of Systems Interoperability ‐ Federated SOA and Reference Architectures
Authors: Chang Chai Fung , Tan Pong Heng , Tam Soh Khum
Published: November 2014

New and emerging threats, technology advancements and the advent of the Knowledge Age are driving change in Armed Forces around the world. The Singapore Armed Forces is in the midst of transformation into the 3rd Generation SAF to meet these challenges. As military systems morph into increasing networked and interdependent system of systems, the Defence Science and Technology Agency (DSTA) has also adopted strategies and put in systems engineering efforts to manage the interoperability requirements and complexities of this system of systems. In 2006 DSTA adopted Enterprise Architecture (EA) to facilitate businessInformation Technology (IT) alignment and subsequently established a Reference Architecture Framework to ensure interoperability across systems. In this article, we describe the Reference Architecture Framework, the linkage between EA and the Framework, and how the framework will guide the development of the solution blueprint to enable 3rd Generation SAF transformations.
3.1.3 A study of heterogeneous network deployment for WiMax and current wireless LAN
Authors: Liou Bo‐Shen , Heng Ching‐Feng , Hsu Victor , Wang Jing‐Liang
Published: November 2014

In Taiwan, Trial‐and‐error method is adopted in practice in the Base Station (BS) deployment of complex heterogeneous wireless local area network, which is subject to high uncertainty and high cost. Based on existing WiFi hypothesis signal demand, the author utilizes hierarchical clustering method in the SPSS analysis, and combines with different weights, to calculate the LOS and NLOS. The outcomes show that the new method can cover the entire area with less number of BS.
3.3.2 Collaborative Systems Thinking: A response to the problems faced by Systems Engineering's “middle tier”
Authors: Pfarr Barbara B. , Lamb Caroline Twomey , So Maria M. , Rhodes Donna H.
Published: November 2014

Experienced systems engineers are adept at more than implementing systems engineering processes: they utilize systems thinking to solve complex engineering problems. Within the space industry demographics and economic pressures are reducing the number of experienced systems engineers that will be available in the future. Collaborative systems thinking within systems engineering teams is proposed as a way to integrate systems engineers of various experience levels to handle complex systems engineering challenges. This paper uses the GOES‐R Program Systems Engineering team to illustrate the enablers and barriers to team level systems thinking and to identify ways in which performance could be improved. Ways NASA could expand its engineering training to promote team‐level systems thinking are proposed.
3.3.4 Active Brainstorming: ‐ A systemic and systematic approach for idea generation
Authors: Kasser Joseph E.
Published: November 2014

Many systems engineers and other problem solvers practice some aspects of idea generation when problem solving but tend not to practice it systemically and systematically. This paper addresses that aspect of problem solving and introduces a systemic and systematic way of idea generation via four new problem solving idea storage templates similar in concept to the Strengths, Weaknesses, Opportunities and Threats (SWOT) template using a combination of:

Three new problem solving templates which have been successfully used in several iterations of a postgraduate introductory course on systems engineering (Kasser, et al., 2008) and several one‐day workshops on applying systems thinking to problem solving and managing research.

A standard set of system thinking perspectives (STP) (Kasser and Mackley, 2008) arranged around a perspectives perimeter which provide anchor points fo r viewing and discussing issues noting that combinations of the STPs are also useful.

A fourth template in the form of a work sheet for triggering ideas based on a combination of the STPS a nd the six questions “who”, “what”, “where”, when, “why” and “how” introduced by (Kipling, 1912).
4.2.3 Cultural Differences in Systems Engineering: What They Are, What They Aren't, and How to Measure Them
Authors: Collins Shawn T. , Callahan Christopher W.
Published: November 2014

Despite frequent use of the term culture in contemporary engineering practice, there is currently no reliable way of understanding what constitutes true shared beliefs and meanings that impact how groups of Systems Engineers spread across multiple departments and countries work together. This paper develops a framework to address that gap and measure cultural variation in Systems Engineering contexts. Drawing from the field of cultural anthropology, we demonstrate methods to empirically measure cultural consensus and divergence related to fostering collaboration, understanding business success or failure, and identifying characteristics of effective cross‐functional teams. The discussion identifies substantive content of what real organizational cultures are, where they are different, and where they overlap. That quantified content feeds culture as a rigorous element of organizational strategy into global alignment and process excellence or six sigma initiatives targeted at changing team behavior. The result is a framework for conducting rigorous, empirical investigations to truly understand the human dimensions that are critical to effective Systems Engineering practice. We discuss areas this approach applies to global process alignment and team effectiveness.
6.3.4 Culture: A Key Factor for Implementing the Integrated Concurrent Engineering Approach
Authors: Ogawa Akira , Rhodes Donna H.
Published: November 2014

Integrated Concurrent Engineering (ICE) is a design approach initially developed in the United States (US) to reduce schedule time and cost while achieving high design quality in the aerospace mission or system design activities. Many organizations in the US and Europe have confirmed these benefits, however, none beyond these regions. In this paper, we focus on a case in which a Japanese organization within the space domain failed to effectively utilize the ICE approach. This case is analyzed from both the systems engineering (SE) and cultural perspectives with comparison to the successes in the US and Europe to identify the main factors differentiating them. The key findings in this paper will provide organizations with information on where to focus in order to successfully implement the ICE approach and any related IT methodologies, and may better inform the strategy for collaboration of organizations within different cultures.
6.4.0 System Engineering Management Plan (SEMP): DOES ONE SIZE FIT ALL?
Authors: Zonnenshain A. , Malotaux N. , Malotaux N.R. , Honour E. , Kasser J. , Urio U. , Shabtay M.
Published: November 2014

One of the managerial and professional tools of the systems engineers in a project is the Systems Engineering Management Plan (SEMP). According to the INCOSE Systems Engineering Handbook, the SEMP is the top‐level plan for managing the Systems Engineering effort. The SEMP defines how the project will be organized, structured, and conducted and how the total engineering process will be controlled to provide a system that meets stakeholder requirements. The Handbook guides projects to tailor the SEMP to fit project, customer, or company standards.

There are several procedures and templates for the SEMP. But in many organizations, companies and projects we find SEMPs that are not tailored for the project needs and goals and are not presenting specific and effective SE efforts to cope with the real project risks. It appears that many organizations believe that one SEMP size fits all projects, and work effectively from that belief. This panel will discuss the application and tailoring of the SEMP to different domains; how to make it effective. In particular, the panel will consider the following questions and dilemmas:

How is the SEMP different than the actual planning?

What are the special characteristics of a SEMP for developing:

Complex Systems?

Systems with high Technology Uncertainty?

Systems with high Novelty and Innovation?

Systems at a fast pace, or for Agile development?

How to integrate effectively the SEMP into the project and system development planning and execution?

How to integrate effectively the SEMP into evolutionary processes?

How to deal with the most important requirement‐time? Can an effective SEMP contribute to the success of the project?
7.3.2 Monte‐Carlo Simulation Approach for System Readiness Level Estimation
Authors: Tan Weiping , Sauser Brian , Ramírez‐Márquez Jose
Published: November 2014

A system‐focused prescriptive metric, called System Readiness Level (SRL), which incorporates both the current Technology Readiness Level (TRL) scale and the concept of an Integration Readiness Level (IRL) has recently been established to measure current and future readiness status of a system under development. In previous research, deterministic values for components' TRLs and IRLs estimation were assumed, which involves much human subjectivity. Moreover, only point estimation from calculation was proposed in previous research. In order to reduce the subjective influence, we propose a probabilistic method here to combine all evaluators' estimation towards a system's components and integration points. Based on the probabilistic form of TRLs and IRLs, a Monte‐Carlo simulation methodology is followed herein to assess the maturity status (SRL) of a system. An illustrative example is examined to show how to employ the proposed methodology. The paper concludes with the discussion of the gained value of the new methodology as well as its limitation.
8.2.3 Demystifying Ambiguity in The Design of Amorphous Systems
Authors: Kim Sun K. , Ishii Kosuke
Published: November 2014

Designing amorphous systems is challenging because of the broad scope of the task. The design team must integrate various solution elements, such as hardware, software, service, and infrastructure, while resolving the communication challenges among different domain‐experts. This research begins with the observation that, at the onset of an amorphous system‐oriented project, design teams struggle because they are limited to knowledge of fewer than 4 of the 6 W's (Who, What, Where, When, Why, How); rather than having detailed functional or structural specifications as is the case with hardware or software products. The proposed scenario‐based approaches enable design teams to effectively deal with ambiguity and to communicate their ideas among team members and managers, as well as with customers through a common language. Based on the Scenario‐based Design for Amorphous Systems, methods such as the Scenario Graph and the Scenario Menu help design teams through the exploration stage of a new system development. A case‐study from industry demonstrates how a multi‐disciplinary design team extracted high‐level functions and requirements from scenarios dealing with an open‐ended project theme. The integrated framework of Scenario‐based Design for Amorphous Systems guides the design teams in visualizing and organizing scenarios and making decisions in order to define an amorphous system.
8.3.3 Different Levels of Centralized Engineering Database Strategies for Integrated Development
Authors: Eckl Carolin , Brandstätter Markus
Published: November 2014

The development of large and complex products is currently carried out in small, separate teams of engineers trained in diverse disciplines. Mechanical and electrical engineers are involved in the development of high‐tech and embedded systems as well as software designers. This diversity of disciplines interferes with the efficiency of communication, which is usually carried out in (informal) discussions and by passing documents and models.

Within this paper, the passing of documents is explained and enhanced in several levels. Solutions, which are currently available (such as tool chains) are discussed as well as approaches that rest upon a central, document‐ and object‐oriented database. The most elaborate database strategy presented uses similarity relations between documents to infer semantic meaning and facilitate the access to meaningful and relevant development data. This paper concludes with the description of development processes that are introduced with the use of this database solution.
9.2.2 A Decision Analysis Framework for Resilience Strategies in Maritime Systems
Authors: Mansouri Mo , Mostashari Ali , Nilchiani Roshanak
Published: November 2014

This research is an effort to develop a Risk Management‐based Decision Analysis (RMDA) framework based on the common fundamental elements that define the nature of resilience in Maritime Infrastructure and Transportation Systems (MITS). The framework develops a systemic approach to the decision making process in regards to investing on resilience strategies. It also enables stakeholders and decision makers of maritime systems to identify, analyze, and prioritize risks involved in MITS operations; to define ways for risk mitigation, plan for contingencies, and devise mechanisms for continuously monitoring and controlling risk factors and threats to the system; and to value the adopted resilience investment plans and strategies. Our suggested RMDA framework is developed based on the Six‐element Flexibility Framework, which is offered for assessing the value of flexibility strategies in Space Systems, and utilizes a Decision Tree Analysis (DTA) methodology for assessing the cost‐effectiveness of the devised strategies.
10.1.1 An Exploration of Matching Teaching to the Learning Preferences of Systems Engineering Graduate Students
Authors: Valerdi Ricardo , Ferris Tim , Jain Rashmi , Kasser Joseph
Published: November 2014

This paper provides an exploratory study on the relationship between learning preferences of systems engineering graduate students and delivery methods of systems engineering coursework. We begin by providing an overview of learning in the systems engineering context, followed by two central research questions that guide the rest of the paper. Our study is focused on measuring learning preferences based on a previously developed survey instrument called VARK. We provide a detailed description of VARK and some insight into the existing database that sheds light on the typical distribution of learning preferences across disciplines. We provide some preliminary results and discuss their implications on systems engineering curriculum development and delivery. Finally, we discuss additional questions that remain to be explored as we strive to understand the learning preferences of systems engineering graduate students.
QoS Control in MANETs — A State‐of‐the‐Art Perspective
Authors: Sapienza Thomas J.
Published: November 2014

This paper examines the state‐of‐the‐art of Quality of Service (QoS) control for wireless Mobile Ad‐hoc Networks (MANETs) based on an exhaustive literature search comprising over 70 journal papers and conference proceedings and standardization development, per the Institute of Electrical and Electronics Engineers and the Internet Engineering Task Force. Site visits to selected United States Government facilities augmented this literature search by addressing –real‐world” models for a comprehensive series of follow‐on simulations and analyses. This paper defines prominent QoS metrics, such as throughput, delay, packet delivery rate and jitter and then proposes that design parameters, such as data rate, packet size, transmitted power, etc., influence QoS in a way to formulate a Multi‐Objective Function (from the QoS metrics) subject to constraints (from design factors) that will solve an optimization problem using evolutionary computation techniques. This research will foster improvements for data link layer and network layer protocols optimizing QoS control.
Aircraft Emergency Evacuation: A Multi Agent Optimization Approach
Authors: Poudel Minesh , Cosenza Carlos A. Nunes , Mora‐Camino Félix
Published: November 2014

In this communication we consider the problem of modelling a multi agents system evolving over a bi dimensional grid. Starting from an initial state, it is considered that the overall aim of the agents population is to behave so that the system reaches a desired final state in a minimum time. Each agent is characterized by motion parameters while to each cell is associated a current capacity. The application of interest in this study is relative to emergency evacuation of aircraft and the influence of cabin crew over its performance. a non standard assignment problem is formulated so that cabin crew can be used efficiently during emergency evacuation. The solution of this problem should provide minimum time standards as well as insights for the design of personal guidance assistance in emergency situations.
1.1.0 Is MBSE a Tectonic Shift in the Way We Perform Systems Engineering?
Authors: Raymond Jorgensen , Cook Stephen , Watson John , Van Gaasbeek James , Hartmann Ralf
Published: November 2014

Explore the possible transformation of system engineering from a document‐centric culture/ old school system engineering thinking to a model‐centric culture/ information mgt thinking perspectives ‐ and all the hurdles, hijinks, hysteria, and hype that we'll encounter along the way.
2.3.1 Systems Engineering for Space Solar Power Architectures
Authors: Bayer Martin , Born Andrew , Davis Dean , McCormick David , Potter Seth
Published: November 2014

Concerns about the availability and use of conventional nonrenewable energy sources have led to an increasing interest in renewable energy. Because renewable energy sources tend to be dilute and intermittent, solar power satellites have been proposed as a means of supplying large amounts of power continuously. Space solar power (SSP) will not be competitive for commercial‐scale baseload power without some combination of greatly reduced launch and non‐recurring engineering costs as well as space resource utilization. However, SSP may be competitive in the near term for niche markets where the fully burdened cost of delivery of conventional fuel is much higher than that for commercial markets. A model under development provides a tool to assess masses and costs of solar power satellites at a variety of power levels, orbits, and power transmission frequencies.
2.4.1 Application of System Engineering to a Major ITS Project
Authors: Fehon Kevin , Fehon Timothy
Published: November 2014

This paper describes the application of system engineering to a major innovative transportation project in the San Francisco Bay Area, the I‐80 Integrated Corridor Mobility (ICM) Project. In addition to being one of the first applications of Active Traffic Management (ATM) to a freeway corridor in U.S.A., it is also one of the first detailed applications of formal system engineering processes to a major highway traffic management project in the U.S.A.

Rigorous application of the system engineering process allowed the study team to put a structure around a loosely defined concept and a wide‐ranging but incomplete set of system requirements. The study team followed the Federal Highway Administration's (FHWA) “System Engineering for Intelligent Transportation Systems” and also made extensive use of INCOSE's “Systems Engineering Handbook”. Using IBM Rational DOORS software allowed the team to decompose the initial concepts, identify the linkages between requirements at different levels and establish a full audit trail so that all elements of stakeholder input could be shown to be adequately addressed.

The paper describes how the gradual education of the stakeholders in the system engineering process was needed to enable the requirements to be fully developed, in particular to allow the study team to differentiate between legitimate requirements and premature design decisions. The stratification of requirements allowed stakeholders at various levels (board member, executive, manager and operator) to understand how their objectives were being met or how they would be able to operate to fulfill their assigned duties.

It is concluded that the FHWA and INCOSE guidelines provide excellent, practical guidance for the development of complex transportation infrastructure systems.
3.1.1 A Generic Quantitative Approach to Resilience: A Proposal
Authors: Henry Devanandham , Ramirez‐Marquez Jose Emmanuel
Published: November 2014

Resilience is the ability to bounce back from a disruption. Of late, applying the concept of resilience to systems and enterprises is gaining importance because major disruptions are becoming more unpredictable, more frequent, and more severe. While there have been some efforts on defining metrics and measuring resilience, there is no generic quantitative approach to resilience that can be used to measure, predict or compare resilience. This paper proposes a generic quantitative approach to defining and measuring resilience. A simple resilience model is introduced using five critical states of a system, and a set of assertions based on a resource based view. These assertions are treated mathematically in the generic resilience model, and a formula for computing resilience is defined. Two simple cases are also discussed to illustrate the usefulness and potential of this approach.