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.
01 / 62Systems Engineering activities at ESS - Introduction
1 / 17
Télécharger la présentation
Systems Engineering activities at ESS - Introduction
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation
Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement.Téléchargez la présentation en cliquant sur ce lien.Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.
Building large facilities: 3 key dimensions Organizations (who) Products (what) Processes (how) ... Specify Design Implement Test Operate Maintain ... Integrate Handover Disposal
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
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.
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
SE management and working groups Interface Working groups Operation concepts Working group Programme Management Office Systems Engineering Office Requirement Working groups …. SE Team
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.
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
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.
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.
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
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
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
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
Let’s have fun: accelerator Irradiate the target with a pulsed proton beam Accelerator Service functions Technical functions Technical solutions
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
Use case for ATM Interacting systems ATM Communication Network Withdraw cash Bank Powering system JACKY BROWN : WITHDRAW CASH
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
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
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
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
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
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
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
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
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.
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.”
Connexion au compte
Connectez-vous pour publier votre contenu sur SlideServe.