1 / 62

Systems Engineering activities at ESS - Introduction

Systems Engineering activities at ESS - Introduction. Romuald Duperrier ESS Systems Engineering Manager AD seminar – October 16 th. Systems Engineering = team work. Building large facilities: 3 key dimensions. Organizations (who). Products (what). Processes (how). Specify. Design.

roger
Download Presentation

Systems Engineering activities at ESS - Introduction

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Systems Engineering activitiesatESS-Introduction Romuald Duperrier ESS Systems Engineering Manager AD seminar – October 16th

  2. Systems Engineering = team work

  3. Building large facilities: 3 key dimensions Organizations (who) Products (what) Processes (how) ... Specify Design Implement Test Operate Maintain ... Integrate Handover Disposal

  4. Operate Maintain Implement Handover Design Specify Integrate Test Disposal Committed cost Cost Incurred cost The waterfall process model Easy/cheap to make changes Processes (how) Hard/expensive to make changes ... Specify Design Implement Test Operate Maintain ... Integrate Handover Disposal

  5. System design and in-kind collaborations Integral architecture Modular architecture Products (what) Often a combination of both

  6. Systematic approach • The construction of the ESS will be paved by a huge number of: • products (most of them are not challenging), • processes (most of them are simple), • roles (all are important). • And thus a huge number of interfaces. • Most of the processes are common sense, but the quantity creates the complexity. • The inherent risk with such complexity can be significantly reduced by a documented systematic approach (ISO 15288). • Traceability from requirements to verification is a must at any level considering the whole facility life cycle.

  7. The V cycle model EM dynamics Fluidic Req. Mgt Validation Implementation Experts, manufacturers Plasmas Func. analysis Integration Electrical Design Test Electronic Physical to built design Mechanical ESS facility Needs Handover Requirement management Validation Compliance Matrix Functional analysis Integration Design Integration Decomposition Logical Design Test

  8. SE management and working groups Interface Working groups Operation concepts Working group Programme Management Office Systems Engineering Office Requirement Working groups …. SE Team

  9. Pre-existing requirements management Integration in ESS requirements tree [M. Field, Frontiers 2008]

  10. About the phasing of SE implementation and on going ESS technical activities What is planned is not a reset of the system but to take a snapshot based on a systematic approach to track inconsistencies and, thus, to bring all the stakeholders in an holistic perspective. Outputs of the SE process will be crucial documentations to support the configuration management during the construction phase.

  11. Requirements allocation to products ESS objectives Interface management

  12. Costing and scheduling support Interface management

  13. Worldwide SE implementation [Barabaschi, Soft’06]

  14. Worldwide SE implementation

  15. ESS context diagram

  16. Context diagram ? ? Accelerator ? ? ? ?

  17. ESS requirements ESS objectives Define requirements Part 1 requirements Part n requirements Part 2 requirements • ESS requirements into a tree-like hierarchy will provide a mechanism for specifying what is necessary down to the lowest level of the system for each state of the life cycle. • Trace links between the scientific objectives and the facility requirements will ensure that the users understand how their needs have been translated into system requirements. System of Part 1 requirements

  18. Relationship of aims • Stakeholder :any entity (individual or organization) with a legitimate interest in the system or which could influence the development, • Programme/project goals: statement of what the programme or project will deliver. • Requirement:specifies a capability or condition that must be satisfied.

  19. Requirements types • Function:“what is performed by the system?” • Constraint: “how the function must be performed?”, • Performance: condition that a system must achieve: clear criterion of achievement of the function/constraint. • Example: • “Transport the proton beam” is a function, • “Limit the beam loss” is a constraint, • “Less than 1 W/m” is an associated performance. • Funct/Const requirement have to be ideally specified by a functive (verb+noun). • See Requirement development policy.

  20. Identify working group members

  21. Verification and Validation • Inspection. • Demonstration. • Analysis. • Test. • Certification. • Similarity. • Review.

  22. Functional Analysis Systems Technique Functive A Functive B AND Functive C WHY? HOW? Functive A Functive B OR Functive C

  23. Function allocation to system System A Functive A Functive B System B Functive C System C

  24. Increase resolution Functive D System D Functive B System B Functive E System E Functive A System A Functive F System F Functive C System C Functive G System G

  25. Example: hoover Aspirate dust Create air flow Turbine Clean the room Remove dust Separate dust Filter dust Filter Store dust Bag HOOVER Service functions Technical functions Technical solutions

  26. Example: hoover Aspirate dust Create air flow Turbine Clean the room Remove dust Separate dust Filter dust Filter Store dust Bag HOOVER HOW? Service functions Technical functions Technical solutions

  27. Example: hoover Aspirate dust Create air flow Turbine Clean the room Remove dust Separate dust Filter dust Filter Store dust Bag WHY? HOOVER Service functions Technical functions Technical solutions

  28. Let’s have fun: accelerator Irradiate the target with a pulsed proton beam Accelerator Service functions Technical functions Technical solutions

  29. Example: FAST diagram for an ATM Request Card Card reader Identify user Request Id Request Pin-code Keyboard Request amount of money Provide cash Bank network terminal Connect to user bank Verify user account Software Request account status Store cash Cash cartridges Provide cash Pick up cash Sort cash Emit cash Dispensing system Service functions Technical functions Technical solutions

  30. Use cases

  31. Use case for ATM Interacting systems ATM Communication Network Withdraw cash Bank Powering system JACKY BROWN : WITHDRAW CASH

  32. Sequence for ATM Bank ATM Insert card Read card Request pin-code Type pin code Verify code Request amount Type amount Request withdrawal Accept Withdrawal Provide cash Update account status Get back card t

  33. New requirement, new system Display sequence Display

  34. ATM: failure scenarios Bank ATM Insert card Read card Request pin-code Type pin code Verify code Request amount Type amount Request withdrawal Accept Withdrawal Provide cash Update account status Get back card t

  35. ATM: failure scenarios Bank ATM Insert card Read card Request pin-code Type pin code Verify code Request amount Type amount Request withdrawal Deny Withdrawal Get back card Update account status t

  36. New requirement, new system Reset sequence Abort sequence Software Send back card

  37. ATM: failure scenarios Bank ATM Insert card Read card Request pin-code Type pin code Verify code Request amount Type amount Request withdrawal Accept Withdrawal Provide cash Update account status Get back card t

  38. ATM: failure scenarios Bank ATM Insert card Read card Request pin-code Type pin code Verify code Request amount Type wrong amount Correct amount Request withdrawal Accept Withdrawal Provide cash Update account status Get back card t

  39. ATM: failure scenarios Bank ATM Insert card Read card Request pin-code Type pin code Verify code Request amount Change opinion/Cancel sequence Abort sequence Get back card t

  40. New requirement, new system Abort sequence Software Clear typing

  41. ATM: failure scenarios Bank ATM Insert card Read card Request pin-code Type wrong code Verify code Request new attempt Type wrong code Verify code Store card Display message t

  42. New requirement, new system Store card Card storage system Software

  43. Life cycle perspective

  44. Let’s play: a bicycle Convert user energy Pedals Create motion (accelerate) Adapt effort Adapt couple between pedal and wheel Derailleur Transmit energy to ground Transmit energy to wheels Chain/wheels Move Maintain wheel contact to ground Suspension Stop motion (brake) Dissipate energy Brakes Steer motion (guide) Change wheel angle Enable wheel rotation Direction Stem Transmit user request Handlebars

  45. Bicycle: life cycle

  46. Bicycle: Parking state Enable vertical parking Establish 3 non aligned fulcrums Add a third fulcrum Lateral foot support Locate third fulcrum on side

  47. Bicycle: Car storage state Enable fast attachment Quick switching Hub Enable fast wheel removing Adapt fork Drop-out WHAT SHOULD BE MENTIONED?

  48. Life cycle of the HEBT collimators

  49. Summary • The construction of the ESS will be paved by a huge number of products, processes and roles; thus a huge number of interfaces. • Most of the processes are common sense, but the quantity creates the complexity. • ESS made the choice to significantly limit the risk inherent with such complexity by implementing a documented systematic approach: MBSE. • The SE deployment is an on going process in the different projects. Working groups meetings have been quite lify and a source interesting and productive discussions. • The SE plan is now a core process for licensing.

  50. SE Handbook v3 p. 2.8 • “Upon casual reading, systems engineers appear to be responsible for everything that happens on a project and systems engineering appears to introduce excessive process overhead and non-value added activities.” • “SE is a multi-disciplinary effort that involves both the technical effort and technical project management…[its implementation] requires vision and practical application of the principles.”

More Related