Concept Exploration Phase Paper: Systems Engineering Process

Anonymous
timer Asked: Feb 20th, 2019
account_balance_wallet $60

Question Description

Systems Engineering Process, Part 2

Part 2 extends the Part 1 work that addressed the needs analysis phase and takes the system

through the concept exploration phase. In Part 1, you built a case to justify initiating the

development of a new system that provides a solution to a problem that you identified. Part

2 explores a broad but differentiated set of system concepts to meet the need.

Starting with the Part 1 paper, update the paper according to instructor feedback and

additional lessons learned in the course. Additional updates may also be needed as you

continue through the rest of the concept development phases, as this is an iterative process.

For the concept exploration phase, first identify the functions that the system will need to

perform. These should be categorized into the following:

  • Input functions
  • Transformative functions
  • Output functions
  • These functions should be defined no further than needed to describe the system and what the

    system needs to do (at the system level).

    Next, develop a system context diagram using the following guidelines:

  • The system context diagram provides the boundary of what is in the system and what
  • is outside of the system

  • The system context diagram shows the key external system interfaces and provides
  • unique labels for all the interfaces and external entities

  • The system context diagram includes primary users, maintainers, trainers, and other
  • stakeholders that interface to the system during the operational phase

  • The system context diagram includes the environmental interfaces (input and output)
  • The system context diagram includes an interface to its energy source
  • The system context diagram addresses signals, data, materials, energy, and forces (as
  • applicable)

    Then define a top-level functional block diagram. Guidelines for the top-level functional

    diagram are:

  • There should be about three to six functions at this level (with some exceptions
  • possible)

  • The functional block diagram should show all the inputs and outputs of the system
  • going to and from at least one of the functions (or to the whole system, if applicable)

  • There should be internal interfaces between at least some (if not all) of the functions
  • inside the system; and these interfaces should be labeled uniquely (different names)

    from the system inputs and outputs

  • Functions should be labeled using verbs
  • Every function should have at least one input and one output
  • Next, develop the functional and performance requirements. That is, the functional

    requirements cover what the system has to do to meet the need, and the performance

    requirements cover how well the system has to perform those functions. Functional

    requirements focus on the capabilities of the system. Performance requirements address the

    characteristics of the system and include a quantitative measure.

    NOTE: You probably do not have subject matter expertise in the system domain that you

    chose, and so the performance requirements can be stated with TBD values or estimated

    ranges.

    For the last part of the concept exploration phase, define a broad differentiated set of four to

    eight system concepts that will be considered. A hybrid of concepts is acceptable as its own

    concept (bridge, tunnel, island combination). These system concepts can be upgrades to

    existing systems, new COTS or technology driven systems, an integration of various existing

    technologies or approaches in a unique way, or other unique or creative system solutions.

    Guidelines include:

  • The concepts address the operational, functional, and performance requirements
  • Four to eight different kinds of concepts are considered; one or two can be hybrids of
  • the other concepts

    The paper should demonstrate your understanding of the Kossiakoff systems engineering life

    cycle. The Part 2 portion of the paper should be about 3 - 5 pages long (not counting charts,

    figures, title page, reference list, etc.).

    Make sure to add a title page to your paper and include your references (on the last page).

    Feel free to use an APA format or another citation format of your choosing.

    Concept Exploration Phase Paper: Systems Engineering Process
    screen_shot_2019_02_20_at_8.37.06_am.png
    Production and Deployment Operations & Maintenance Documentation System Production Specifications Production & Deployment Integration & Evaluation Operation & Support Tooling & Test Eqpt. Production & Accept. System Delivery Production System Installed Operational System Unit 17 Reference : “Systems Engineering, Principles and Practice,” Kossiakoff et. al – Chapter 14 Production: We have a product, what’s left to do?  Goals:  Reproduce what has been designed and proven  Get the product to the customers  End Result:  Products  Happy customers 2 Production Phase in the System Life Cycle 3 Production Phase Overlap with Adjacent Phases System & Subsystem integration System Test Integration & Evaluation Phase Operational Evaluation Transition to Production Material Procurement Production Engineering Low Rate Production Full Production Production Phase Operational Introduction Installation & Test System Operations Operation & Support Phase 4 Starting Points for Production  Proven Design  Prototype(s) that have been tested and shown to meet the specifications  Specifications  Drawings  Documentation  Supportability Plans 5 System Engineering Method in Production Product Specifications Proven System Current User Environment Constraints Leftovers From Development  Requirements Analysis  Determine whether the requirements and drawings are ready for production  Identify whether requirement changes are needed  Define acceptance of the produced product 6 System Engineering Method in Production Product Specifications Proven System Current User Environment Constraints Leftovers From Development  Requirements Definition  Define new requirements and tests needed to verify them  Done in context at the right level of specification  System  Subsystems - Components 7 System Engineering Method in Production Product Specifications Proven System Current User Environment Constraints Leftovers From Development  Physical Definition  Configuration management  Manage changes to the production articles 8 System Engineering Method in Production Product Specifications Proven System Current User Environment Constraints Leftovers From Development  Validate Requirements  Ensure end product meets the acceptance criteria for delivery  Ensure changes are verified against original/revised requirements 9 Engineering For Production  How you build something is as important as what you are building  If you can’t reproduce it, it may be useless  Many considerations…  Number of systems to build  Manufacturing considerations  Procedures  Processes  Equipment  Deployment/distribution considerations  Logistics support considerations  Configuration and document control considerations (e.g., engineering changes)  These should be considered from the beginning of the project starting with the needs analysis! 10 Manufacturing Considerations (1/3)  Case 1: The development system is the production system  Case 2: Copies of the development system need to be produced  2A: Few copies  2B: Many copies  2C: Software 11 Manufacturing Considerations (2/3)  Limited Production Line Resources  Vendor facilities & personnel  Limited facilities worldwide  Advanced integrated circuits  Exotic materials  Large components  Long Lead Components  Some parts take from months up to years to buy  Specialty products  Obscure connectors  Custom integrated circuit products 12 Manufacturing Considerations (3/3)  Tooling  Building 1 unit may be acceptable to build hand-crafted  May not be economical to build ten units that way  Develop and build special tooling  Factory Test Equipment  Same as tooling – may want to build if producing in quantity 13 Logistics Support Considerations  Maintenance  By the manufacturer/vendor or the user?  Affects documentation that needs to be produced and delivered  Affects training to be developed – in-house or user self-train?  If user maintenance…  Generally more documentation needed for user self support  User may need special test equipment  Spare Parts  Initially delivered with a system  Built and stored for future needs  Depends on product lifetime, time committed to support product  Long term plan for obsolescence  Proactive or reactive 14 Logistics Maintenance Approach Effects Production  Throwaway item?  Need to assume that more spare assemblies will be purchased  Fixed Item?  May need different repair parts to fix the assemblies  Also need to consider what test capabilities are needed where  How many repair centers?  Whether to allow for repair or broken components and location(s) for doing the repair are usually based on a life cycle cost estimate  What is the cheapest approach? 15 Transition from Development to Production  Continuity of operations is critical during transition to Production  System production plan is the “blueprint” for the transition  Engineering and manufacturing facilities are usually separate and independent  Responsibilities transferred from engineering personnel to manufacturing specialists  Configuration management process must keep step with engineering change process  Systems engineers play a key role in facilitating a smooth transition  Facilitate communication between engineering and production personnel  Ensure the integrity of the system design  Resolve unexpected problems with component incompatibilities or components using advanced technologies 16 Production Operations  System Production Plan – the ‘blueprint” for system production and operations … key elements include:  Delivery schedule for each major component/sub-assembly  Engineering release schedule  Fabrication requirements  Tooling requirements  Test equipment/requirements  Quality control processes  Assembly  Acceptance testing  Packaging and shipping  Production readiness reviews  Overall schedule and cost estimates 17 Production Operations Standard Components Production Production Suppliers Developed Components System Production Production Assembly Integration Acceptance Test Engineering Products Users Production Engineering Legend: Engineering Subcontractors Prime Contractor Shipping Coordination 18 Production Knowledge Base  Acquiring knowledge of the suitability of specific components to meet the requirements of specific system applications can be achieved effectively by focusing on  Components that use advanced technologies, such as  Electronics Components  Electro-optical Components  Electro-mechanical Components  Mechanical Components  Thermo-mechanical Components  Recently developed or changing production processes  Risk areas that have been previously identified  Software Components 19 Other Tasks for the Systems Engineer in Production       Estimate risk Provide inputs to estimate the needed schedule Provide inputs to estimate the cost Address user feedback Recommend who is needed to support the project Maintain good system engineering processes  i.e., Configuration management, etc.  Recommend course of action for technical issues 20 System Engineering Products in Production  Recommendations for technical approaches to resolve required changes  Solution approach  Regression test plans  Information for the program manager     Candidate actions/plans Schedule Risk Cost  Recommendations for product improvements 21
    Operations and Support Operations & Maintenance Documentation Disposal Plan Operation & Support Production & Deployment Disposal System Operation Logistics Support System Upgrades Obsolete System Installed Operational System Unit 18 Reference : “Systems Engineering, Principles and Practice,” Kossiakoff et. al – Chapter 15 Operations and Support in the System Life Cycle – The Users Get Their Product Operational Deficiencies System Functional Specifications Concept Development Technological Opportunities System Production Specifications Engineering Development Defined System Concept(s) Operations & Maintenance Disposal Documentation Plan PostDevelopment Development Post Production System Installed Obsolete Operational System System 2 Operations and Support The Engineering is All Done, Right?  What about:  …Fielding the System?  Unleashing your system on an unsuspecting user  …Maintaining the product?  Fixing the system in the field  …Sustaining the product?  Keeping a supply of replacement components  …Upgrading the product?  Providing enhancements to keep the system useful New and Improved!! 3 Complex Systems Can Be In Use for a Long Time  Autos  Median age on the road is 8.9 years (2005 data)  Pioneer 10  Launched 1972  Last successful data transfer - 2002  B-52 Stratofortress  The youngest aircraft was delivered in 1962 - still in service  Software systems: Microsoft Windows XP )  Introduced in 2001  Some embedded applications still based on DOS (1981 4 Systems Engineering in Operations and Support  For routine system deliveries, operations and support  Often less of a direct system engineer role  Occasional routine efforts Degree of Systems Engineering  Higher level of effort while initially fielding Typical SE Tasks Casualty & Repairs System Installation System Upgrade Scheduled Maintenance Logistics Supply System Disposal – Update risk assessment – Address latent design defects or installation/operation problems – Make recommendations – How should a part that is no longer available be addressed? – Does system still meet the user need? 5 Fielding the System  There are many elements to delivering the system and making it operational  Infrastructure at the site to support the actual delivered system  Buildings, space, power, air conditioning, cabling  Installation & test (to make sure it works)  Documentation  Not just design specs and drawings  User & maintenance manuals  Training the personnel who will use it  Coordinating the integration of the new system with other already existing systems  Sudden switchover  Phase in of capabilities  These can all affect the requirements and implementation of what is delivered The Systems Engineer should ensure that there is a plan 6 Delivery Considerations  Complete delivered end item product  Assembled on-site  New system “Kit” includes everything new  “New” system is a modification to an existing item  System developer install  User install Many large-scale real-world systems are a combination of the above 7 System Installation and Test  Difficulty affected by amount of physical and functional integration accomplished at the production facility  High degree of integration: Largely self contained at delivery Vehicle – Saturn Vue Major Software Application – One set of install disks  Low degree of integration at delivery: Assembled in the field AN/FPS-115 Pave Paws Radar BSY-2 Submarine Command & Control System Over 100 nodes 8 System Installation and Test  Difficulty affected by the number and complexity of interfaces at the operating site  Internal interfaces vs. external interfaces  External interfaces have dependencies outside the delivered system  Are the other ends of the interface ready?  Internal interfaces are (usually) tested in development  Need to check that installation is correct  Installation Challenges  Physical interfaces  Mating holes/mounting can be wrong, cables can be built incorrectly, components are assembled incorrectly, etc.  Functional interfaces  Command or data transfers are corrupted in transfer and do not work, software versions do not match in the delivered components, environmental air conditioning can be underpowered, etc. 9 Non-disruptive Installation via Simulation New System(s) Operational System of Systems V&V New SoS S imulatio n System(s) SoS Testing System Deployment Strategy Non-disruptive Installation via Simulation 10 Non-disruptive Installation via Duplicate System SoS Testing System Deployment Strategy Operational System of Systems New System Duplicate System of Systems Non-disruptive Installation via Duplicate System 11 Logistics Support Considerations  Maintenance  By the manufacturer/vendor or the user?  Affects documentation that needs to be produced and delivered  Affects training to be developed – in-house or user self-train?  If user maintenance…  Generally more documentation needed for user self support  User may need special test equipment  Spare Parts  Initially delivered with a system  Built and stored for future needs  Depends on product lifetime, time committed to support product  Long-term plan for obsolescence  Reactive or “proactive” 12 Engineering For Operation and Support  Modularity  Good selection for Subsystems/Components  Good selection for interfaces  Many considerations  Number of systems to build  Accessibility for repair  These need to be considered from the beginning of the project starting with the Needs Analysis! 13 Support Equipment  Support elements of the system can be quite substantial  Example elements  Field maintenance and test equipment/test tools  Intermediate maintenance and test equipment/test tools  Facilities  Enclosures/buildings  Intermediate maintenance facility  Examples  RF test equipment  Antenna test ranges  Docking port/dry dock/terminal dock/launch pad  Or are these subsystems of the operational system? 14 Ongoing Maintenance  Systems Engineer is not usually involved in ordinary maintenance  May be brought in to diagnose hard problems  Especially if problem is between components or systems  However, maintenance is affected by the Systems Engineer’s decisions in prior phases of the life cycle  Reliability requirements  Is it possible (or needed)?  Scheduled maintenance vs. fix on breakage  Mean time between system failures  Mean time between component failures  Maintainability requirements and features  How difficult is it to fix? 15 High Reliability May Add Cost  Redundancy  Provides additional spare components built into the system so it keeps operating even if a component fails  Adds more parts that fail, more complexity Redundant Unit Redundant Unit Redundancy Control  High Reliability Parts  Tighter tolerances – more difficult to manufacture  Burn in – run components before installing in the system to weed out early failures 16 Considering Logistics: Spare Parts  Tradeoff:  Cost of purchasing/storing lots of spare components/parts  Cost and time to get broken components/parts repaired  Effects of system being unavailable if a spare part is unavailable  Caution – Components/parts with long lead times ■ System Requirements – System Reliability – System Availability – Storage/transportation of components ■ Considerations/Constraints – Development Cost – Operations Cost – Repair facilities 17 Diminishing Manufacturing Sources (DMS)  When a part or component is no longer available to support the operational life of the system  Original vendor no longer makes the part or component  No business base  Obsolete technology  Source of repair parts has insufficient quantity  Maintaining an active DMS monitoring program is important to prevent repair part shortages  Provides advance notice to allow time for a solution  This is one place where good choice of components and interfaces pays off  Poor selection means that unusually large (expensive) components must be replaced or redesigned 18 Resolving DMS  Lifetime Buy  Ask the vendor for one last order  Buy enough parts and put them in a warehouse to last the expected lifetime of the system  Qualify an Alternate Item  Find a substitute part – another vendor may make an identical or sufficiently close part  Develop a plan to test the substitute  Update specs, drawings, manuals as needed to allow the alternate part as a substitute  Have a 3rd Party Build More Parts to the Original Drawings  Need to ensure that you have the right documentation  Need to ensure the newly produced item does what it is supposed to do 19 Resolving DMS (continued)  Design a New Part  Design and qualify a new part  Use the appropriate specification for a new design  Hopefully, you also have good interfaces to design the new part to interoperate with the rest of the parts correctly In all cases, the systems engineer should be involved with the solution ■ Assess risk ■ Perform a trade study ■ There are testing considerations ■ It may be an opportunity to address system shortcomings 20 Special Consideration: Commercial Off The Shelf Equipment (COTS)  COTS – Components or equipment that you purchase from a commercial company that is not custom designed for your application  Sold to the general public as “a catalog item”  Government has a long definition “The entire process of system development – requirements, design, implementation, testing, maintenance – will undergo many radical changes when a system incorporates multiple COTS components. By committing to just one part of the “new paradigm” (i.e., simply buying some commercial products), it is vital to realize that this will usually demand a commitment to all of it.” From “Quotations from Chairman David, A Little Red Book of Truths to Enlighten and Guide on the Long March Toward the COTS Revolution,” Carnegie Mellon Software Engineering Institute, 1998 21 COTS – The Good  Reduces development time  Functionality can be immediately purchased  Lower initial cost  Get the advantage of quantity production  Someone else has already done the design and development  Competitive environment  Stimulates improving performance  Contributes to lower initial purchase cost 22 COTS – The Bad  Vendor-unique product  Vendor can change their products at their whim  They abandon a product for a new one  Contributes to DMS problems  They change the product to lower their production costs  e.g., swap a part like a memory module  “Minor changes” can have surprising side effects  Most likely you will not have good documentation  Vendor product manuals and sales brochure sheets  Few detail specifications  No drawings 23 COTS – The Ugly!  You get what you get – Be sure to test what you really need  Vendors sometimes claim to meet a specification they really do not  Do not implement lesser used parts of the specification  Bugs & glitches  You usually have to live with the vendor’s choices  If a vendor does not sell it, you will have to develop it yourself  Riskiest approach: Modify a product from a COTS vendor and use it as your own component  It is now your product, the original vendor will not support it  You probably do not have the needed documentation if there is a problem  Resolving DMS on a COTS component often has side effects  New generations of equipment change may also change interfaces  Example: New CPU hardware may need new driver or OS upgrade 24 Approaches to COTS Management Factors in making a Decision Vendor Stability System Functionality Upgrades Pre-Emptive Replace all COTS on a fixed schedule, DMS or not     Product Lifetime Funding Methods/Availability Integration Facilities Availability of Component Spares to Update Product Interoperability Configuration Management Complexity Product Evolution Vendor Maintenance Updates Spares Concept Reliability Cost Technology Changes A Spectrum of Possibilities Reactive Replace a COTS item when it goes DMS No single answer is obviously the best Solution is often a mix of answers depending on subsystem/component Need an approach the system’s user community can support Initial system concept and requirements sets the wheels in motion 25 Upgrades  Treat like new system development – Define the requirement  Replace a component for DMS  Add functionality or improve performance to meet the user need  Biggest difference is the degree of emphasis on the existing design  Tendency is to constrain the concepts to provide a solution  Existing system external interfaces  Existing system decomposition into subsystem/components  The systems engineer should consider all solutions  Fit solution into the existing system  Change other components to provide the right solution  Recommend an alternate solution:  Doctrine, Organization, Training, Materiel, Leadership and Education, Personnel and Facilities 26 Summary  The systems engineer needs to consider the range of topics for making a system work in the field         Readying the support infrastructure Delivery Installation Initial user training Activating the system and beginning operations Initial logistics support Plan for long term maintenance and sustainment Assigning responsibilities  A fielding plan should be prepared  Often ends up being led by a logistics team  Systems Engineers should participate 27 Summary  For routine system deliveries, operations and support  Often less of a direct systems engineer role  Mainly addresses latent design defects or production problems  Choices made while developing the system show their effect  Reliability  Maintainability  Choices for defining subsystems, components and interfaces  Systems Engineers need to understand the operations and support portion of the life cycle to make good decisions in development 28
    Systems Engineering Process, Part 2 Part 2 extends the Part 1 work that addressed the needs analysis phase and takes the system through the concept exploration phase. In Part 1, you built a case to justify initiating the development of a new system that provides a solution to a problem that you identified. Part 2 explores a broad but differentiated set of system concepts to meet the need. Starting with the Part 1 paper, update the paper according to instructor feedback and additional lessons learned in the course. Additional updates may also be needed as you continue through the rest of the concept development phases, as this is an iterative process. For the concept exploration phase, first identify the functions that the system will need to perform. These should be categorized into the following: • Input functions • Transformative functions • Output functions These functions should be defined no further than needed to describe the system and what the system needs to do (at the system level). Next, develop a system context diagram using the following guidelines: • The system context diagram provides the boundary of what is in the system and what is outside of the system • The system context diagram shows the key external system interfaces and provides unique labels for all the interfaces and external entities • The system context diagram includes primary users, maintainers, trainers, and other stakeholders that interface to the system during the operational phase • The system context diagram includes the environmental interfaces (input and output) • The system context diagram includes an interface to its energy source • The system context diagram addresses signals, data, materials, energy, and forces (as applicable) Then define a top-level functional block diagram. Guidelines for the top-level functional diagram are: • There should be about three to six functions at this level (with some exceptions possible) • The functional block diagram should show all the inputs and outputs of the system going to and from at least one of the functions (or to the whole system, if applicable) • There should be internal interfaces between at least some (if not all) of the functions inside the system; and these interfaces should be labeled uniquely (different names) from the system inputs and outputs • Functions should be labeled using verbs • Every function should have at least one input and one output Next, develop the functional and performance requirements. That is, the functional requirements cover what the system has to do to meet the need, and the performance requirements cover how well the system has to perform those functions. Functional requirements focus on the capabilities of the system. Performance requirements address the characteristics of the system and include a quantitative measure. NOTE: You probably do not have subject matter expertise in the system domain that you chose, and so the performance requirements can be stated with TBD values or estimated ranges. For the last part of the concept exploration phase, define a broad differentiated set of four to eight system concepts that will be considered. A hybrid of concepts is acceptable as its own concept (bridge, tunnel, island combination). These system concepts can be upgrades to existing systems, new COTS or technology driven systems, an integration of various existing technologies or approaches in a unique way, or other unique or creative system solutions. Guidelines include: • The concepts address the operational, functional, and performance requirements • Four to eight different kinds of concepts are considered; one or two can be hybrids of the other concepts The paper should demonstrate your understanding of the Kossiakoff systems engineering life cycle. The Part 2 portion of the paper should be about 3 - 5 pages long (not counting charts, figures, title page, reference list, etc.). Make sure to add a title page to your paper and include your references (on the last page). Feel free to use an APA format or another citation format of your choosing.

    Tutor Answer

    Proff_White
    School: Carnegie Mellon University

    Attached.

    Running head: CONCEPT EXPLORATION PHASE

    Concept Exploration Phase

    Student’s name:
    Institutional affiliation:

    1

    CONCEPT EXPLORATION PHASE

    2

    Concept Exploration Phase
    Introduction
    Considering that National Academy of Engineering (n.d.) advocate for the use of
    desalination as the best low cost alternative in providing clean water to the population, this paper
    will focus on desalination. Desalination is the extraction of water from salty ocean water. This
    option is viable for Modesto, California considering that the region is not very far from the coast.
    This paper extrapolates on the system used in the most recent method of desalination – reverse
    osmosis.
    Functions of the system


    Input functions

    The main inputs include salty water, materials (pipes and water system components), labor,
    energy (solar energy), automatic water billing gadget with SMS function.


    Transformative functions

    Changing water from salty to fresh, automatic water billing, sending a signal to the water
    department if water does not reach users’ meters, and delivering water on a 24/7 basis to
    residents.


    Output functions

    Clean water, consistent water, timely reporting of water outage, convenient mobile based billing
    and payments.

    CONCEPT EXPLORATION PHASE

    3

    Sun

    System Context diagram

    RR
    Reverse Osmosis system

    California water
    department

    T
    Users

    U

    Water purification unit

    S
    K

    J

    P

    tghsssss

    Water
    Pumping

    W

    Automatic meter reader
    and SMS unit

    D

    M

    G
    System Engineers and
    developers

    Key
    K – Send water bill payment, check meter reading.
    J – Receive SMS for water bill, receive notification of payment receipt, receive notification for
    water shortage
    D – SMS notification for system fault or urgent needs, notify them of important repair dates.
    G – Regular maintenance of the sys...

    flag Report DMCA
    Review

    Anonymous
    Thank you! Reasonably priced given the quality not just of the tutors but the moderators too. They were helpful and accommodating given my needs.

    Similar Questions
    Hot Questions
    Related Tags
    Study Guides

    Brown University





    1271 Tutors

    California Institute of Technology




    2131 Tutors

    Carnegie Mellon University




    982 Tutors

    Columbia University





    1256 Tutors

    Dartmouth University





    2113 Tutors

    Emory University





    2279 Tutors

    Harvard University





    599 Tutors

    Massachusetts Institute of Technology



    2319 Tutors

    New York University





    1645 Tutors

    Notre Dam University





    1911 Tutors

    Oklahoma University





    2122 Tutors

    Pennsylvania State University





    932 Tutors

    Princeton University





    1211 Tutors

    Stanford University





    983 Tutors

    University of California





    1282 Tutors

    Oxford University





    123 Tutors

    Yale University





    2325 Tutors