10 good reasons to go for model-based systems engineering in your organization

Editor's Notes

• #2: Good morning to all of you. This is my great pleasure to be here with you. Today, I’ll talk about how we Siemens and our customers are willing to tackle current and future challenges of Model Based Systems Engineering.
• #3: Darwin may not have said it exactly like this but he was to the point really when saying that the one that survives is the one that is able to change …
• #4: And believe me or not, change is happening in the industry.
• #5: Let us consider the Automotive industry context: We as individuals are requiring powerful cars but clean and cheap in terms of fuel consumption. We also want these cars to be safe, robust, comfortable, more autonomous. Because OEMs and suppliers want us to be satisfied, because regulation policies are more and more strict, they need to reflect upon ways to design quicker and more efficiently such ideal cars.
• #6: What does this mean in terms of Product Development ? Being able to cope with growing complexity of electronic systems and interaction with the physics, Managing increasing number of requirements and use cases, Innovating with new types of architectures, managing the ever increasing number of vehicle variants. And all of this in an international and multi-cultural work environment …. Definitely …
• #8: Can Darwin help us again here ?
• #9: Over the last 30 years, product engineering has evolved.   To start, requirements management has developed from ad-hoc and paper-based methods to a managed approach within PLM systems.   Product representation has evolved from drafting to full digital mock-ups of the product assembly.   Performance verification has evolved from a build-and-break approach to the current practice that includes significant CAE work as well as test.   But with the complexity trends, engineering must evolve again.   Product representations must evolve to full system mock-ups that cover not just mechanical but also electrical, software, and controls representations.   Product performance engineering must evolve to be more predictive so it can drive the creation of the design and the system representation. This is represented in the arrows under the Product Representation row.   And these must be fully integrated into an overall PLM system to ensure we can close the loop from requirements to as-designed behavior and beyond to manufacturing and usage.
• #10: Today engineering data and models are scattered in different silos No ability to easily draw inferences across these silos. This must change in order to meet the new demands of today’s products.
• #11: When we take all these different silos of models and data and link them together, we create the digital twin. The digital twin includes simulation models and data that cover different types of behaviors. It has models that are relevant to different stages of the development process. Data from one model may be used as inputs to a different model that is built later in the process. The models themselves can be matured over time.
• #12: Let me illustrate this slide with the example of ADAS (Advance Driver Assistance Systems). Car passengers want cars that are safer and safer. They require emergency braking features, active cruise control, … Do you know how many kilometers a car has to be driven in order to validate an ACC with tests ? More than 1 million km. Meaning that at the start of the product design process, there are many requirements to be fulfilled that translates into functions and some logics to control these functions. If you combine this with later the CAD representation of the product you end-up with what we call the System Mock-up. From this Mock-up, you are going to create analysis requests to check that requirements are verified. This analysis can be performed based on Simulation (CFD, 3D, 1D) but also test. Once you have checked that requirements are verified and that the analysis performed shows no major issues with the performance of the subsystems involved, you have closed the loop. This is the System Driven Product Development Iterative process.
• #13: Simcenter is the Siemens software brand for addressing Predictive Engineering Analytics. The Simcenter portfolio consists of solutions that span 3D simulation, 1D simulation, and testing solutions. It is comprised of a number of well known products such as NX Nastran, STAR-CCM+, LMS Imagine.Lab and LMS Test.Lab. Additionally, it includes Simcenter 3D, our next generation 3D CAE solution that is based on the NX platform and expands on the heritage of NX CAE, LMS Virtual.Lab, NX Nastran and LMS Samtech. The portfolio covers a number of disciplines as represented in the spokes of the inner circle and the solutions are further enhanced with multi-discipline design exploration capabilities. Finally, the solutions are available with integrations to Teamcenter to enable data and process management and complete traceability within the PLM ecosystem.
• #14: To fully realize the Predictive Engineering Analytics vision, we strongly believe that the following 9 cornerstones need to be implemented and further developed to future-proof engineering approaches.   [1] The portfolio should support the full development cycle and different technology domains.   [2] A multi-disciplinary and multi-physics approach is crucial to receive the required fidelity level to predict phenomenon involving different physics domains.   [3] It should embed technology to capture specific industry challenges and include dedicated post-processing capabilities. The portfolio can be augmented with engineering services and technology transfers.   [4] Multi-disciplinary design exploration, data mining and optimization provides strong visualization capabilities to communicate insights.   [5] A systems approach captures the relationships between the requirements, functional layout, logical implementation and physical implementation. Users can assess how changes at one level impact decisions on another level. This will enable traceability and cascading of key parameters throughout the lifecycle.   [6] The portfolio provides flexible licensing mechanisms including tokens and cloud-based options to limit infrastructure hassle.   [7] It should be open, taking into account that companies always have a variety of in-house tools, either for legacy reasons or to benefit from the specific strengths of certain tools.   [8] Collaborative workflow means that development is interconnected. Sharing data, both internally and externally with suppliers is crucial. At the same time, collaborative workflows support traceability to ensure quality, legal compliancy and improve operational efficiency.   [9] The portfolio provides a user experience to maximize ease of use and minimize the learning curve.
• #15: While the previous solutions are heavily dependent on available geometry, LMS Imagine.Lab 1D does systems modeling in a different way. The approach is in theory quite simple. By creating 1D models based on physical equations, one can create a library of components with validated physical behavior. These models can be easily clicked together into a complete system model. The physics embedded in the components can be used to calculate how the energy will flow from one component to another, and how this energy is converted into heat, motion, or a chemical reaction. These 1D models can also be used for 3D co-simulation and control strategy validation.
• #17: Let me show how the digital twin strategy is applied on real cases. I will illustrate adption on 3 different cases: Controls/Energy Management and Attribute Balancing as well as new challenges in driving dynamics performance.
• #18: Traditional mechatronic development - most of controls validation done @ end of dev cycle - expensive in terms of time spent Industry moving to Model based controls engineering that is to say: - Using Plant connected to control models for virtual calibration before prototyping, - Implies Having the possibility to still have an impact on the product design Cheaper alternative.
• #19: Renault has applied our tools and methodologies to support MBD for Powertrain and controls.
• #20: How did Renault Proceed? At any stage of the mechatronics Design Cycle, they used scalable model or what we call the proper plant + control model level to reduce drastically the costs for controls validation.
• #21: At early design and architectural choices stage by combining a model of the plant and its high level control, they were able to answer to questions like: With these actuators and these sensors, can we satisfy on-board diagnosis requirements (Nox leakage detections and failure strategies)
• #22: At the end of phase 1 and 2, they were able to develop optimal control, select best architecture in 1-month. If you compare to the past where 10 prototypes were needed, gain is huge.
• #23: In previous stage, Renault defined the optimal architecture in terms of sensors and actuators valid for different regulation policies. In next stage, they are prototyping the control algorithm and closed loop testing them with a refined model.
• #24: With this strategy, Renault was able to simulate 6 millinon km in a few days and perform 80% of the control software validation.
• #25: In the last phases, Renault validates the implementation of the complete SW inside the real HW: Export Plant on RT targets + connection to ECU HW via I/O boards. On top of this an automation test environment will help script the test execution.
• #26: Finally, Renault initiated the first step of virtual calibration. The idea is to reduce the amount of HW DoE by tuniing High Fidelity model with a reduced amount of test data (orange data). The model is used to perform virtual DoE with parallel processing. Tuning quality Complexity handling R&D cost 
• #27: Use of simulation enabled Renault to pre-calibrate 20% of the 20000 controls parameters !
• #28: Renault GREEN case study: http://www.plm.automation.siemens.com/CaseStudyWeb/dispatch/viewResource.html?resourceId=50650
• #29: IRKUT case study: http://www.plm.automation.siemens.com/CaseStudyWeb/dispatch/viewResource.html?resourceId=40548
• #30: Liebherr Group (Complex Excavators) case study: http://www.plm.automation.siemens.com/CaseStudyWeb/dispatch/viewResource.html?resourceId=35349
• #31: 30
• #32: 31