bluuebunny/crossref_metadata_2025_split huggingface dataset:
1.5.1 Bridging System Engineering and Human Factors Engineering: a step forward
Authors: René Jean 
Published: November 2014

AbstractHuman factors are the cornerstone for insuring QHSESA quality for all/some/many systems. Normative documents such as ISO 15288 or EIA 632 provide keys to human factors processes and activities. There are few links between system engineering (SE) processes and human factors engineering (HFE) processes.This article bridges the gap between SE, using EIA 632, and HFE, using ISO TS 13407 and ISO TR 16982. The purpose is to provide project managers and system engineers with a guide helping them to plan and implement human centred design. The first part deals with SE, the second with HFE, and the third provides the bridge between the two. For each EIA 632 requirement, the article indicates the relevant ISO 13407 principles and activities to apply.ISO 13407 is not as specific and clear as EIA 632. It would be relevant to enhance HF standards in order to encompass such processes as risk management, effectiveness analysis, or trade‐off analysis.
1.6.1 Software Project Management: Adding Stakeholder Metrics to Agile Projects
Authors: Gilb Tom 
Published: November 2014

AbstractAgile methods need to include stakeholder metrics in order to ensure that projects focus better on the critical requirements, and that projects are better able to measure their achievements, and to adapt to feedback. This paper presents a short, simple defined process for evolutionary project management (Evo), and discusses its key features.
1.6.2 An Approach to Tailoring Major Technical Reviews Based on Project Characteristics and Stakeholder Interests
Authors: Richstein Alan B. , Nolte Jerome T. , Pfarr Barbara B. 
Published: November 2014

AbstractBoth NASA and DOD have well defined, proven technical review processes that include numerous technical reviews that occur throughout the systems engineering process life cycle. Many are well known by project managers and stakeholders such as developers and end users, an example of which is the critical design review (CDR). This major milestone for a large, complex new project may last two or more days, include an extensive agenda of topics, and entail hundreds of hours of developer time to prepare presentation materials and associated documents. Additionally, the weeks of schedule spent on review preparation is at least partly at the expense of other work.This paper suggests an approach for tailoring technical reviews, based on the project characteristics and the project manager's identification of the key stakeholders and understanding of their most important issues and considerations. With this insight the project manager can communicate to, manage expectations of, and establish formal agreement with the stakeholders as to which reviews, and at what depth, are most appropriate to achieve project success. The authors, coming from diverse organizations and backgrounds, have drawn on their personal experiences and summarized the best practices of their own organizations to create a common framework to provide guidance on the adaptation of design reviews to other system engineers.
2.1.1 Isoperformance: Analysis and Design of Complex Systems with Known or Desired Outcomes
Authors: de Weck Olivier L. , Jones Marshall B. 
Published: November 2014

AbstractTradeoffs between performance, cost and risk frequently arise during analysis and design of complex systems. Many such systems have both human and technological components and can be described by mathematical input‐output models. Oftentimes such systems have known or desired outcomes or behaviors. This paper proposes “isoperformance” as an alternative approach for analyzing and designing systems by working backwards from a set of desired performance targets to a set of acceptable solutions. This is in contrast to the traditional “forward” process, which starts first in the design space and attempts to predict performance in objective space. Isoperformance can quantify and visualize the tradeoffs between determinants (independent design variables) of a known or desired outcome. For deterministic systems, performance invariant contours can be computed using sensitivity analysis and contour following. In the case of stochastic systems, the isoperformance curves can be obtained by regression analysis, given a statistically representative data set. Examples from opto‐mechanical systems design and human factors are presented to illustrate specific applications of the method.
3.5.2 Integrated Modular Avionics: a challenge in Tools & processes
Authors: Bonnet Pierre , Coupier Alain 
Published: November 2014

AbstractFor years, the avionics systems have been implemented via Line Replaceable Units (LRU) where each LRU is dedicated to one avionics function, leading to huge avionics costs as more and more functions were embedded.In the late 80's, came the idea of Integrated Modular Avionics (IMA) where generic “platforms” would be shared by several “applications“.“First‐generation” IMA programs demonstrated the industry capability to provide integrated “avionics suites” with standardised computing resources, leading to significant improvements in terms of direct and indirect aircraft costs.With the “Second‐generation” of IMA program, the IMA platforms are now being procured separately from the hosted avionics applications, introducing many challenges in terms of industrial organisation, design processes and tools.Thales with Diehl Avionik Systeme, its 49% German subsidiary, has been awarded IMA platforms on the A380 and had to overcome with Airbus these challenges to make this “2nd‐generation” IMA a success.The paper will review how Thales and Diehl are conducting these changes, and how System Engineering processes are impacted.The paper will also give some hints and what is still to be made or could be envisioned as a “3rd‐generation” IMA.
4.3.2 Systems Engineering Approach To Information Assurance
Authors: Taylor Kim H. , Sloan Crystal D. 
Published: November 2014

AbstractToday's security solutions for protecting telecommunications and information infrastructures are primarily defensive. They are not commensurate with the increasingly sophisticated nature of the global cyberthreat, and likely ineffective in countering new, dormant threats that could be a strategic surprise to organizational security. Defensive measures such as firewall and antivirus software can only protect computer networks and systems against known signatures of malicious code. To engineer pre‐emptive capabilities and processes that discourage and repel attacks would require integration of key aspects of security domain engineering into systems engineering practices. An integrated approach would promote the implementation of security controls and processes as built‐in features of future human/computer systems and networks, rather than as separate solutions, thus enabling a more holistic and robust information assurance.
4.4.1 Concept of Operations Development Considerations for a Highly Networked System
Authors: Herald Tom , Verma Dinesh 
Published: November 2014

AbstractWithin the United States Department of Defense, the interest and focus on Network‐Centric Systems (NCS) is increasing. The US Navy defines network‐centric operations as “military operations that exploit state‐of‐the‐art information and networking technology to integrate widely dispersed human decision makers, situational and targeting sensors, and forces and weapons into a highly adaptive, comprehensive system to achieve unprecedented mission effectiveness.” (Committee, 2000) Therefore, the benefits of building a NCS appear to be obvious and desirable for providing greater information in order to render higher quality decisions and provide greater overall system capability. However what is not so obvious is the priority order of the incremental system benefits realized by the NCS. There is a need to identify the magnitude and order of the systems (or system capabilities) that are to be integrated to provide the greatest impact on the NCS mission needs.The importance of developing a clear Concept of Operations (ConOps) document has been acknowledged for many years (since R. J. Lano's seminal publication in 1980). The process traditionally involves a single Systems Engineer (or System Architect) responsible for taking the needs statements from the involved stakeholders, and consolidating this tops‐down information into a coherent ConOps document. When the size of systems and the number of stakeholders were both small this “single person focal point” was reasonable; however, with NCSs this approach is no longer sufficient. The challenge is how to best formulate a NCS‐level ConOps when the number of stakeholders with uncompromising needs has increased drastically.Since a new NCS is often made up of existing systems plus the development of new state‐of‐the‐art and emerging‐technology systems, there is potential to provide an early system analysis from the bottoms‐up and integrate with the stakeholder tops‐down needs. This source of information is the existing constituent system Concept of Operations (ConOps) documents. However, how can these be effectively used? This paper focuses on a reasonable implementation in direct support of the NCS Systems Engineer with the tops‐down and bottoms‐up mapping for effectively feeding the NCS‐level ConOps document development process.
6.5.1 Attributes of a Managerial and Organizational Infrastructure to Enable Safe Systems
Authors: Jackson Scott , Hann Stuart D. 
Published: November 2014

AbstractHuman‐intensive systems have become the subject of systems engineering studies in recent years. This concept can be used to define the organizational and managerial infrastructure that develops, maintains and operates complex systems subject to catastrophic failure. For a program to be effective, it must exist within this infrastructure that contains specific attributes that will enable it to meet its objectives. If it does not, even the most well planned program will experience shortfalls, and there are multiple examples of that occurring. This paper presents the attributes' observable features and shows how these attributes can be confidently applied to any organizational and managerial infrastructure. While these attributes are not a guarantee that a program will be effective, they provide the means to assure that any program will have an opportunity to perform at its best without being compromised by an inappropriate infrastructure. Case studies are cited and correlated to specific attributes, which, if applied, would have mitigated the probability of a major catastrophe.
6.6.1 Adapting Systems Engineering for Software‐Intensive Systems
Authors: Sheard Sarah A. 
Published: November 2014

AbstractThe nature of systems engineering has changed in the last quarter century because of the increasing presence of software in systems. This paper describes the adaptations that systems engineers should make to their skills and approaches in order to engineer software‐intensive systems better, and the places where systems engineers need to reinforce what continues to be useful about traditional systems engineering. Systems engineers should continue to contribute “systems engineering specialist” skills, help the project manager coordinate multidisciplinary activities that ensure a well‐engineered system, and continuously learn about software. Finally, the systems engineer might need to advocate for good systems engineering.
6.6.3 Lessons Learned from Implementing Configuration Management within Electrical/Electronic Development of an Automotive OEM
Authors: Knippel Erwin , Schulz Armin 
Published: November 2014

AbstractIn the past decade the automotive domain has encountered significant changes within its competitive environment. Automotive OEMs are forced to offer an increased number of variant models, to satisfy individual customer needs as well as constantly introduce innovative features within their products. Electrical/electronic systems play a major role enabling OEMs to address these needs. Development processes for electrical/electronic systems are moving into the focus of automotive companies. However current development approaches for these type of systems within automotive industry are only partially able to cope with the mentioned challenges and yield the necessary, high‐quality systems. Thus automotive OEMs started to restructure their development approaches for electrical/electronic systems and introduce Systems Engineering.This paper is illustrating lessons learned from implementing configuration management within electrical/electronic development as part of an major initiative at a German OEM to introduce Systems Engineering. The initiative is still on its way, therefore the lessons learned are only part of the truth. The paper will start by highlighting the current situation of the automotive industry and point out the future role of electrical/electronic systems for achieving competitive advantage. Based on this background the need for Systems Engineering, especially within electrical/electronic development will be discussed. Configuration management as a part of Systems Engineering processes will be described in general and in its application in an automotive environment. The specifics of configuration management within Electrical/electronic development of an automotive OEM will be highlighted and discussed. Afterwards the paper discusses lessons learned during conception and implementation of the configuration management building blocks into the OEMs organization. Key success factors for introducing configuration management as part of a Systems Engineering initiative into an existing process and organizational landscape are then derived from the lessons learned.
7.3.1 Human Understandability for Optimizing Architectures
Authors: Smith Darold K. 
Published: November 2014

AbstractHumans define, create, and use systems. Therefore, to minimize opportunities for problems in a system's lifecycle, the work products that affect the system definition and program lifecycle activities must be highly understandable and not subject to multiple interpretations. The antidote to complexity is (human) understandability. Understandability is driven by the amount and clarity of information presented and accessible to stakeholders at a particular level in the system architecture. High‐level information needs to be more general while lower‐level information must provide sufficient detail to prevent ambiguity and omissions. The issue is how to package information at each system level to maximize stakeholder understandability at that level.This paper describes ways to increase human understandability and thereby increase system robustness of both the architecture elements and interfaces between them during the SE process. The result is a system definition that is more likely to satisfy the SE goals of delivering an error free product.
7.4.3 Inside‐Out Systems Architecting: An Approach to Architecting the NASA Orbital Space Plane
Authors: Post Kevin E. , Dagli Cihan H. 
Published: November 2014

AbstractNASA has published the Level One requirements for the Orbital Space Plane development. Those requirements leave open opportunities for creative development of a spacecraft that not only will provide the world with efficient travel to and from low‐earth orbit, but also for crew rescue capability from the International Space Station. The success of the Orbital Space Plane development phase will depend strongly on the ability of competing contractors to establish criteria for gathering the needs of the stakeholders and develop models which are technically achievable, have acceptable risks, have acceptable costs, while adequately meeting the NASA needs.This paper proposes a hypothesis for architecting the NASA Orbital Space Plane. Beginning with the level one system requirements, this approach defines a “system of systems” approach that moves from the “inside‐out” in an iterative fashion. This process allows the system architect to understand the out‐lying systems and when/where the architecting process should stop. Systems are inherently boundless and knowing also where are the client's core needs versus what are the “desirements“. Fundamentally, both the System Life Cycle functions (process architecting) and the System Functions (product architecting) need to be addressed in this way and in an integrated fashion. Each system level would address both the System Life‐Cycle Function as well as the System Functions.
7.5.3 Testing Industrial Embedded Systems – An Overview
Authors: Prins Martin 
Published: November 2014

Industrial systems are becoming highly dependent on software modules. This results in a continuous increase of both development & test effort and maintenance & upgrading effort of innovative products. While on one hand competitiveness requires an as early as possible rollout of new developed products the increasing complexity tends to lengthen the testing trajectory and seriously threatens the quality of the delivered products. To limit this trend of increasing cost, time, and team size, research is required that targets on improving development and test methodologies, processes, and supporting tools.Based on experiences in the semiconductor industry ‐ in particular the lithography segment of this industry ‐ this paper explores factors that should be taken into account when selecting a test strategy. In the paper, we discuss the major factors contributing to the complexity of complex system integration. In particular we will consider the problem of testing subsystem and system behavior during several stages of integration. We discuss several contributing factors to the test problem: the need to deliver in time, technology, and testing knowledge.
8.2.3 Verification, Validation & Testing Strategy and Planning Procedure
Authors: Lévárdy Viktor , Hoppe Markus , Honour Eric 
Published: November 2014

AbstractThis paper introduces a new systems engineering approach for verification and validation (V&V) planning: the Verification, Validation & Testing (VVT) Strategy and Planning Procedure. This iterative planning technique offers an effective method for the deeper integration of V&V planning with other systems engineering disciplines and supports the maximal fulfilment of the project goals and objectives. Since V&V is an important means to reduce project risk, the new VVT strategy & planning procedure assists the risk management efforts by feeding the results of risk analysis directly into VVT planning and the systems engineering measurement process. VVT planning defines the optimal risk reduction strategy in form of the VVT process and a measurement system to track project risks throughout the lifecycle. The three stages of the SysTest VVT Process are introduced in the first part of the paper and then the major steps of the VVT strategy & planning procedure are described in detail. Finally, the last section provides insight to the SysTest pilot projects presenting the first results of the VVT Methodology implementation.
8.3.1 Clearing The Confusion About Spiral/Evolutionary Development
Authors: Mooz Hal , Forsberg Kevin 
Published: November 2014

AbstractUS Government DoD Directives 5000.1 and 5000.2 declare a preference for evolutionary acquisition and spiral development both of which affect the life cycle and associated life cycle processes. Since this declaration there has been considerable confusion over what these terms mean and how they should be applied to system acquisition. Unfortunately, the DoD's own terminology definitions do not help to clarify these approaches and tend to counter traditional understandings. Both the Software Engineering Institute and Under Secretary of Defense E. C. (Pete) Aldredge have been quoted that there is confusion and lack of understanding of both the terms and application. This paper highlights the points of confusion and then takes the reader back to ground zero and builds a logic based understanding of available technical strategies. Included are technical methods/models, development strategies, and delivery strategies.
8.4.1 Supportability Analysis Process Flow
Authors: Navarro Ernesto A. , Carstens Howard D. , Sleder Albert 
Published: November 2014

AbstractUnited Defense, L.P., Armament Systems Division has developed a process that improves the accuracy of reliability, maintainability, and supportability analyses during the design cycle. These analyses rely heavily on initial assumptions in calculating key parameters and serve as the basis for determining spares, manpower, maintenance policy, etc and ultimately the estimate for system Total Life Cycle Cost (TLCC). Because of this, it is imperative that the initial assumptions be realistic and credible. We found that by modeling and simulating the design against the customer's specific mission profile, we can obtain realistic credible results, permitting the program to make cost effective supportability decisions early in the system design cycle.This paper presents the process and related tasks used in developing the supportability analysis in order to obtain realistic supportability results. Also, this paper discusses the benefits of the approach and draws a comparison between the traditional methodology and this new process.
8.6.2 Maintainability Considerations for Software Intensive Systems
Authors: Ramchand Ramya , Tatikonda Nirmala , Verma Dinesh , Nance Richard E. 
Published: November 2014

AbstractThis paper reflects one aspect of an overall research initiative to better understand and articulate the “cause and effect” relationship between design causes and operational effects. Here the specific focus is on “before the fact” system maintainability. Maintenance considerations for software intensive systems must be addressed early in design and must focus on the entire system life cycle. Use of commercial‐off‐the‐shelf (COTS) components in system architectures reinforces this need. COTS usage can be readily observed in modern commercial and defense systems. Such architectures are often characterized by an evolving physical baseline (technology refreshment) driven by obsolescence considerations. This paper proposes aspects of a framework to evaluate system architectures, with a particular focus on system maintainability and with the objective of positively influencing the long‐term cost of operational maintenance.
9.1.1 Applying Systems Engineering to University Satellite Projects
Authors: Meijers M.A.H.A. , Hamann R.J. , Zandbergen B.T.C. 
Published: November 2014

AbstractA growing number of spacecraft development programs are emerging at universities across the world. These programs share a lot of characteristics because they are all encouraged by the perception that a small spacecraft can both be capable and low‐cost. The success of these missions, both on a performance and programmatic level, is often due to use of adapted design and verification methods from mainstream large satellites. These methods are well described in successive papers like [McInnes, 2001] & [Kitts, 1995]. Less attention is however paid to the adaptation of the requirements definition process and design configuration management process into a small satellite project. This paper shows the need for the adaptation of full Systems Engineering (SE) functionality into such a project and that it is possible to adapt the SE process, while keeping full functionality, into a small spacecraft project that is conducted in an educational environment. The paper describes the successful introduction of the requirement engineering process and configuration/design management in the Delfi‐1 university satellite program, as part of the primary author's master thesis.