bluuebunny/crossref_metadata_2025_split huggingface dataset:
11.4.3 Systematic design of greenhouse crop production systems
Authors: Hemming Silke , van Henten Eldert , van ‘t Ooster Bert , Vanthoor Bram , Bakker Sjaak 
Published: November 2014

AbstractProtected cultivation systems are used throughout the world as a powerful instrument to produce crops. They protect the crops from unfavorable outdoor climate conditions and pests and offer the opportunity to modify the indoor climate to create an environment that is optimal for crop growth and production, both in terms of quality and quantity. Designing protected cultivation systems is a multi‐factorial optimization problem. During this process, choices have to be made with respect to construction, cladding material, climate conditioning equipment, energy sources and management, growing substrates, water and nutrient supply, internal logistics and labour, to mention a few. All of these choices mutually influence each other and are influenced by local boundary conditions like climate, economics, market, legislation and availability of resources. This paper presents the outlines of a systematic design methodology to design protected cultivation systems including several design examples of modern greenhouses production systems.
Applying systems thinking and aligning it to systems engineering
Authors: Kasser Joseph , Mackley Tim 
Published: November 2014

Abstract1This is a paper on thinking about thinking. Systems engineering is an emerging discipline in the area of defining and solving problems in the manner of (Wymore, 1993). The emerging paradigm for problem solving is “systems thinking”. Both systems engineering and systems thinking have recognized the need to view a system from more than one perspective. This paper proposes a set of perspectives for applying systems thinking in systems engineering and then defines a systems thinking perspective set of views for a system, the use of which will provide one way of aligning systems thinking to systems engineering. The paper then provides an example of applying the set of perspectives to the Royal Air Force Battle of Britain Air Defence System and shows that not only does the set of perspectives provide a way to model the system; it also picked up two potentially fatal flaws in the system. The paper then concludes with some observations on the state of systems engineering from a number of the perspectives.
KR03 Global Positioning System (GPS) Systems Engineering Case Study
Authors: Bullard Randall , Colombi John , Freeman G. Richard 
Published: November 2014

AbstractThe Global Positioning System (GPS) Systems Engineering Case Study (O'Brien & Griffin, 2008) describes the application of systems engineering during the concept validation, system design and development, and production phases of the GPS program. The case examines the applied systems engineering processes, as well as the interactions of the GPS Joint Program Office, the prime contractors, and the plethora of government agencies that were associated with the programs development and fielding. The systems engineering process is traced from the initiation of studies and the development of key technologies that established the vision of a satellite navigation system in the 1960s, through the multi‐phase joint program that resulted in a full operational capability release in 1995. Numerous interviews were conducted with individuals who personally directed, managed and engineered the program, from which the systems engineering story emerged. Results are organized using the Friedman‐Sage Framework
KR07 SYSTEMS ENGINEERING: THE GLUE THAT BINDS DISPARATE ACQUISITION ORGANIZATIONS
Authors: Holzer Thomas H. 
Published: November 2014

AbstractThis case study presents how an effective joint systems engineering team can bring together disparate but mutually dependant acquisition organizations to improve enterprise acquisitions and technical integrity. The organization providing software applications and associated hardware may not be the same organization providing the host network and server infrastructure. The result can be incompatibilities between system needs and infrastructure capacity, stovepipe capabilities, and flawed acquisitions. A joint systems engineering forum with expanded responsibilities is mitigating these problems by improving collaboration and communication between the two organizations. Their concept of operation reflects how a team spanning application and infrastructure acquisitions can work together in minimizing redundant engineering functions and create a more cost effective and technically sound operational enterprise. Findings presented further show that joint systems engineering will help infrastructure providers and the applications developers successfully establish a more productive and cost efficient relationship.
KR12 Processes and Beyond
Authors: Gonçalves Duarte 
Published: November 2014

AbstractSystems engineering is about coordination. To coordinate is to bring the different elements of a complex activity or organization into a harmonious or effective relationship as a whole system. This paper views coordination in the context of unprecedented or innovative systems and attempts to focus some attention on important social issues relating to how work gets done. A framework of coordination mechanisms is developed. Coordination can be performed using processes, work products, skill/knowledge and mutual adjustment (personal or group communication). Under conditions of high task uncertainty, high task interdependence and dynamic environments, mutual adjustment is favored as opposed to process. Under these conditions this is not a choice. Most methodologies use some combination of the basic coordination mechanisms. The paper presents a case study illustrating some aspects of coordination.
KR14 Emergent Behavior in Systems of Systems
Authors: Osmundson John S. , Huynh Thomas V. , Langford Gary O. 
Published: November 2014

AbstractAs the development of systems of systems becomes more important in global ventures, so does the issues of emergent behavior. The challenge for systems engineers is to predict and analyze emergent behavior, especially undesirable behavior, in systems of systems. In this paper we briefly discuss definitions of emergent behavior, describe a large‐scale system of system that exhibits emergent behavior, review previous approaches to analyzing emergent behavior, and then present a system modeling and simulation approach that has promise of allowing systems engineers to analyze potential emergent behavior in large scale systems of systems.
KR16 Moving Towards a Normative System Engineering Process: Why standards sometimes fail to gain traction
Authors: Haynes David , Dagli Cihan 
Published: November 2014

AbstractThe use of standards is one of the four architecting methodologies commonly used in Systems Engineering, but where do standards come from? Why are standards developed? Why do some standards fail to gain traction? Are standards always developed for the right reasons and along the right lines? This paper discusses the timing and emergence of new standards in the marketplace. The paper selects an emerging industry – Automated Meter Reading (AMR) and discusses the four “who's” (who benefits, who pays, who provides, and who loses) with respect to standard development. Finally, the paper offers some concluding remarks which contain recommendations for would‐be standards sponsors and developers.
KR18 Decomposition of Projects: How to Design Small Incremental Steps
Authors: Gilb Tom 
Published: November 2014

AbstractThe basic premise of iterative, incremental and evolutionary project management (Larman 2003) is that a project is divided into early, frequent and short duration delivery steps. One basic premise of these methods is that each step will attempt to deliver some real value to stakeholders. While it is not difficult to envisage the steps of construction for a system; there is often difficulty in carrying out decomposition into steps when each step has to deliver something of value to stakeholders, in particular to end‐users. This paper gives some guidelines, policies and principles for decomposition. It also gives a short example from practical experience. The evolutionary project management method (Evo) is used (Gilb 2005).
KR21 Systems Thinking and Technical Planning: The Roadmap for Air Force Systems Engineering in the 21st Century
Authors: Bullard Randy , Loren Jeff 
Published: November 2014

AbstractMilitary acquisition has long emphasized the portion of the life cycle between the Request for Proposal (RFP) and Initial Operational Capability (IOC). In response to changing political and economic realities during the 1980s, though, much of the Services' own performance of many technical acquisition tasks devolved to management of contractor efforts. After a number of aircraft accidents in the mid‐ to late 1990s were traced to breakdowns in these processes, the Air Force issued new policy stressing the need to apply Systems Engineering (SE) discipline during later life cycle phases. Significant cost and schedule overruns on major programs, and resultant intense Congressional scrutiny, engendered several initiatives to restore technical and programmatic credibility throughout the entire Department of Defense (DoD) acquisition enterprise. This paper recounts the Air Force's approach to modernizing engineering and technical management policy and practices over the 2000–2006 timeframe, and provides a glimpse of key highlights of their roadmap for the next several years.
KR22 Standards for Defending Systems against Interaction Faults
Authors: Harel Avi 
Published: November 2014

AbstractInteraction faults are operational failures attributed to improper interaction between system components. A special, very important case is when at least one of the system components is a human operator. For example, 60–80 percents of the accidents are due to user errors. This article presents guidelines for preventing and protecting from interaction faults.Did you ever wonder why interactive systems are typically error‐prone and why system development is typically behind schedule? Interaction faults are a main source for productivity and maintenance loss, for customer dissatisfaction, for accidents and eventually, project failure and shortening the system life cycles. Interaction faults are actually the results of design defects. The article shows that the effort required to handle exceptional events is in an order of magnitude more than that for conforming to the requirements for normal operation.A special, very important type of interaction faults is of state mismatch. The first section presents examples of various types of interaction faults, and the design defects that caused these faults.Standards are essential for defending against user errors, because developers often feel irresponsible for user errors and typically avoid fixing the design mistakes that enable these errors. Yet, many of the standards proposed here may also help for the interaction between non‐human system elements.An interaction fault is preceded by a trigger, which is a deviation of one of the interacting subsystems from the normal operational procedure. The article provides guidelines for preventing triggers attributed to user errors of two sources: usability mismatch and user slips. Few methods for preventing mode errors were tested using ModeTester, an experiment interaction specification tool by ErgoLight.To detect interaction faults, the system may include an implementation of a protocol formalizing the operational procedures. The standards should provide guidelines for specifying the system behavior in cases of deviations from this protocol, in order to avoid the unpredictable results of operating in the unexpected circumstances.From each incident, we can learn. The standards should include guidelines about enabling learning from incidents and from accidents.Recently, the Standards Institute of Israel (SII) joined the international effort for usability standardization. Besides adopting international usability standards, which target usability practitioners, the Israeli chapter initiates standards that will target system engineers as well. In particular, the intention is to elaborate and formalize the guidelines and methods presented in this article, to help system engineers defend the system against interaction faults.More about interaction faults: http://www.usability‐standards.com/English/Interaction‐Fault/
Right Sizing Reference Architectures; How to provide specific guidance with limited information
Authors: Muller Gerrit 
Published: November 2014

AbstractThe growing complexity and size of systems and the organizations that create these systems trigger the need for instruments that facilitate the creation of these systems. We shortly analyze these trends and the (potential) role of reference architectures as facilitating means. After a short discussion about the content of Reference Architectures and their relation with system architectures, system design and actual systems, we zoom in on the question what the appropriate level of detail is for Reference Architectures. We discuss an evolutionary approach to create and maintain Reference Architectures
A Large‐Scale Systems Engineering Perspective of Water Management in Singapore
Authors: Seng Eng , Gilbert Foo Kong Pin 
Published: November 2014

AbstractFor a small country with almost no natural resources, Singapore has, over its 42 years of independence, developed an intricate water management system. This system has evolved from a combination of resource development, political diplomacy and acceleration towards enabling water technology. Singapore has found that ensuring a viable water supply for future growth is no longer dependent on any specific domain, but rather across a series of options that, at present, have already poised the island state for self‐sufficiency. The selection of these options is not additive and must be analysed in consideration with the country's regional, political and economic goals. This paper examines Singapore's water management system from a large‐scale systems engineering perspective: goals, boundaries, stakeholders and complexities involved in such a system. Such an approach illustrates how systems thinking and systems engineering tools may be used to understand systems complexities, how learning organization concepts and methodologies may be applied to understand behavioural complexities and how lean thinking facilitates a long term strategic philosophy, built on the premise of continuous improvements. Perhaps more importantly, it shows that while systems engineering, especially the systems approach, is necessary for the conceptualisation and planning of such a system, it is the systemic structures that have been put in place and the people/ culture that make it possible.
What is Systems Engineering for Embedded Systems?
Authors: Boyer Adrian 
Published: November 2014

AbstractThis paper asks the question “What is Systems Engineering for Embedded Systems?” First the scene is set by discussing the prevalence of embedded systems in the world around us including examples, design metrics, and technology issues such as processor architecture. Then the aspects of Systems Engineering that apply to embedded systems are discussed in some detail with a focus on requirements issues such as end product utility and power management. This is followed by a discussion of the System Design issues relating to embedded systems such as real time operation, size & weight and cost. Some focus is applied to the issue of data management for embedded systems. Finally some tool related issues are discussed.
Paradox of the Bermuda Triangle Applying Systems Engineering in a PPP‐environment
Authors: Audsley Robert , van der Vooren René , Elich Erik 
Published: November 2014

AbstractApplying Systems Engineering to a Public Private Partnership (PPP) contract requires a closed‐loop control between the project goals, the project management and the content itself. Unexpected events, contradicting incentives and many more reasons can easily open the closed‐loop without initially being perceived. All parties involved should participate actively at peer levels in order to assure the closed‐loop control. The transparent and phased approach of Systems Engineering supports achieving this peer level closed‐loop control.
Mitigating Rail Transit Project Risks with Systems Integration
Authors: Kouassi Alain J. 
Published: November 2014

AbstractAs rail transit systems are becoming more complex, from a hardware, software and technology standpoint, new approaches are being contemplated to reduce capital project risk. Systems integration has come forward as a way to efficiently transition from traditional systems designed and installed independently without the need for a formal, structured process for physical, functional, logical, and operational integration, to more integrated systems. This paper presents the application of systems integration as a way to mitigate risk on two light rail projects in New Jersey, USA. It discusses how and at what levels various and complex interfaces were managed, and presents methods used to ensure that interface gaps were avoided, duplication reduced, conflicting requirements across projects negotiated and managed, and coordination among all stakeholders refined. It also highlights similarities and differences in approaching the systems integration process for these two projects, the unique challenges faced by the project teams, and general lessons learned that can be carried forward on other capital projects.
1.1.2 Moving the Mindset: from Safety to Systems Safety
Authors: Campbell Alistair , Qureshi Zahid 
Published: November 2014

AbstractSafety is the focus when accidents occur, and the default approach among the experts deployed to investigate such safety incidents, is to concentrate on the technology issues or human errors in isolation. While specific technical faults or human errors can typically be identified as having initiated the safety breach, widening the focus to gain a more systemic understanding of the context within which the accident occurred, is increasingly being recognised as best‐practice. Using the background of some important advances in the field of systems safety by authors such as Jackson and Leveson, this paper draws out the crucial role of the socio‐technical aspects.This discussion is then contextualised by using examples taken from railway safety case studies, to focus on some key practical implications of using this enterprise‐wide systems approach. The paper concludes that a systems approach which includes the enterprise as well, becomes especially important when formulating strategic policy which works towards systems safety.
1.2.1 Development of an Exploratory Computer Model for Acquisition Management of System‐of‐systems
Authors: Ghose Shayani , DeLaurentis Daniel 
Published: November 2014

AbstractThe Department of Defense (DoD) has placed a growing emphasis in recent years on the pursuit of agile capabilities via net‐centric operations. In this setting, systems are increasingly required to interoperate along several dimensions. Yet, the manner in which components of these “system‐of‐systems” are acquired (designed, developed, tested and fielded) has not kept pace with the shifts in operational doctrine. Acquisition programs have struggled with complexities in both program management and engineering design. This paper presents a classification of underlying complexities in the acquisition of system‐of‐systems and describes a conceptual model that exposes the connectivity between systems, requirements, and externalities throughout the acquisition lifecycle. Implementing this model in an exploratory computer simulation highlights the relationship between requirement dependencies, risk profiles of the project and management parameters like span‐of‐control of SoS engineers and managers. The objective of the simulation (which remains under development) is to allow acquisition professionals to develop intuition for procuring and deploying system‐of‐systems, providing a venue for experimentation to develop insights that will underpin successful acquisition of SoS‐oriented defense capabilities.
1.4.0 “Has Asia Been Resilient to Natural Disaster Events and Terrorist Attacks? A Debate on the Issues”
Authors: Mackey W. , Jackson S. , Weng Y. L. , Durodie B. , Ferris T. , Dagli C. , Elias E. 
Published: November 2014

AbstractDuring the past few years, natural disasters including the major earthquakes in China and Pakistan, the Tsunami floods of Indonesia, the firestorms of Australia, and terrorist attacks in Mumbai, India and Bali, Indonesia have caused major loss of life, injury and significant loss of property in Asia. How resilient have these Asian and Pacific countries been to these events?During the same period, insurgent attacks in Iraq, subway bombings in London, fire attacks on the city of Paris, and continued threats of terrorists throughout the world have placed life at risk due to terrorist activities. Also hurricanes and destruction in New Orleans, LA and the Gulf Coast region of the United States have caused major loss of life, injury and significant loss of property. How does resilience in these communities compare to similar communities in Asia?Terrorism is the systematic use of violence and force as a means of coercion through fear and intimidation. As we have seen since World War II and experienced first hand since the terrorist attacks of September 11, 2001, the calculated murder of political personalities has given way to the random killing of innocent people and civilian populations.Natural disasters are perhaps even more threatening. Are we building systems and responding in a way that permits these communities to respond properly and be resilient to these kinds of events? How can the discipline of systems engineering assist in preparing for, responding to, recovering from and mitigate against the risks of natural disasters and terrorist events?Since September 11, 2001, INCOSE through its Anti‐Terrorism International Working Group (ATIWG) has focused the principles, techniques, and practices of systems engineering on how to reduce and eradicate international terrorism. We have taken this opportunity to expand emergency preparedness efforts to natural disasters as well.Through the ATIWG sponsoring of panels at previous INCOSE symposia (2002–2008), writing papers for publication (2003), a tutorial (2004), an Insight Issue (2006) and working group activities, the systems engineering community has discussed the application of collaborative engineering environments, simulation and modeling, religion, system solutions to defend against terrorism, psychology, and root causes of terrorism to address the vulnerabilities of systems as well as the attack responses to threats.This panel continues the INCOSE application of systems engineering to these international problems by discussing the proper responses, recovery and resiliency of society and the systems it builds to natural disaster events and terrorist attacks.
2.2.2 Harmonizing Systems and Software Cost Estimation
Authors: Wang Gan , Roedler Garry J. , Valerdi Ricardo , Ankrum Aaron , Gaffney John E. 
Published: November 2014

AbstractThe objective of this paper is to examine the gaps and overlaps between software engineering and systems engineering cost models with intent to harmonize the estimates in engineering estimation. In particular, we evaluate the central assumptions of the COSYSMO and COCOMO II models and propose an approach to identify gaps and overlaps between them. We provide guidelines on how to reconcile and resolve the identified gaps and overlaps. The ultimate purpose of this work is to develop effective techniques for accurately estimating the combined systems and software engineering effort for software‐intensive systems.