bluuebunny/crossref_metadata_2025_split huggingface dataset:
NAVY LEGACY SYSTEMS REENGINEERING
Authors: Wilson Mark L. 
Published: November 2014

AbstractLegacy systems abound in the Navy. In many cases it is infeasible or ill advised to develop new systems from scratch. Yet due to new system requirements, increasing maintenance costs, or other reasons it is desirable to somehow replace or upgrade these systems. There is also a desire to capture some of the capabilities inherent in these systems and somehow reuse them. This paper looks at some of the issues involved reengineering, and in particular those that tend to be unique to or more pronounced in Navy systems. It also briefly describes some progress that has been made using language translation to facilitate reengineering of Navy systems to open architectures.
Discovery & The Change Control Process
Authors: Oliver David W. 
Published: November 2014

AbstractThis paper describes the change control process that is essential for engineering projects to cope with requirements changes imposed from outside the program and to cope with the internal discovery of issues that require the engineering work be altered.The engineering life cycle has been described in the literature by a waterfall model, which emphasizes top down development, and a spiral model, which emphasizes prototyping. Engineering developments in the real world follow neither of these models. In the real applications world the engineering work follows a nominal forward process which can be described rigorously with models, (Oliver 1994a).One step of that rigorous process considers multiple product releases, risk remediation, and partial builds for early validation testing. Prototypes are built to a schedule to meet these project needsIn real applications the forward process is never followed without interruption. Customers discover that requirements must change, engineers discover technical problems, and management discovers need for funding and schedule changes. These changes can cause the engineering work to be interrupted at any step of the forward process and to be resumed at any other step of the forward process. Since the work is interrupted at any step and may resume at any other step, these impacts cannot be described in a work flow diagram because it would show recursion from every point back to every other point.The real engineering work conditions can be rigorously described with a forward process combined with a change process, (Oliver 1994b). The change process provides for identification of the need for change, change impact assessment, change authorization, change planning, change execution, and process improvement based on analysis of change causes.
1 EVALUATION IN THE SEDRES PROJECT: Measuring the Effectiveness of Model Data Exchange between System Engineering Tools: Ninth Annual International Symposium of the International Council On Systems Engineering (INCOSE) June 6–10, 1999
Authors: Harris David , Candy Linda 
Published: November 2014

ABSTRACTThe System Engineering Data Representation and Exchange Standardisation (SEDRES) Project is a European initiative towards the development of a standardised data exchange capability for use between the different tools used in System Engineering. A significant issue arising from the Project is the usability of such a data transfer capability, and its effectiveness in the System Engineering process, especially in its application in the support of Integrated Product Teams. This paper addresses the Test & Evaluation programme within SEDRES and its focus on the Usability issues for tool data transfer. It concludes with a comparison of the SEDRES capability with a proposed Integrated System Engineering Environment (ISEE) Model set out in a 1996 INCOSE report (INCOSE 1996).
1 A Plug‐and‐Play Early Validation Module
Authors: Larsen Bob , Buede Dennis 
Published: November 2014

ABSTRACTIn the complex world of developing requirements and eliciting user needs, engineers build billions of dollars of products that are wrong on delivery, because they solved the wrong problem. All technical people need specialized techniques and processes to increase the probability of developing the right products in the future. Everyone discusses the importance of getting the stakeholder involved, but the present techniques do little to address this problem. Presently, validation is the stakeholder's only mechanism to test that the developer is building the right product. Validation is the process of testing for technical appropriateness and adequacy near the end of the system life cycle process. An Early Validation (EaVa) module will stablize the problem statement, which will enhance the probability of technical appropriateness and adequacy. EaVa can be used continuously, developing requirements, or for the preliminary design phase depending on the system and the stakeholder's needs. EaVa tries to ensure the engineers are solving the right problem prior to the majority of the resources being committed late in the design phase. A critical piece is getting user feedback, based on this EV step, from independent agents or engineers within the process.
2 Design Integration “Testing” from Concept to Support
Authors: Blake A. T. 
Published: November 2014

AbstractThe value of modelling and design prototyping in the early phases of the systems engineering life cycle is well understood, as is the use of specialist test facilities for design verification during development and to confirm system behaviour and performance prior to delivery. This paper identifies that significant business advantage can be gained through the integration of these various design evaluation activities. The use of an integrated test and evaluation strategy, supported by a model integration environment, is proposed as a means of achieving this objective. The key concept discussed is that of a “virtual” rig.
2 An Integrated Model for Characterizing & Managing System Architectures
Authors: Steiner Rick 
Published: November 2014

AbstractThe term “architecture” is widely used in systems engineering circles, but the explicit meaning of the term varies considerably from person to person, depending on expertise and viewpoint. A previous paper (Steiner '98) defined the term with respect to system evolvability. This paper attempts to clarify architectural characteristics by defining three orthogonal axes:
Expression (form/function),
Permanence (enduring/transitory), and
Abstraction (abstract/concrete).
Segregating a given architectural concept into these three key areas of concern facilitates a balanced approach to managing system architectural models. It can also logically be extended as a mechanism for clear communication among stakeholders.
3 From research to development: specifying a future command and control system
Authors: Lamers Jessy , Streng Martin 
Published: November 2014

ABSTRACTWe present some experiences obtained with the definition and preliminary design of a new generation command and control system for military applications. We will concentrate on the transfer of research results to development. During this phase, requirements have to be specified for the new system for which it is still hard to envision in detail the desired tasks that it should support. At the same time, the new technologies that are to enable these new capabilities are not known well enough to completely understand their possibilities. We will outline some approaches that, in our project, helped to be creative at the right time and specific and decisive when needed. These are storyboard, natural language and formal methods. We will indicate for each of them at what moment they can be best applied.Finally, we indicate why any such approach used within a project does not guarantee widespread acceptance of its results by the remaining R&D population.
1 Embedded Systems, The Forgotten Y2K Problem
Authors: Fisher Gerard H. 
Published: November 2014

AbstractThe shortcut of early programmers has become one of the world's worst nightmares. Year 2000 (Y2K) problems exist in the most improbable places, from medical equipment like defibrillators and EEGs to building equipment that determines when it is time for maintenance. The Y2K problem in mainframe software is well known. The problems dealing with the microprocessors embedded in virtually all of our smart equipment is less apparent. This paper discusses the problem, the systems engineering process for identifying and remediating the problems, and some ways to use this remediation to add value to your systems.
2 A Systems Approach to the Year 2000 (Y2k) Issue
Authors: Moore Patrick D R , Fairbairn Allen G 
Published: November 2014

AbstractWidespread disruption has been predicted for businesses as the sins of programmers in the not too distant past are found out. The long term consequences of using only two digits for the year in date codes and other memory saving techniques are soon to be unavoidably upon us all. PC's and other electronic devices are relatively easy to check out and fix, although many people are still failing to do so. Less easy to track down and deal effectively with are the myriad types and numbers of embedded chips built into the equipment, machinery and control systems that have been installed and used world‐wide over the last twenty years or so. The real Y2k issue for businesses turns out to be contending with the unpredictable consequences of a widespread, common mode failure both within and outside of a company's legal boundaries. The paper describes simple means by which any business can be better prepared in order to withstand the effects of the millennium changeover. Basic systems engineering principles are described that produce the basis for understanding core business processes. A useful technique of dependency modelling can be used to prepare contingency plans and countermeasures. More importantly, the paper shows how vital it is to view a business as part of the greater business “system” of commercial activity – the extended enterprise concept or “system of systems” to which all businesses belong and which is the true focus for the Millennium bug problem.
3 Assessing Emergencies and Making Disaster Recovery Decisions
Authors: Riggs Donald A. , Botten LeRoy H. 
Published: November 2014

AbstractEmergency situations almost always present unforeseen situations and problems. Thus, effective mobilisation of business continuity and recovery (BC&R) resources surviving an adverse event requires assessment and analysis of the emergency situation to aid in crisis management.Costs associated with transition to BC&R operations and subsequent return to normal operations are often significant. Use of backup facilities, personnel, and data; and non‐standard operational procedures (including the transition process itself) increases the risk of operational error. Assumption of such risks and costs may be necessary following an adverse event; however, a decision to invoke BC&R operations should be an informed decision made by a designated senior manager.This paper offers systems engineering‐based methods and practices for facilitating rapid, accurate assessment following an emergency. The decision support tool described facilitates such assessment, provides recommendations for recovery action; and aids in planning, implementing, and approving transition to BC&R operations or restoration of normal operations.
1 R&D in Systems Engineering perspective
Authors: Bol Derk 
Published: November 2014

AbstractSystems Engineering is a structured and integral approach for the development of complex products and processes. Obtaining the knowledge and mastering new technologies necessary for the development of these products and processes is the subject of Research & Development (R&D).This article discusses the relationship between the various phases of product life cycle and the different types of R&D activities from a Systems Engineering point of view. It is shown that Systems Engineering helps to:
Clearly position R&D activities in the product life cycle
Make the goals of R&D activities clear for both the customer and the R&D team
Make the development of a new technology an integral part of the overall system development.
2 Whole Life Systems Engineering Research in Academia – a Position Report
Authors: Sydenham Peter H 
Published: November 2014

AbstractThis paper addresses a need for improved research support within the ‘Whole of Life’ aspect of Systems Engineering. A key element in the full profile of a mature Systems Engineering sector is the presence of a suitably supportive academic research activity. By surveying the current global scholarly contributions it is shown that much needs to be done to bring research for this area up to the baseline normally experienced in mature sectors. A short summary of the main Systems Engineering academic research programs that have been reported in USA UK and Australia show that some corrective actions are in place. It is also of interest to learn of the different approaches being used to address this need. Finally, generic recommendations are given that are considered to be needed to assist Whole Life Systems Engineering research support reach the normally expected performance available from academia.
3 Systems Engineering applied to a Research Management Process
Authors: Burdett Stuart , Rawlins Richard 
Published: November 2014

AbstractThis paper describes a process, based on systems engineering principles, that is being used by the UK MoD to select research to meet the changing needs of its existing land combat vehicle fleets and its future combat vehicle‐system procurements. This selection process addresses operational uncertainty, system complexity, international collaboration, changing procurement approaches and yet remains flexible enough to exploit technology opportunities as they arise. The research being managed encompasses system integration, technology development and ‘pure’ technology research.
1 Function Based Design Of Complex, Complicated Systems
Authors: Shell A D 
Published: November 2014

AbstractThe ‘top‐down’ system design process of functional decomposition is increasingly being criticised as simplistic, outmoded, and (in particular) too ‘reductionist’. Its use on large, complex systems is frequently portrayed as naive and impractical. There is much comment on the need to concentrate, instead, on the ‘emergent behaviours’ of systems, and to adopt a ‘holistic’ design approach in which a system solution is ‘evolved’ through a process of system design synthesis.This paper presents a counter‐argument that top‐down design decomposition can, in fact, be a highly efficient way to produce good (optimal) system solutions .Many of the fundamentals of function based system design are addressed: the central role of system function in the design process; the characterisation of system complexity and complication; the identification and specification of component requirements; and the determination of optimal design solutions.An established mathematical theory of systems design, using formal constructs and set‐theory notation, is used as the basis for the presentation of ideas.
2 SYSTEM THEORETIC PORTENTS OF PREDISPOSITION TO SYSTEM FAILURE
Authors: Wymore A. Wayne 
Published: November 2014

AbstractThis paper is the first in what will be a series of papers concerned with system failure traceable to decisions taken at a level of specification above that of bioware/hardware/software components, failure ascribable to faulty requirements and architecture. The style of discourse is informal but the results are based on research in the mathematical, system theoretic foundations of systems engineering wherein rigorous mathematical structures for system requirements and designs have been established: input/output, functional, technology, performance, cost, tradeoff and system test requirements and functional, buildable and implementable system designs generated by these requirements. The results in this paper have been deduced from examples and counterexamples representing instances of the general structure of requirements and system designs. Discussed herein, is predisposition to system failure from the following sources:
Completeness of problem statements.
Simplification of system requirements.
System functional analysis.
Coupling of implementable system designs.
1 A Method for Design and Analysis of Next Generation Aircraft Computer Systems
Authors: Grigg Alan , Audsley Neil , Fletcher Martyn , Wake Allan 
Published: November 2014

AbstractNext generation aircraft computer systems require a major advance in system design practice and associated methods of analysis compared to even the most modern aircraft systems now in service. As well as the ongoing need to demonstrate predictable, real‐time behaviour for a wide range of safety critical and mission critical applications, a significant improvement in flexibility is required in order to support cost‐effective design‐time and in‐service modifications to the system. The system design and analysis problem is further complicated by a trend towards increasing functional and physical integration. In this paper, we address the temporal aspects of the problem and propose a design/analysis approach based on resource reservation. This supports top‐down development by incorporating only appropriate timing information at each stage of development and defering the use of implementation details until absolutely necessary. At each stage of refinement, the system model supports localised changes with minimal re‐analysis, thus minimising the impact (and associated cost) of such changes.
2 A new approach to marine programmable systems assessment
Authors: Earthy Jonathan , Register Lloyd's 
Published: November 2014

AbstractIncreasing reliance on complex, computer‐assisted systems presents a problem for most maritime stakeholders. The combination of complexity, use of computer hardware and software, and sector practice in the purchase and operation of computer‐based systems leads to a wide range of potential defects which cannot be guarded against by prescriptive standards.The EC ATOMOS II research project has developed a total system, human‐centred, risk‐based, through life approach to the specification, design, introduction and use of operationally effective and commercially efficient marine systems, including the use of programmable electronic systems (PES). This is presented in a new standard from ISO which will have a far‐reaching effect on the design and operation of marine transport.The rationale for a new approach to the development, use and assessment of marine PES and a new ISO standard which embodies this rationale are presented. The industrial impact is outlined.
4 The Importance of Animation with UML
Authors: Dockerill Kevin 
Published: November 2014

AbstractIn order to understand the diverse requirements for large complex and highly integrated real time embedded systems, System Engineers have recognised the benefits of representing requirements using graphical notations with animation.Animation has been used for different aspects of systems, which include control, moding, mechanical, fluid mechanics and algorithms.Tools have been developed to support each type of system. However, if we wish to fully exploit model based tool notations as part of the System and Software Development then we need an overall design framework for the System.UML has the potential to describe such a framework using a common notation for both Systems and Software Engineering. The notation supports architecture, behaviour and functional views of the system.However, experience with animated tools has led to view that UML tools must also be developed to support animation of the design in order to maximise the benefits in adopting UML for the systems and software development of real time embedded systems.This paper aims to identify the need for animation, through experience within BAe, the need for UML and the role of animation with UML tools.
2 Multinational Requirements Handling
Authors: Smith Craig N. , Dynamics Matra BAe 
Published: November 2014

AbstractThis paper discusses an approach to requirements handling that is based on seeking flexibility and adaptability. It is particularly suitable for multinational programmes which are characterised by differences in requirements.Several aspects must be considered coherently within a systems engineering approach to provide a solution with sufficient flexibility and adaptability. Firstly, the correct environment is required to remove preconceptions about the solution and discover the underlying need. A joint requirement management process between customer and industry can achieve this, provided requirements are set at the correct level. In turn, this requires that the boundaries of the problem are challenged, particularly the interaction of the system characteristics and the concept of employment. Finally, the whole process will fail without the correct team principles and enlightened communications.
1 Systems Engineering and Information Management ‐ a Local Need in a Global Perspective
Authors: Fossnes Terje 
Published: November 2014

AbstractThis paper addresses several concurrent initiatives within the Royal Norwegian Navy Materiel Command, and how information available world‐wide have been utilised. This includes use of the Systems Engineering tool RDD‐100®, IEEE STD 1220–1994, results from NATO CALS, the SE‐CMM and SWOT analysis. The activities performed affect the Norwegian Navy's New Frigates project as a pilot for new processes and information management. The paper culminates in an integration of the initiatives into an overall interdisciplinary process‐model for future implementation of identified needs with respect to information handling in an Enterprise Resource Planning (ERP) system. Finally some lessons learned from the initiatives are addressed.
2 Integrating Human Factors within Systems Engineering
Authors: Ward George , Harmer Steve 
Published: November 2014

ABSTRACTThe need to re‐focus attention on Human Factors issues in Systems Engineering has recently taken fresh impetus in the UK, as the cost‐effectiveness of the human element in defence system procurement has been reconfirmed as a critical component in achieving fielded system success.British Aerospace Military Aircraft and Aerostructures (MA&A), in conjunction with the BAe Sowerby Research Centre, has for the past five years been engaged in activities aimed at ensuring that their Systems Engineering process improvement plans take full account of customer driven Human Factors Integration (HFI) requirements. These include the need to identify and manage all aspects of human involvement in the system lifecycle in order to ensure a balanced application of human and machine resources. The overriding aim being to optimise total system cost‐effectiveness.This paper reports the status of these activities and describes the background to this work, the goals of HFI, the BAe initiatives undertaken and gives a personal view of the way forward to the successful integration of HFI principles into systems engineering.
3 Collaborative Software Process Data Collection: BAe and Roll‐Royce's Experience of Sharing a Measurement Philosophy
Authors: Clark Graham D. , Powell Antony L. 
Published: November 2014

AbstractAs the Aerospace Industry increasingly moves to an environment where the development of its processes and products take place across company boundaries, the need for an understanding of how they will share process and product data is vital. BAe and Rolls‐Royce are collaborating on such an enterprise and this paper reports on a pilot collaboration from an engineering perspective. As a result of exchanging best practice in Software Metrics between BAe MA&A and Rolls‐Royce, a decision was made to begin to use the Process Engineering Language (PEL) across the two companies to gather metrics in a consistent format. The goal was to find out if the same measurement philosophy could be used to assess differing Real Time High Integrity Software development strategies and to see if different working practices produce similar costs and results.