Application Of Model Based System Engineering (MBSE .

2y ago
96 Views
4 Downloads
958.14 KB
20 Pages
Last View : 1m ago
Last Download : 2m ago
Upload by : Rosemary Rios
Transcription

Application of Model Based SystemEngineering (MBSE) Principles to anAutomotive Driveline Sub-SystemArchitecturePresented By: Robert Kraus, GeorgePapaioannou and Arun Sivan

Discussion Agenda Introduction & Project SummaryDriveline Definitions and ConceptsSystems Engineering ConceptsMBSE ConceptsDriveline Model Structure - Functional and Logical DecompositionRequirements & Test Case ManagementRequirements Management : Satisfy RelationshipsParametric Relationships - Constraint Modeling Applied to SizingBenefits of Applied MBSE2

Introduction & Project SummaryCurrent State: Today’s automotive driveline system engineering process is “document based” Complex system requirements and specifications are communicated through large amountsof electronic dataOften leads to incomplete or conflicting requirementsInefficient, redundant, error proneRunning changes introduce potential problemsProject Summary: Obtained and deconstructed existing driveline system methods and sizing toolsIdentified need for improved requirements traceability in driveline systems engineeringCreated detailed driveline system model to apply the concepts of MBSE using SysMLAdded parametric constraints for sizing calculationsDelivered functional MBSE model as proof of concept3

Driveline Definitions and ConceptsArchitecture: Complete AWD DrivelineA driveline system links the powertrain output to the drive wheelsPrimary function is to transmit drive torque from the powertrain to the ground (wheels)Driveline subtypes such as FWD, RWD, AWD are treated as generalizations in SysMLComponents: Driveshaft / half shaft - transmits torque to front/rear or left/rightAxle - multiplies driveshaft torque and directs to wheelsAdditional - Transfer case, PTU, disconnect device, U-joints, CV-joints, flex couplerSizing: Design optimization of each component, system and subsystem is the primary objectiveA sizing tool converts input data into torque outputs for all vehicle variations and uses industrystandard equations and some correction factors.4

System Engineering Concepts V-Model: Top level requirements are decomposed to the subsystem andcomponent levels, each with a specific validation plan flowingdown the left side of the V and back up the right side.Context Diagram: Represents system interactions to an external environment Interacting systems are defined as “black boxes”P-Diagram: Expands and refines context for more detailed black boxes Includes detail on input signals, control factors, noise factors,outputs, and potential failure modesMBSE Modeling Language (SysML, UML etc) Modeling Method Modeling Tool (Magicdraw, IBM Rational Rhapsody etc)V- ModelContext DiagramP-Diagram5

Model Based System Engineering Concepts: System Requirements Requirements define customer andstakeholder needs in technical termsIn SysML, system requirement statements aredefined as objectsEach object contains the requirement text & aunique identifierThe requirement type defines the features arequirement can be associated withGeneralizations manage and allocaterequirements through inheritancerelationshipsRequirements must be verified by test casesTest cases are checkpoints, such as designreviews or physical testsStandard type requirements within SysMLare used to provide rigor and clarity whendefining the system6

Model Based System Engineering Concepts: Functional & Logical Architecture Functions define what actions / activities must be accomplished or completed to achieve adesired outcome An operation is a property of a block Functions are linked through logical relationships to the various subsystems and componentsThe logical architecture describes how a system will be implementedIt abstractly defines a technical solution based on the system’s required sub-systems,components and their relationshipsA logical architecture should only be created after the system’s functions and requirementsare clearly definedIt does not define any particular system implementation, but rather the general guidelines soas to remain solution-neutral A block is an abstract representation of any part of a system, like physical hardware or asignal7

Methods of Modeling: Functional Decomposition Five basic operations of the drivelinesystems were identified from theP-diagramThe system needs to Transmit torque Direct torque left / right Direct torque fore / aft Multiply torque Disconnect the secondarydrivelineEach function is associated, ormapped, to at least one logical blockThe function, or operation, is theninherited through generalizations8

Methods of Modeling: Functional Decomposition Transmission of propulsion force from the powertrain to the wheels is the most basic,and most obvious, driveline functionAt the functional level of abstraction the degree or amount of torque transferred is notnecessarily relevant – all that matters is that all drivelines transmit torqueIn our model the “transmit torque” function is inherited by all mechanical sub-systemsand componentsIt is important to note that no one component alone delivers or satisfies the transmittorque function - it is an emergent function of the total systemThe next function is to direct torque left/right which is the operation or behavior of aaxle/transaxle differential logical blockThe next function is to direct torque fore-aft which is the behavior of a transfer case andis only present in AWD or 4X4 driveline configurationIn a driveline system model, the multiply torque function is a behavior of the axle onlyThe last function is the disconnect function which is the behavior of a disconnect device9

Methods of Modeling: Logical Decomposition Logical blocks are constructed after thefunctional blocks are defined,requiring some experience andengineering judgementA good logical decomposition shouldremain untethered to any specificdesign concept, since it is unlikely thatthe first design concept will be the bestdesign conceptThe driveline logical diagram providesthe structure required to capture thevehicle inputs required to supportparametric equations for calculatingdriveline impact torques, which is thebasis for sizing10

Requirements & Test Case Management Import the requirementsusing the import feature inMagicDraw into arequirements package.Existing test methods areimported using a methodsimilar to that ofimporting requirementsVerify matrices arecreated and eachrequirement is verified byone or more test methods.11

Requirement Management: Satisfy Relationships Requirements are satisfied by physicalelementsIn MBSE this relationship is created at thelogical level of abstraction, prior to anyphysical parts being designedThe satisfy matrix indicates that eachrequirement is mapped to at least one logicalblock through a satisfy relationship thatindicates that the logical block is required todeliver or meet the requirementThe table shows all the logical elements in thedriveline model that satisfy requirements, andthe requirements are separated into the sevendifferent SysML requirement typesI think I am done for now. Will revise a bit moreafter Bob and Mike review.12

Parametric Relationships In systems engineering, design involves makingdecisions between solution alternativesGeneral process is: Generate ideas Evaluate alternatives - engineering analysis Decide between alternatives - interpretresultsSysML provides a language to express andperform mathematical system analysis throughparametric diagramsParametric diagrams show mathematicalrelationships between the blocks of the systemmodel.They act as constraints on the system design.13

Parametric Relationships: Sizing Inputs Parametric input parameters areobtained from industry standardequations for sizing (sizing tool).Mapping of parametric inputs as valueproperties associated with logicalblocks based on the property’s logicalownership are shown hereThe impact torque sizing inputs are thevalue properties associated with theappropriate logical blocksAt logical architecture levels, thesevalue properties are to be definedvariables that are not associated withany specific instanceSpecific instances can be created whenrequired14

Parametric Relationships: Constraint modeling Parametric constraints specify equivalencerelationships between logical blocksDefined in a similar manner to IBDs, butthey use internal relationships withconstraint parameters instead of partparametersRestricted to connecting only throughbinding connectors, typically with aparametric constraint at one end of theconnectionThe key element is the constraint block,which is used to constrain the properties ofone or more other blocksConstraint blocks consist of constraintexpressions {τ F * d } and constraintparameters (such as τ, F and d)15

Parametric Relationships: Driveline Sizing Goal : Show proof of concept for thecalculation of sizing torquesA total of eight different constraint blocksused to model impact torque, consisting oftorque flow equations, logic flow and BooleanassignmentsInstances need to be created with specificinputs to complete parametric analysis fordriveline sizingParametric calculations for impact torquewere completed for a proposed vehicleprogram, and compared to the values obtainedfrom existing analytical toolsSuccessful proof of concept, however, requiresmore time and work to reliably replaceexisting analytical tool16

Benefits of Applied MBSE Object oriented modeling can be equally applicable to a fully mechanical systemMBSE improves engineering productivity and efficiencySystem models are more flexible, consistent and scalable across all sub-systemsStreamlined communication of requirements by making all key input and outputparameters available to all model usersBetter traceability and linkages between requirements and their methods ofverificationThe reduction of requirement redundancies and automatic validation of test caseverification could result in the elimination of entire tracking departmentsThe ability to continuously update and manage component design inputs throughparametric relationships with vehicle level inputsEvery individual with access to the model can not only see and verify his or hersubsystem, but also view all of the interactions of their subsystem with other parts ofthe entire system minimizing cross functional issues and miscommunication17

Benefits of Applied MBSE We emphasized careful categorization of existing requirements and during the importprocess eliminated redundancies, reduced 500 to 300Through our integration efforts into SysML categories, we discovered a clear need andbenefit of improved elicitation and partitioning of existing requirementsRequirements and test cases can be added to the model fairly easily, and can be easilylinked with the entire driveline system.A new requirement with the document based approach will require a lot of crossreferencing with other requirements, and redundancies and total misses are quitepossible18

Benefits of Applied MBSE: Parametric Input Cascade andControl Through parametric relationships, top level assumption changes areimmediately cascaded down and can be verified against existing componentvariable properties For example, If engine torque in first gear goes up, it will immediately be calculatedinto transmission output torque and compared against the axle maximum input torquelimit. These are SysML numbers calculated, used as an alert, but details need to alsoexist to define past systems level. Not too deep and complex. You lose sight of bigpicture.Changes in tire properties can be linked to and compared against halfshaft joint designlimits automaticallyIf the input assumptions exceed design limits the model shows an outputerror alerting engineering to act19

20

Benefits of Applied MBSE Object oriented modeling can be equally applicable to a fully mechanical system MBSE improves engineering productivity and efficiency System models are more flexible, consistent and scalable across all sub-systems Streamlined communication of requirements by making all key input and outputFile Size: 958KB

Related Documents:

Remington Model 121 Fieldmaster Remington Model 141 Remington Model 241 Remington 270 Remington 336 Remington Model 504 Remington Model 511 Scoremaster Remington Model 512 Sportmaster Remington Model 513 Remington Model 572 Fieldmaster . Remington Model 600 Remington Model 660 Remington Model 673 Remington

Co-Teaching Models Model 4 Model 5 Model 6 Model 7 Image Credit: New America. Model 1. Model 2. Model 3. Model 4 . Model 5. Model 6. Model 7. Ownership. Instruction Supporting one teacher presents, one teacher rotates to individual students; allows for immediate feedback Modeling one teacher leads, one

OSI Model vs. TCP/IP Model . 30. OSI Model vs. TCP/IP Model. OSI Model TCP/IP Model. Physical Data-link Network Transport Session Presentation Application Physical Data-link Network Transport Application “Please Do not Throw Sausage Pizza Away” **030 Okay so now let's map to the . other model that's out there. Page 2 of 23File Size: 848KBPage Count: 23

ASTM D 5132 BSS 7230 MODEL 701-S MODEL 701-S-X (export) MODEL VC-1 MODEL VC-1-X (export) MODEL VC-2 MODEL VC-2-X (export) MODEL HC-1 MODEL HC-1-X (export) MODEL HC-2 MODEL HC-2-X (export) FAA Listed TM. FAA MULTI-PURPOSE SMALL SCALE FLAMMABILITY TESTER SPECIFICATIONS: FAR Part 25 Appendix F Part I (Vertical, Horizontal, 45 and 60 ) DRAPERY FLAMMABILITY The most widely cited .

FOKUS MASALAH Turban (2005) mengkategorikan model sistem pendukung keputusan dalam tujuh model, yaitu : 1) Model optimasi untuk masalah-masalah dengan alternatif-alternatif dalam jumlah relatif kecil. 2) Model optimasi dengan algoritma. 3) Model optimasi dengan formula analitik. 4) Model simulasi. 5) Model heuristik. 6) Model prediktif. 7) Model-model yang lainnya.

7. Model Integrasi Pendidikan Kecakapan Hidup SMP dan SMA. 8. Model Penilaian Kelas. 9. Model KTSP SD 10. Model KTSP SMP 11. Model KTSP SMA 12. Model KTSP SMK 13. Model KTSP Pendidikan Khusus Model-model ini bersama sumber-sumber lain dimaksudkan sebagai pedoman sekolah/madrasah dalam mengembangkan

Mendelr Model-1988, 1992, The Jacob Kounin Model -1971, Neo-Skinnerian Model-1960, Haim Ginott Model (considered non-interventionist model approach) -1971, William Glasser Model-1969, 1985, 1992 (Quality school), Rudolf Dreikurs Model (Model of democracy)-1972, Lee and Marlene Canter Model (Assertive Discipline Model is one of the most spread

Zodiac Aerospace P/N: 950006022100001 Tests and Computations per 14 CFR § 21.303, Dwg No.: 950006022100001DEC, Rev.: C, Dated: 8/1/12, or later FAA approved revisions. Airbus A318 Model -111 A318 Model -112 . A318 Model -121 : A318 Model -122 . A319 Model -111 . A319 Model -112 . A319 Model -113 . A319 Model -114 . A319 Model -115 . A319 Model .