bluuebunny/crossref_metadata_2025_split huggingface dataset:
8.2.2 Improvement of Software Engineering Performances An Experience Report at Bombardier Transportation – Total Transit Systems Signalling Group
Authors: Laporte Claude Y. , Roy Denis , Doucet Mikel , Drolet Marc 
Published: November 2014

AbstractThe performance of the Bombardier TTS/Pittsburgh Signalling group has been evaluated twice: first in November 2003 and again in January 2006. The 2003 evaluation established a baseline for the evaluation of progress made in 2006. During those visits, the same evaluation method was used to evaluate project performance and organizational change management, i.e. the people issues. Since 2003, there has been substantial improvement in both process maturity level and process performance. This experience report, at Bombardier Transportation, illustrates that process performance improvements are achievable when two key factors are involved, namely: a link between business goals and process improvement activities, and a sponsor committing the right level of resources to the improvement program. This paper explains the multi‐dimensional methodology used to perform the evaluations, as well as the business goals and the quantitative performance improvements achieved since 2003.
8.2.3 Optimal integration and test planning applied to lithographic systems1
Authors: Boumen R. , de Jong I.S.M. , van de Mortel‐Fronczak J.M. , Rooda J.E. 
Published: November 2014

AbstractIn the current integration and test phase of the development of a complex system, (the “right side” of the V‐model) planning is becoming more and more difficult because of: 1) variability in delivery times of components, 2) failing tests and subsequent repairs, 3) resource changes and the use of component models, and 4) the growing system complexity and growing number of components and tests. Manually created integration and test plans are often not optimal regarding time‐to‐market. Furthermore, creating and maintaining these plans costs a lot of effort. In this paper, we introduce a method that allows to automatically create optimal integration and test plans. This method can be used by intelligent enterprises to shorten the time‐to‐market of a system and to reduce the effort needed to create and maintain integration and test plans. We illustrate this method with two cases studies related to the development of ASML lithographic machines (ASML 2006).
8.3.1 Bridging the Chasm ‐ Tracing from Architectural Frameworks to SysML
Authors: Hause Matthew , Thom Francis 
Published: November 2014

AbstractA conspicuous disconnect exists between a MoDAF/DoDAF Architectural Model (MAF) and any subsequent Systems Engineering modeling activities. MAF permits the modeling of 'system‐of‐systems' and they both facilitate the capture of the high‐level properties of a system's interfaces. However, how is this critical information communicated to an organization contracted to develop the real system? How does an organization ensure traceability from MAF artifacts and any subsequent Systems Engineering artifacts? In addition to heavyweight and lightweight mapping, SysML offers bridges that provide traceability between artifacts in MAF and any subsequent system specification. The concepts used by the different languages are examined as well as mapping from MAF to SysML. Then this paper explores allocation and requirements traceability. Due to the inherent extensibility of a UML‐based model, properties not prescribed by MAF (‘Risk’) can be added to a MAF and the two approaches to flow‐down can be augmented with these domain specific properties.
8.3.3 Enterprise Domain Modelling Process Using SysML for the Tooling Enterprise at the U.S. NNSA's Pantex Plant
Authors: Griego Regina M. , Mayes Larry M. , McGrath Daniel A. 
Published: November 2014

AbstractThis paper describes the process and methods applied in modelling an enabling enterprise within the NNSA Pantex Plant within the U.S. Nuclear Weapons Complex. The process used is based on the Enterprise Domain Modelling and systems analysis methods enabled by Systems Modelling Language (SysML). SysML consists of four types of views to describe a system: structure, requirements, parametrics, and behavior (INCOSE, 2006). The model illustrated behavioural viewpoints of the tooling enterprise.
9.2.2 Object‐Oriented Systems Engineering Method (OOSEM) applied to Joint Force Projection (JFP), a Lockheed Martin Integrating Concept (LMIC)
Authors: Friedenthal Sanford , Izumi Lisa , Meilich Abraham 
Published: November 2014

AbstractA Lockheed Martin Team is developing an enterprise architecture to specify a Joint Mission Capability Package for Next Generation Long Range Strike (NGLRS) in support of Major Combat Operations. The modeling approach leverages the Object‐Oriented Systems Engineering Method (OOSEM) and the newly adopted Object Management Group Systems Modeling Language (OMG SysML™) using the I‐Logix Rhapsody modeling tool. The preliminary modeling effort resulted in a model of the enterprise architecture and an executable architecture to support behavior analysis and simulation. The analysis and simulation are intended to allow JFP to validate customer and mission requirements and develop and demonstrate System of Systems (SoS) architecture solutions. A brief overview of SysML is included in the paper; however, those who are not familiar with SysML will benefit from a review of the OMG's SysML Tutorial [3].
9.2.3 Standardized Process as a Tool for Higher Level Systems Thinking
Authors: Lamb Caroline Twomey , Rhodes Donna H. 
Published: November 2014

AbstractStandardized processes are being used to address three issues in engineering today: increasing system complexity; shifting demographics; and longer development cycles that result in a dearth of experiential learning for young engineers. There is obvious value in having engineers who can see the big picture and effectively broker design tradeoffs: engineers capable of systems thinking. However, what is the impact of standardized processes on the ability of teams of engineers to make these critical tradeoffs? This paper lays the groundwork for research investigating ways in which standardized process usage facilitates or hinders systems thinking within engineering teams—termed collaborative systems thinking.
10.1.1 Capability Engineering: Learning from Practice
Authors: Lalancette Claire , Lizotte Michel , Nécaille Christophe , Pagotto Jack , Robbins Wayne , Waruszynski Barbara 
Published: November 2014

AbstractFor over four years, Defence R&D Canada has been investigating Capability Engineering, which aims at supporting the Capability‐Based Planning (CBP) decision‐making process, under the Collaborative Capability Definition Engineering and Management Technology Demonstration (CapDEM TD) project. Based on the systems engineering paradigm, the approach is articulated around three axes: People, Process and Materiel. This paper presents the results of an experimental evaluation conducted to assess the CapDEM approach to Capability Engineering. The focus is on the lessons learned from Exercise Beta, the second of three validation exercises which are part of an evaluation strategy attempting to evolve capability engineering from theory into practice.
11.1.2 Systematic Enterprise Definition
Authors: Grady Jeffrey O. 
Published: November 2014

AbstractOne prerequisite to enterprise improvement is management awareness of the enterprise current process, organization, and the relationship between these entities. That is, the enterprise must define itself as a system capable of satisfying a pre‐defined enterprise functionality using a particular organizational entity structure derived from that needed functionality. If this sounds familiar, it should because it is precisely the way system engineers have defined product systems for many years applying traditional structured analysis. The same methods used to define large product systems can be employed to define enterprises and their programs which are, after all, process systems. This paper describes how this process can be employed to re‐engineer an enterprise that has been found to be inefficient. It is not suggested as a way to originally engineer an enterprise, though it will work in that context, because enterprises are commonly formed by entrepreneurs who seldom have a lot of interest in organized ways of thinking. Over time, however, an initial success will often expose a need for better discipline and efficiency.
Effective industrial modeling for high‐tech systems: The example of Happy Flow
Authors: Beckers J.M.J. , Muller G.J. , Heemels W.P.M.H. , Bukkems B.H.M. 
Published: November 2014

AbstractIn the design of high‐tech systems like copiers, wafer steppers and televisions, modeling plays an important role. However, not all developed models are industrially successful. It would be very beneficial if guidelines were available on how to create industrially effective models that support the system architects and speed up the multi‐disciplinary design of high‐tech machines. In this paper, we describe a very successful industrial model in the context of the design of copiers. The model is developed for the design of the paper transport system (the mechanical layout of the paper track, the schedule of print jobs, sensors, actuators, etc.) in a multi‐functional office copier. As most other activities in the printer are synchronized to the paper transport system, this design issue is at the heart of the overall design and has a major influence on the total functioning of the machine. The so‐called Happy Flow model is based on kinematic modeling and its generic elements are not restricted to copiers only. Its main ideas are applicable to a much wider range of mechatronic products. It is important to learn from such instances of successful industrial models. The aim of this paper is to identify the success factors of this particular model, which forms a first step towards a more systematic method on how to construct industrial effective models.
1.3.1 Measuring Systems Engineering Success: Insights from Baseball
Authors: Blackburn Craig , Valerdi Ricardo 
Published: November 2014

AbstractOptimizing the efficiency of socio‐technical systems and determining accurate measurements of performance is a critical issue in many systems engineering enterprises. In our analysis we explore some of the recurring themes of Michael Lewis's study of baseball, depicted in the best selling book Moneyball, and we make the connection to corresponding systems engineering principles of interest. The paper will focus on the systems engineering roadmap inspired by Lewis' study for developing and refining a meaningful set of metrics for organizational transformation. The following steps are highlighted to convey this transformation with the assistance of metrics: identify and understand value in the enterprise and your organization; consider an integrated system focus in your organization; use cost analysis methods to implement a strategy for executing the transformation; and manage risk throughout operations and improve the process continuously.
1.4.3 A Sustainable Energy Economy: The Next Challenge for Systems Engineers
Authors: Snyder Neil 
Published: November 2014

AbstractThe realities of shrinking fossil fuel reserves, growing global energy demand, and climate change concerns will force a change to a sustainable energy economy. Systems engineers need to take a leadership role in making the transition to this new energy economy. A study of large projects from the past provides some insights into methodologies that might be used to effect this transition; however, the complexity of the energy transition is far greater in some respects than on these earlier projects. The timeframe of this transition is measured in decades, the technologies involve numerous industries, and the spatial dimension involves the entire planet. Systems engineers will not only need new tools but will need to step into somewhat different roles than in the past. It is time to start planning for these new challenges, and INCOSE should play a key role in this planning.
1.5.0 Architecture Concepts, Principles, and Terminology
Authors: Malhotra S , Dickerson C E , Martin J , Bendz J , Martin R , Sillitto H , Wilkinson M , Ring J 
Published: November 2014

AbstractAn invitational workshop at the January INCOSE International Workshop (IW08) was held to clarify the concepts, principles and terminology for the architecture of systems and enterprises. The results of this workshop have served the needs of several groups: the two ISO standards committees dealing with architecture, TC184/SC5/WG1 and JTC1/SC7/WG42, the Model Based Systems Engineering initiative, and various INCOSE Working Groups. Attendees of this panel will learn the outcome of recent debates on concepts, principles and terminology and how they have helped the progress of the ISO groups and other stakeholders in this critical domain.
2.3.2 COSYSMO Reuse Extension
Authors: Wang Gan , Ankrum Aaron , Valerdi Ricardo , Millar Cort , Roedler Garry J. 
Published: November 2014

AbstractReuse in systems engineering is a frequent, but poorly understood phenomenon. Nevertheless, it has a significant impact on estimating the appropriate amount of systems engineering effort with models like the Constructive Systems Engineering Cost Model. Practical experience showed that the initial version of COSYSMO, a model based on a “build from the scratch” philosophy, needed to be refined in order to incorporate reuse considerations that fit today's industry environment. The notion of reuse recognizes the effect of legacy system definition in engineering a system and introduces multiple reuse categories for classifying each of the four COSYSMO size drivers – requirements, interfaces, algorithms, and operational scenarios. It fundamentally modifies the counting rules for the COSYSMO size drivers and updates the definition of system size in COSYSMO.In this paper, we present (1) the definition of the COSYSMO reuse extension and the approach employed to define this extension; (2) the updated COSYSMO size driver definitions that are consistent with the reuse model; (3) the method applied to defining the reuse weights used in the modified parametric relationship; (4) a practical implementation example that instantiates the reuse model by an industry organization and the empirical data that provided practical validation of the extended COSYSMO model; and (5) recommendations for organizational implementation and deployment of this extension.
3.2.2 What is wrong with Reliability Engineering?
Authors: Barnard R.W.A. 
Published: November 2014

AbstractNotwithstanding the implementation of reliability engineering programs by companies, it is not uncommon to observe many instances of low field reliability. This paper briefly describes the essence of reliability engineering, which has prevention of failure as primary objective. Possible reasons for the apparent failure of reliability engineering, especially as practised by the defence industry, are given. It argues that incorrect practices are often applied, frequently performed by incorrect people in the organisation, and at the incorrect time during the product or system life cycle. The value of reliability engineering as specialty area of systems engineering can be improved by learning from best practices used by industry leaders.
4.1.0 Systems Acceptance for SoS: Rail/Transit Case Studies
Authors: Hayward‐Williams C , Halliday B , Brouwer P , Hodges B 
Published: November 2014

AbstractRail/Transit systems are effectively comprised of many layered and complex systems – hence a System of Systems (SoS). Upgrading, expanding and modernizing rail/transit systems becomes a complex endeavor as portions of a rail/network are modified and then must ultimately be accepted as a complete, operational system before being introduced/integrated back into the rest of the active rail network. The multi‐layered system acceptance creates challenges that relate to planning, modeling, contracting and deployment.SE practitioners across all industries are urged to join this SoS exchange based on rail/transit case studies and offer comparative or contrasting experiences from their domains.
4.2.2 Technology Readiness Assessment a Systems Engineering Process to Ensure All Your Pegs and Holes are Round Before Beginning Development
Authors: Walker John Bryan 
Published: November 2014

AbstractTechnology insertion can be like trying to fit a square peg into a round hole if the technology is not mature enough for the system beginning development. The Technology Readiness Assessment (TRA) is a process that takes it's pedigree from NASA. NASA needed a systematic approach to assess the maturity of a particular technology and a consistent comparison of maturity between different types of technology. An approach using Technology Readiness Levels (TRLs) was institutionalized when it was incorporated in the NASA Management Instruction 7100 [Mankins 1995]. This was the beginning of the TRA process. It is now a readily accepted Systems Engineering process for all major U.S.A. Department of Defense (DOD) acquisitions. The use of the TRA is expanding and should be considered for systems being considered for the sustainability of the planet. The TRA is best used up front before system development when deciding on competing technologies to be used and before production when deciding if technologies have matured enough to insure production feasibility. In this paper I shall discuss the key components of the TRA, the identification of Critical Technology Elements (CTE)s and the evaluation of those CTEs against a Technology Readiness Level scale. The purpose of the discussion is to expand the use of the TRA into other Systems Engineering technology intensive domains where continuous systems development is being performed.
4.3.1 Demonstrating professionalism through competency assessment
Authors: Holt Jon , Perry Simon , Currie Malcolm 
Published: November 2014

AbstractIn order to be successful in business, it is essential that we can inspire our clients with confidence. This confidence must exist at both the organisational and individual level. As practising systems engineers, it is essential that we are able to demonstrate our professionalism in everything that we do and, hence, inspire confidence in our colleagues and clients.This paper looks at the issue of professionalism through competency assessment. The INCOSE competencies framework is used as an example of a good best‐practice model and an assessment process, known as UCAM, is introduced and discussed.A real‐life industrial case study taken from the rail industry is presented which discusses the practical business benefits of effective competency assessment and some actual results are presented. Finally, some general comments and observations are included regarding the INCOSE competency framework.
4.3.3 Capability Engineering within Canadian Defence: Experimentation and Lessons Learned
Authors: Lalancette Claire , Lizotte Michel , Nécaille Christophe , Robbins Wayne , Waruszynski Barbara 
Published: November 2014

AbstractThis paper summarizes the results of an experimental evaluation conducted to assess the Capability Engineering approach developed for the Canadian Forces/Department of National Defence to facilitate decision‐making on strategic investments and divestments. This work was performed as part of the Collaborative Capability Definition, Engineering and Management Technology Demonstration Project (CapDEM TDP). Based on the systems engineering paradigm, the approach is articulated around three axes: People, Process and Materiel. The focus of this paper is on the lessons learned from Exercise Gamma, the last of three validation exercises which are part of an evaluation strategy attempting to evolve Capability Engineering from theory into practice. Lessons learned have helped to identify specific improvements as well as critical success factors for the implementation and application of Capability Engineering.
5.1.2 Designing Embedded Systems using Heterogeneous Rich Components1
Authors: Josko Bernhard , Ma Qin , Metzner Alexander 
Published: November 2014

AbstractThis paper aims at boosting the level of re‐use in embedded system design. A key concept to achieve this goal is given by an appropriate heterogeneous rich component model – called HRC – which is (1) expressive enough to cover the complete development cycle from high‐level specifications to design models and which (2) addresses both functional and non‐functional aspects. HRC components are characterized by formal contracts allowing various analysis techniques to validate a design already in early design stages. The described approach has been developed jointly with the partners of the SPEEDS project.
6.2.1 Function Durability over System's Life Span
Authors: Gasser Laurent 
Published: November 2014

AbstractThis paper presents some of the heuristics that a system architect could use to preserve the full operational potential during the system's intended life span, and beyond. The proposed heuristics prevent a single subsystem from severely limiting the evolution and maintenance potential of the whole system. The durability of the system's function ought to have precedence on the subsystems' own evolution, resulting in improved system robustness. The scope of function durability is first exposed. Side topics are then examined and the way they relate to the system viability is discussed. The second part introduces the proposed heuristics. Rationale and illustrations are given for each of them.
9.2.1 Using SysML and UML To Develop and Implement Interoperable System Components for Engagement Simulations
Authors: Haley Thomas , Cerenzia Judith , Diederich David , Friedenthal Sanford 
Published: November 2014

AbstractThe Torpedo Enterprise Advanced Modeling and Simulation (TEAMS) project is an initiative funded by the Office of Naval Research to develop a cross‐enterprise, collaborative undersea warfare modeling and simulation (M&S) environment using reusable components that can be composed into simulations. This environment will include an open systems architecture and result in the sharing and leveraging of legacy and new‐development resources; it will support the development of M&S tools and the application of these tools across the lifecycle of undersea weapons. TEAMS initial model was delivered in the Unified Modeling Language (UML). When the Object Management Group (OMG) adopted the OMG System Modeling Language (OMG SysML™) specification, the Open Systems Joint Task Force of the Office of Secretary of Defense funded TEAMS to assess the utility of applying SysML in place of UML. This paper describes the torpedo M&S domain as it relates to TEAMS, discusses the application of SysML to existing UML artifacts, and assesses the utility of SysML from the TEAMS perspective.