bluuebunny/crossref_metadata_2025_split huggingface dataset:
4.4.2 The Mission Analysis Discipline: Bringing focus to the fuzziness about Attaining Good Architectures
Authors: Shupp Jeffrey K. 
Published: November 2014

AbstractThe systems and software engineering communities have experienced a veritable explosion of activity surrounding architectures and their role in developing complex systems. This activity has moved forward on two fundamental fronts: the ability to document an architecture, and the ability to evaluate one. Both of these themes have as their foundation the need for well articulated requirements. The architecture is the highest level design of a system, and as such is a response to the requirements. This paper addresses a third, largely overlooked, segment of the early systems development cycle called Mission Analysis, and the focus on the solution trade space through the generation of Technical Business Strategies. Making this topic a recognized discipline in its own right will help to focus early system development work in a way that hopefully makes the overall process less reliant on super system architects to produce good solutions for the long run.
6.4.1 On the Use of Knowledge Modeling Tools and Techniques to Characterize the NOAA Observing System Architecture
Authors: Martin James N 
Published: November 2014

AbstractThe National Oceanic and Atmospheric Administration (NOAA) in the United States has a very broad charter that includes making “observations” of environmental phenomena worldwide. These observing systems are used to provide accurate and timely information to various stakeholders who depend on this information to make critical decisions about farming, construction, fishing, military operations, traffic safety, and so on. This paper describes a project to develop the NOAA Observing System Architecture to assist NOAA in formulating its strategic plans and invest its funding more effectively. We used “knowledge modeling” as the basic approach to capture information about the systems and other entities associated with the architecture. We are using the Metis enterprise architecture tool along with DOORS for requirements, NOAA Forge for team collaboration, and ArcIMS for geospatial data visualization.
6.4.2 Predicting Structural Change in Environmental Systems: a Complement to Model‐based Forecasting
Authors: Osidele Olufemi 
Published: November 2014

AbstractSimulation models are commonly employed for predicting both the impacts of natural stressors and the outcomes of anthropogenic actions on the environment. Such model‐based forecasting depicts a forward approach to environmental systems analysis. This paper presents a complementary backward approach that uses prescribed future scenarios to identify the dominant components of the modeled system. In particular, two Monte Carlo methods for uncertainty analysis – namely, Regionalized Sensitivity Analysis (RSA) and Tree‐Structured Density Estimation (TSDE) – are applied in detecting structural change between observed past and speculated future ecological behavior in a small southeastern US Piedmont reservoir (Lake Oglethorpe, GA). Results indicate that sediment‐water‐nutrient interactions are key elements of structural change that distinguish between the past and future scenarios analyzed. General implications for predicting structural change in environmental systems are discussed.
2.5.1 Systems Engineering and Rapid Product Development
Authors: King Greg 
Published: November 2014

AbstractThis paper describes the processes used at MDS‐SCIEX to quickly deliver a radical new product to the marketplace. Although the product is based on current technologies, it represents a novel use of these technologies. The use is so novel that our scientists were unable to fully predict how customers would use the product. In addition to making it difficult to define complete requirements this also imposed the requirement that the system architecture be flexible enough to quickly adapt to unexpected new requirements.An iterative approach was taken but the deliverables at each stage were complete in themselves. At the start, an over‐all general architecture was defined along with the stages and their deliverables. For each stage the requirements were gathered and analyzed, specifications produced, components were designed, implemented, and tested.Despite what appears to be a lot of redundant work we proceeded rapidly because at no time did we have to completely specify the whole system in detail. Debugging was also facilitated because the changes for each stage were limited and testing commenced earlier. Also by keeping the whole system in mind when designing each stage we were able to minimize backtracking if a deliverable was deemed unacceptable and needed redesign. This approach also serves to mitigate risk as at each stage we have a functional, albeit incomplete, system.
5.5.2 Engineering Tomorrow's Systems Engineers Today
Authors: Goodlass Sue , Seabridge Allan 
Published: November 2014

AbstractTo date, the majority of engineers in UK industry have acquired their qualifications and skills from a ‘traditional’ engineering education, and tend to specialise in a particular ‘branch’ or discipline of engineering or science.Developing the breadth as well as depth needed by Systems Engineers has traditionally only been achievable over a long period of time, especially in the Aerospace and Defence sector where lifecycles of complex systems and platforms can be as long as 50 years.Given the increased demand for reductions in ‘to‐market’ times and the emphasis on whole life services, how can BAE SYSTEMS fast track the process needed to develop the breadth of knowledge and experience to become a successful Systems Engineer in today's rapidly changing Defence environment? Is it possible to convert large numbers of specialist engineers with different educational backgrounds and experience levels into useful Systems Engineers?
2.6.1 Extending the Systems Engineering Methodology to Include Supportability Engineering
Authors: Hanna Michele 
Published: November 2014

AbstractSystems' engineering has always been an essential part of developing integrated solutions. From its' earliest inceptions, systems engineering dealt with providing a solution that balanced performance and operational requirements at the lowest life cycle cost. As an art form, systems' engineering was based upon the methods and processes of individuals. As the tools, methodologies and philosophies of systems engineering evolved, it was transformed from an art to a science. This transformation is demonstrated in evolution that occurred through IEEE 1220, EIA 632, and EIA 731.While many of the attributes of these guidance documents map in to understood design areas such as hardware, software, and ease of manufacture, they do not clearly map into areas such as support strategy, impact to total ownership cost, maintenance planning and technology refresh cycles. These later actions fall under the discipline of supportability engineering. The systems engineering model contains numerous opportunities for supportability linkage, however the supportability hand‐offs were undefined when the systems engineering standards were released. This is because systems engineering guidance documents were being written at the same time supportability engineering was evolving to a standalone entity. The result is the documents have a strong interface, but without the necessary details to effectively integrate the disciplines.This paper describes the interconnections and key linkages that need to be addressed to flow information between supportability engineering and systems engineering, and the further evolution of the systems engineering process through assimilation of supportability engineering.
3.6.2 Using a Rapid Incremental Solution Construction Approach to Maximise the Completeness and Correctness of a Set of Requirements for a System
Authors: Kasser Joseph E. , Cook Stephen C. 
Published: November 2014

AbstractWhile the problem of poor requirements engineering and management has been documented since the dawn of systems engineering the continual documentation and discussion of the problem requirements has not resulted in a practical solution to the problem. This paper discusses applying the Blackboard methodology used in Artificial Intelligence to the development of a suite of Computer Enhanced Systems Engineering (CESE) tools that may be able to alleviate much of the problem. The paper also describes conceptual prototypes of the tools that have already been developed, their effect on alleviating the problem of poor requirements, and some concepts for future tools in the suite.
4.6.1 An Integrated Tool Suite for the NOAA Observing System Ar chitecture
Authors: Martin James N 
Published: November 2014

AbstractThe NOAA Observing System Architecture describes a number of observing systems that provide accurate and timely environmental information to various stakeholders who depend on this information to make critical decisions about farming, construction, fishing, military operations, traffic safety, and so on. This paper describes a project to develop the interfaces between several tools to assist in development of the NOAA Observing System Architecture. We used “knowledge modeling” as the basic approach to capture information about the systems and other entities associated with the architecture. We are using the Metis enterprise architecture tool along with DOORS for requirements, NOAA Forge for team collaboration, and ArcIMS for geospatial data visualization.
3.7.3 Integrated Requirements & Configuration Management For Advanced Software Engineering
Authors: Sibbald Chris 
Published: November 2014

AbstractRequirements Management is essentially the documentation and communication of what is to be delivered for a product. Requirements management ensures a common understanding, between customer and supplier, of what's needed for a project to be successful – and for the customer to be satisfied. The fundamental nature of collecting and managing requirements must accept and welcome change. In fact, most organizations lack any sort of formal process for describing who is accountable and responsible for approving change. This is especially difficult when hundreds of developers, contractors, customers, and leaders are involved. Configuration Management consists of identifying configuration items and associated configuration documentation, implementing change control, maintaining configuration status and performing configuration audits. Linking requirements and configuration management improves communication, accountability and delivery of software and systems projects.
5.7.3 Developing an Information Sharing Architecture across a Complex Competitive Environment
Authors: Macaulay Andrew L , Jenkins Adrian 
Published: November 2014

AbstractThe UK's Warship Support Agency (WSA) works with hundreds of companies to support the Fleet. The information needed is often hosted and managed by these companies, with many of them in active competition with one another.As many business processes span organisations, the sharing of information across boundaries is crucial. To achieve this, change projects were initiated by individual business units, resulting in ‘Shared Data Environments’ between these business units and their partners. Although this approach promotes innovation and rapid progress, it can hinder information sharing across the wider enterprise.This paper sets out the approach adopted by the WSA and Cap Gemini Ernst & Young (WSA's strategic e‐business partner) to develop a Technical Architecture for further information sharing across the enterprise. Key findings from the architecture study are also presented, which have relevance to many organisations seeking to integrate information systems across enterprise boundaries.
6.7.3 The Raytheon Enterprise Architecture Process (REAP)
Authors: Siegers Rolf 
Published: November 2014

AbstractArchitecture processes have become an essential component in the construction of complex systems and in the government's evaluation of defense contractors. The Raytheon Enterprise Architecture Process (REAP) is a systems architecting process being developed by Raytheon Company to address both the needs of our customers and of Raytheon as a system integrator. This process integrates established industry and government standards including: Zachman Framework for Enterprise Architecture, C4ISR/Department of Defense Architecture Framework, Software Engineering Institute's Architecture Tradeoff Analysis Method, Unified Modeling Language, and Colored Petri Nets. The REAP initiative is being approached as a “one‐company” standardized methodology to address architecture definition, description, evolution, and assessment throughout Raytheon. The REAP facilitates higher interoperability for our customers' systems, enables the sharing of architectural best practices through common taxonomy and representation, and supports the creation of product line architecture templates to provide established architecture baselines for the design of new systems.
1.8.2 Managing Project Risks in Requirements, Design and Development using Planguage
Authors: Gilb Tom 
Published: November 2014

AbstractRisk management must be fully integrated into all the development and maintenance processes for systems. It involves far more than applying risk assessment methods to identify and evaluate system risks.To explain this broad approach to risk management, this paper discusses the way in which ‘Planguage,’ which consists of a specification and planning language, and a set of methods developed by the author, contributes to handling risks. It explains some suggested principles, some suggested processes and some specification methods.
1.8.3 Military Value of Spectrum (MVOS): A Case Study in Resource Risk Assessment
Authors: Jones Leo H. 
Published: November 2014

AbstractThe Military Value of Spectrum (MVOS) initiative was begun in late FY01 by the Defense Spectrum Office (DSO) to explore the potential for applying military operations research disciplines and principles to the challenges in spectrum access and use facing the DoD. In this paper we define MVOS as a decisive military advantage gained through the use of spectrum‐dependent technology. We have developed a logical framework to aid the Department of Defense in evaluating the impacts of various spectrum access strategies. Our initial studies demonstrate significant quantifiable connections between spectrum access and traditional measures of military success. We encourage broad participation in the further development of MVOS.
2.8.1 Will Car Manufacturers Survive the Second Death of Henry FORD?
Authors: Jean‐Philippe M. 
Published: November 2014

AbstractHenry FORD was a visionary man that did not only create a huge company, he also built up a comprehensive architecture of the “car system”, including the product, the process, the operations and the service. This architecture was so good that it lasted nearly 100 years, being the basis for one of the strongest industries of the 20th century.The 21st century comes with new requirements, as well as with new technological opportunities that drastically change the way the car systems may be built. But, just as the “fly by wire” killed most of the aircraft manufacturers, the “drive by wire” is likely to produce the same results and be as lethal for the automotive industry.This paper tries to re‐capture the Henry FORD architecture and to put it in perspective with today's concerns and evolutions. Then, a possible systems engineering road map is given to highlight areas where car engineering may reduce the time and money wasted when designing a car.
2.8.2 Deployment of SE including Manufacturing Systems development: Theoretical Aspects
Authors: Lardeur Etienne , Auzet Christian , Bocquet Jean‐Claude 
Published: November 2014

AbstractNowadays, the improvement of engineering efficiency is presently one of the most important issue within the industry field. Engineering coordination through information control is often taken as a means to resolve this issue. PSA Peugeot Citroën has decided to explore this approach, and has consequently decided to deploy Systems Engineering. SE provides an adequate and structured approach for the development of the new vehicles. Vehicles can be considered as complex products. Manufacturing Systems also. Because of its industrial background, the SE Framework of an automotive company must take into account the development of the products, but also the development of the related manufacturing systems. This study is the answer ‐ on theoretical aspects ‐ to the following problematic: how can optimal co‐ordination of the engineering of a complex and mass product and its associated manufacturing systems can be reached in reality? This paper presents the theoretical aspects of a Ph. D. study. Another submitted and accepted paper presents the practical aspects of the same study.
3.8.1 Repeating Design Errors or “Where's The History?”
Authors: Bennett Randal D. , Sloan Crystal D. 
Published: November 2014

AbstractThe Oliver Hazard Perry class of frigates and the Arleigh Burke class of destroyers, the US Navy's newest combatants, share a common design fault despite, or perhaps because of, a 20‐year difference in design time. This paper describes the fault and links the underlying cause of the error to a lack of readily available historical knowledge. A solution is proposed to prevent the recurrence of error repetition by increasing the visibility of corrective maintenance actions to designers and of the status of material condition throughout the fleet to the maintenance managers and operations planners. The results of the process include better design, elimination of repetitive design errors, and true depictions of fleet readiness as a systems engineering solution.
2.3.3 A Transparent Way for Process Guidance in Satellite Design
Authors: Finkel Stephan , Burazanis Michael 
Published: November 2014

AbstractThis paper describes the development of a satellite design process and its implementation within a process guidance tool (Process Steering Tool – ProST) for the work within a design center environment (Satellite Design Office – SDO). Process and tool have been developed at the Institute of Astronautics (LRT) of the Technische Universität München in cooperation with EADS Astrium Ottobrunn within the BaiCES project (Bavarian Center of Excellence for Satellite Constellation Systems) partially funded by the Bayerische Forschungsstiftung BFS. The work presented in this paper was based on two major aspects, the design center concept and the satellite design process. The paper emphasizes a new way of process guidance, using a web based tool support, against the background of these aspects.The authors present the overall process development and guidance approach, in particular the design and implementation of the satellite design center process within the process steering tool and the process guidance provided by the tool. The paper also highlights the evolution from the idea of developing a HTML based process guidance demonstrator to a dynamic PHP/mySQL based tool. It also shows that this approach is well suited for the guidance of a design center team through a development process. The usability and flexibility of this process was shown during a satellite design workshop at the Institute of Astronautics. At the end of the paper the next steps of the process and tool development will be presented.
2.5.3 Unifying Systems Engineering Through the System Record
Authors: Baden Gregory R. 
Published: November 2014

AbstractManaging the information and processes that are intrinsic to systems engineering efforts requires the identification and control of a range of enterprise data. This paper presents an approach to systems engineering management that is based on the concept of the “system record.” By capturing and managing the system record, an organization gains visibility into the five major content areas that feed the systems engineering effort and integrates these content areas within a managed process from the concept phase through retirement. Intrinsic to this approach is the ability to operate on system engineering content from the highest system level to the detailed component level within the context of both process and content interrelationships. Examples of how the system record concept can be utilized in system engineering projects are included.
3.1.3 Complex System Classification
Authors: Magee C. L. , de Weck O. L. 
Published: November 2014

AbstractThe use of terms such as “Engineering Systems”, “System of systems” and others have been coming into greater use over the past decade to denote systems of importance but with implied higher complexity than for the term systems alone. This paper searches for a useful taxonomy or classification scheme for complex Systems. There are two aspects to this problem: 1) distinguishing between Engineering Systems (the term we use) and other Systems, and 2) differentiating among Engineering Systems. Engineering Systems are found to be differentiated from other complex systems by being human‐designed and having both significant human complexity as well as significant technical complexity. As far as differentiating among various engineering systems, it is suggested that functional type is the most useful attribute for classification differentiation. Information, energy, value and mass acted upon by various processes are the foundation concepts underlying the technical types.
3.2.1 Failure Modes And Two Types Of Robustness
Authors: Clausing Don , Frey Daniel D. 
Published: November 2014

AbstractReliability is one of the most important characteristics of a system. To be reliable a system must be robust and mistake free. Robustness is achieved by avoiding failure modes, even in the presence of noises that strongly tend to excite the failure modes. Basic systems engineering primarily considers two‐sided failure modes, such as excessive deviation from the correct voltage reading for a voltmeter, which can be either positive or negative; thus the name two sided. In this paper we focus attention on one‐sided failure modes, which occur only on one side of the distribution for the exciting noise(s). A single one‐sided failure mode is easy to avoid. However, in complex systems it is common for two or more one‐sided failure modes to be affected by one critical design parameter in such a way that it is challenging to avoid both failure modes. A path to a reliable system is to open an operating window between the two one‐sided failure modes.
5.3.2 Creativity in Systems Engineering
Authors: Warner Dawn E. 
Published: November 2014

AbstractA survey of the systems engineering literature reveals an interesting relationship between the artistic terms of ‘art’, ‘originality’, ‘creativity’, and ‘innovation’. An order and nesting of these terms is proposed, and their relationship to the systems engineering discipline is examined. The specific focus is on how creativity is defined in the context of systems engineering, its importance to the discipline, and how it is being used today in system architecting, the transition from research to development, design synthesis, alternatives in decision making, emergence, and project management.