Presentation is loading. Please wait.

Presentation is loading. Please wait.

Best Practices for Model Based Design (MBD)

Similar presentations


Presentation on theme: "Best Practices for Model Based Design (MBD)"— Presentation transcript:

1 Best Practices for Model Based Design (MBD)
By Jonathan Friedman, Ph.D. Industry Marketing Manager MathWorks

2 Quick Review … What is Model-Based Design?

3 Traditional Workflow RESEARCH REQUIREMENTS SPECIFICATIONS DESIGN
Requirement Documents Difficult to analyze Difficult to manage as they change Paper Specifications Easy to misinterpret Difficult to integrate with design DESIGN Electrical Components EDA Embeddable Algorithms Algorithm Design Mechanical Components MCAD/ MCAE Physical Prototypes Incomplete and expensive Prevents rapid iteration No system-level testing Manual Coding Time consuming Introduces defects and variance Difficult to reuse IMPLEMENTATION Embedded Software C/C++ Hardware VHDL, Verilog Traditional Testing Design and integration issues found late Difficult to feed insights back into design process Traceability INTEGRATION AND TEST

4 Model-Based Design Workflow
INTEGRATION IMPLEMENTATION DESIGN Environment Models Physical Components Algorithms Other CAD Tools VHDL, Verilog C, C++ TEST & VERIFICATION RESEARCH REQUIREMENTS Other hardware MCU DSP FPGA ASIC Use this slide or any other MBD slide to set the stage for the talk. Focus is on multi-discipline design

5 Adoption Process

6 Adoption of Model-Based Design
Virtual Verification & Validation System Validation Fully Leveraged Model-Based Design Closed-loop Simulation Hardware- In-Loop Simulation based Development Algorithm System Requirements Graphical Specs Rapid Prototyping Graphical Programming Simulation Real-Time Testing Production

7 Where did the best practices come from? Why are there 10?

8 Best Practice # 1: Identify the problem you are trying to solve
Have metrics that identify the weak points in your current process Attack your greatest weaknesses first Monitor your Return on Investment (ROI) Example 1: Missed release dates Example 2: Excessive software defects Example 3: Prototype hardware availability

9 Lear automotive body electronic control unit.
Lear Delivers Quality Body Control Electronics Faster Using Model-Based Design Challenge Design, verify, and implement high-quality automotive body control electronics Solution Use Model-Based Design to enable early and continuous verification via simulation, SIL, and HIL testing Results Requirements validated early. Over 95% of issues fixed before implementation, versus 30% previously Development time cut by 40%. 700,000 lines of code generated and test cases reused throughout the development cycle Zero warranty issues reported “We adopted Model-Based Design not only to deliver better-quality systems faster, but because we believe it is a smart choice. Recently we won a project that several of our competitors declined to bid on because of its tight time constraints. Using Model-Based Design, we met the original delivery date with no problem." Jason Bauman Lear Corporation Primary Industry: Automotive Secondary Industries: n/a Application Areas: Code Generation, Control Design, Model-Based Design, Verification, Validation, and Testing Products Used: MATLAB, Simulink, Embedded Coder, MATLAB Coder, Simulink Coder, Simulink Verification and Validation, Stateflow Country: USA Automotive OEMs are pushing suppliers to deliver more functionality in ECU software. To reduce cost, suppliers often integrate many control functions for body electronics—from wipers, lights, windows, and antitheft systems to power distribution—on a single ECU, commonly known as a body control module (BCM) or smart junction box. Lear Delivers Quality Body Control Electronics Faster Using Model-Based Design The rapid increase in system complexity has led to poorly defined requirements, missed deadlines, and quality issues across the industry. Engineers at Lear Corporation are addressing these challenges by using Model-Based Design to develop, verify, and implement body control electronics systems. “With Model-Based Design we identify and resolve requirements issues before implementation,” says Jason Bauman, supervisor, systems engineering at Lear. “Production code generation and continuous verification enable us to complete projects on time, within budget, and with high quality.” The Challenge As vehicle electronics and electrical distribution systems become increasingly complex, requirements need to be clear, complete, and consistent. In traditional hand-coding workflows, ambiguous or conflicting requirements are often discovered late in the development process, leading to schedule or cost overruns. Handwritten code for controllers with hundreds of inputs and outputs and sophisticated state logic is difficult to maintain and reuse. “In the past, as we implemented an engineering change request in one area, we had a difficult time predicting the types of issues we were introducing in the rest of the system,” recalls Jinming Yang, principal engineer at Lear. “We adopted Model-Based Design not only to deliver better-quality systems faster, but because we believe it is a smart choice. Recently we won a project that several of our competitors declined to bid on because of its tight time constraints. Using Model-Based Design, we met the original delivery date with no problem." - Jason Bauman, Lear Corporation The Solution Lear adopted Model-Based Design for the design, verification, and implementation of dozens of body electronics systems. In one BCM project, Lear engineers analyzed customer requirements and partitioned the overall system into components such as interior and exterior lighting, battery management, and vehicle starting control. The team used MATLAB, Simulink, and Stateflow to develop fully functional behavioral models, including all required inputs and outputs, for each component. To conduct early unit testing, the engineers used the Signal Builder block in Simulink to generate test stimuli and incorporate them into the models. The team also used Simulink to develop plant models for functional testing. Using Simulink Verification and Validation, the team analyzed model coverage and continued refining test cases, designs, and requirements until they reached satisfactory model coverage levels, including decision coverage and modified condition/decision coverage (MC/DC). After verifying nearly 400 unit models, the team used Embedded Coder to generate C code. They verified this code via software-in the-loop (SIL) tests that reused the test cases generated for the unit model tests. Lear engineers integrated the generated code for each unit model into 20–30 feature-level components, which were in turn integrated into a complete system model. The team met with the customer and ran simulations of the components and the complete model to resolve ambiguities in the original design specification. The group used MATLAB scripts to automate the conversion of test cases into test vectors for hardware-in-the-loop (HIL) and vehicle-based testing. They wrote additional MATLAB scripts to import and analyze the test results from the hardware. The ability to share models enabled Lear to extend the workday across a distributed team. In some cases, design changes made by Lear engineers in North America were tested the same night by colleagues in Asia. On a separate project for an international customer, issues with translating technical terminology made it challenging for Lear engineers to understand a particular requirement. “We used a Simulink model including a Signal Builder block to visualize different timing options, and the customer immediately selected the one they wanted,” notes Bauman. “Opening that line of communication was vital to the project.” The Results ■ Requirements validated early. “For the BCM project, we used virtual integration and test with executable functional models in Simulink to identify more than 95 percent of requirements issues before implementation—compared with just 30 percent before we started using Model-Based Design,” says Bauman. “We resolved issues much earlier too, often in as little as six weeks from the start of the project, instead of a year or more.” ■ Development time cut by 40 percent. “We generated about 700,000 lines of code for the BCM project, and we reused test cases throughout the development cycle,” says Yang. “This approach enabled us to reduce overall development time by about 40 percent. ” ■ Zero warranty issues reported. “Industry-wide, the number of warranty issues has grown with software complexity,” says Bauman. “For the most recent products that we have completed using Model-Based Design, we’ve had no warranty issues related to application software after 12 months of production. That is a record that our current and future customers are happy to hear.” Learn more about Lear Corporation: OR Link to user story

10 Best Practice # 2: Use models for at least two things – “Rule of Two”
Overcome startup costs and resistance to change ROI increases with multi-use models Example 1: Validate requirements through simulation and add new functionality through rapid prototyping Example 2: System specification and automatic code generation Example 3: Development time reduced and additional design complexity without staff increases

11 Airbus A380, the world’s largest commercial aircraft.
Airbus Develops Fuel Management System for the A380 Using Model-Based Design Challenge Develop a controller for the Airbus A380 fuel management system Solution Use MATLAB, Simulink, and Stateflow for Model-Based Design to model and simulate the control logic, communicate the functional specification, and accelerate the development of simulators Results Months of development time eliminated Models reused throughout development Additional complexity handled without staff increases “Model-Based Design gave us advanced visibility into the functional design of the system. We also completed requirements validation earlier than was previously possible and simulated multiple simultaneous component failures, so we know what will happen and have confidence that the control logic will manage it.” Christopher Slack Airbus Primary Industry: Aerospace and Defense Secondary Industries: N/A Product Capabilities: Mathematical modeling, Algorithm development, Parallel computing, System design and simulation, Physical modeling, Verification, validation, and test Applications: Embedded systems, Control systems, Digital signal processing Products Used: MATLAB, Simulink, Curve Fitting Toolbox, MATLAB Distributed Computing Server, Parallel Computing Toolbox, Signal Processing Toolbox, SimPowerSystems, Simulink Coder, Stateflow, System Identification Toolbox Country: United Kingdom Airbus Develops Fuel Management System for the A380 Using Model-Based Design The Airbus A380, the largest commercial aircraft currently in operation, has a range of more than 8,000 miles. To enable such long non-stop flights, the A380’s 11 fuel tanks have a capacity of 250 metric tons (320,000 liters). The A380’s sophisticated fuel management system handles fueling and defueling operations on the ground, as well as fuel flow to engines and between tanks while airborne. The system can move fuel between tanks to optimize the aircraft’s center of gravity, reduce wing bending, and keep fuel within the acceptable temperature range. Airbus engineers used Simulink® and Stateflow® to develop a model of the fuel management system that was reused throughout the project. “With Model-Based Design, the model we used to represent the functional specification enabled us to validate requirements months earlier than was previously possible,” says Christopher Slack, computational analysis expert in fuel systems at Airbus. The Challenge The A380’s fuel management system must be able to safely handle any failure in the system’s 21 pumps, 43 valves, and other mechanical components. In a complex system, it’s challenging for engineers at the requirements stage to predict any problem that can result from combinations of relatively minor failures. The fuel system specification document for the A380’s predecessor, the A340, had over a thousand written requirements. “Text requirements can leave room for ambiguity and misinterpretation. When you have that many requirements, it’s difficult for anyone to understand all the possible interactions between them and identify, for example, that a requirement on page 20 conflicts with one on page 340,” says Slack. “Model-Based Design gave us advanced visibility into the functional design of the system. We also completed requirements validation earlier than was previously possible and simulated multiple simultaneous component failures, so we know what will happen and have confidence that the control logic will manage it.” - Christopher Slack, Airbus The Solution Airbus used Model-Based Design to model the A380’s fuel management system, validate requirements through simulation, and clearly communicate the functional specification. Airbus engineers used Simulink and Stateflow to model the system’s control logic, which comprises 45 top-level charts, almost 6000 states, and more than 8700 transitions. This model defines modes of operation on the ground (including refuel, defuel, and ground transfer) and in flight (including normal engine feed, center of gravity control, load alleviation, and fuel jettison). The functionality within each top-level mode is grouped into subcharts, enabling engineers to work independently on individual components in the hierarchy. The team developed a parameterized plant model of the tanks, pumps, valves, and electrical components using Simulink. Engineers can set parameter values to configure this model to represent fuel systems for any Airbus aircraft. After running closed-loop simulations of individual operational components in Simulink, the team integrated them into a complete model for system-level simulations. Using Parallel Computing Toolbox™ and MATLAB Distributed Computing Server™, the team performed Monte Carlo simulations on a 50-worker computing cluster. Over a weekend, they can run 100,000 simulated flights under varied environmental conditions and aircraft operational scenarios. The team created a desktop simulator by generating code from the plant and control logic models with Simulink Coder™. A MATLAB® based user interface enables suppliers, airline customers, maintenance engineers, and other Airbus teams to visualize how the fuel management system works and interacts with other aircraft systems. The team also used the Simulink models to develop hardware-in-the-loop (HIL) tests and commission their HIL testing rig well before the real hardware was available. After successful flight tests of the A380, the team used System Identification Toolbox™ to tune their plant model using measured flight test data. They used Signal Processing Toolbox™ to remove noise from the test data, and Curve Fitting Toolbox™ to evaluate differences between the measured data and predicted results and to predict system performance beyond the usual flight envelopes. While refining the plant model, they used SimPowerSystems™ to incorporate relays and other elements of the electrical power system. Based on the success of implementing Model-Based Design for the A380, Airbus engineers are now using this approach to develop the Airbus A350XWB’s fuel management system, reducing development time of this aircraft by one year. The Results ■ Months of development time eliminated. “On earlier projects, it took up to nine months to integrate our fuel system design with the simulated cockpit, or iron bird. Using Model-Based Design on the A380, it took less than a month,” says Slack. “Similarly, by reusing the model to commission the HIL rig, we saved three months of development and shortened the time from initial concept to first flight.” Models reused throughout development. “The Simulink and Stateflow models enabled us to validate requirements early and communicate the functional specification to our suppliers, complementing the written requirements in conformance with ARP 4754,” says Slack. “These models were reused to create desktop simulators, commission our HIL test rig, run on our virtual integration bench, and demonstrate system functionality to customers.” Additional complexity handled without staff increases. “The fuel system of the A380 is three to four times more complex than that of the A340,” notes Slack. “Model-Based Design enabled us to handle a substantially more complex project with the same size engineering team.” Learn more about Airbus: Link to user story

12 Best Practice # 3: Use the models for production code generation
To ensure success you must connect models to real system Enable a culture of modeling by removing temptation and option to write code Executable code is what makes machines move and generates profits

13 Toyota Uses MathWorks Tools to Increase Quality, Reduce Costs, and Speed Time to Market of New Vehicles Challenge Speed up design, increase quality, and reduce R&D costs by finding an alternative to traditional design methods Solution Use MathWorks tools for control design to prototype, model, test, and refine control strategies in an integrated design environment Results Deliver a better product to market faster — and at a lower cost Reduce time to embedded code Forge a pathway to innovation “MATLAB, Simulink, and Stateflow… have become the de facto standard at Toyota for simulation, data processing, and controls design. It would be impossible to list all of the applications for these tools at Toyota.” Akira Ohata Toyota Primary Industry: Automotive Secondary Industries: n/a Application Areas: Control Design Products Used: MATLAB, Simulink, MATLAB Coder, Simulink Coder, Stateflow Country: Japan MATLAB and Simulink Help Toyota Design for the Future Toyota is taking full advantage of tools like MATLAB®, Simulink®, Simulink Coder™, and Stateflow® to design, model, test and refine control strategies in an integrated design environment. This process has trimmed design times, as engineers create and test their ideas quickly and with few hardware prototypes. Now, in a development partnership with MathWorks, Toyota engineers are taking their control designers’ ideas from concept, through verification, to real production code in the same, seamless environment. The Challenge Under increasing pressure to speed up design, increase quality, and reduce R&D costs, engineers at Toyota knew that they needed an alternative to traditional design methods. These methods were neither cost-effective nor efficient, hampered as they were by costly or incomplete hardware prototypes and a design process that required re-engineering and reprogramming at several steps along the way. Toyota started looking for a way to bridge the gaps in traditional automotive electronics development and create executable specifications to consolidate the work of spec writers, control designers, and programmers. “MATLAB, Simulink, and Stateflow … have become the de facto standard at Toyota for simulation, data processing, and controls design. It would be impossible to list all of the applications for these tools at Toyota.” - Akira Ohata, Toyota The Solution Toyota adopted MathWorks tools like MATLAB, Simulink, Simulink Coder, and Stateflow, as a total design solution. Toyota’s initiative—and their development partnership with MathWorks—was set in motion when the auto maker first chose MATLAB, then Simulink. “Our use of [these tools] has been gradually increasing,” says Toyota spokesperson Akira Ohata. “We now have more than 400 licenses for MATLAB, Simulink, and Stateflow, and they have become the de facto standard at Toyota for simulation, data processing, and controls design. It would be impossible to list all of the applications for these tools at Toyota.” MathWorks tools have found a real home in the development of Toyota’s electrical control units (ECUs), the under-dash controllers that run the software that runs the vehicles. Faced with stringent emissions standards and calls for improved performance, Toyota engineers are concentrating on improving such vital logic as fuel injection and transmission controls. With design solutions from MathWorks, Toyota engineers have the significant advantage of designing, modeling, simulating, testing, and programming control strategies in a single environment. For example, specifications for Toyota’s powertrain controllers now begin in the intuitive and self-documenting environment of Simulink and Stateflow, both powered by the industrial-strength computational, analytical, and visualization capabilities of MATLAB. Controls engineers work directly in these executable specifications, refining control strategies and optimizing performance. The engineer’s work is then just a step away from working C code through Simulink Coder, with software coded per the control engineer’s intent. Toyota engineers use the code in conjunction with hardware and implementation software manufactured by dSPACE of Germany for testing and virtual prototyping. Toyota takes advantage of two types of simulation: hardware-in-the-loop (HIL) simulation, which allows testing of a prototype ECU on a “virtual engine” modeled in Simulink, and rapid prototyping ECU (RPE), which allows the simulator to replace all or part of the ECU while controlling an actual power plant. Toyota uses HIL with the Simulink virtual engine to debug ECU hardware and software and for calibration. The HIL setup reduces costs, makes it easy to analyze performance, and allows duplication of operating conditions such as cold start and warmup. In RPE, Toyota engineers can calibrate the parameters of control algorithms and quickly evaluate control logic. Developers build control logic in MATLAB and evaluate it with Simulink, finding the most promising candidates. Through the use of dSPACE hardware, the changed parts of the engine control can be segregated as the ECU controls a real auto power plant. This allows the engineers to concentrate on areas being improved or developed. The Results ■ A better product brought to market faster—and cheaper. Already, the ECU development process has been streamlined and design cycles shortened as designers work with MathWorks tools to create and test their ideas quickly and with few hardware prototypes. ■ Reduced time to embedded code. Toyota presented a chart at the Global Automotive Engineering Seminar in Troy, Michigan, in June The chart showed that Simulink, Stateflow, and Simulink Coder, in conjunction with Toyota’s own Integer Toolkit, generated code automatically that was just 5% larger and only 15% slower than Toyota’s existing handwritten C code. ■ A pathway to innovation. Toyota released a revolutionary hybrid electric vehicle in November “Simulink had a remarkable effect,” on Toyota’s HEV program, says Ohata. “It even allowed software developed in Simulink and autocoded with Simulink Coder to be used on a real ECU well into the development cycle.” Learn more about Toyota: Link to user story

14 Best Practice # 4: Treat models as the sole source of truth
Remove the temptation to hack code by hand late in a program when under time pressure Prevent divergence of code and model If you don’t, then the models will not be maintained. The MathWorks

15 Eurocopter Uses Model-Based Design to Accelerate Development of DO-178B Certified Systems
Challenge Speed up DO-178 development cycle while stabilizing system and software definitions by using models for validation and reusing the data for verification Solution Develop Plan for Software Aspects of Certification (PSAC) consistent with latest recommendations from European Aviation Safety Agency (EASA) for DO-178B, taking into account DO-178C concepts for Model-Based Design Create models in Simulink for software architecture, high-level requirements, and low-level requirements Generate flight source code using Embedded Coder Results Early requirements validation and execution of simulation test cases with Simulink Seamless object code verification by reusing simulation test cases EASA approval for the software certification with use of code generated by Embedded Coder EC130 Air Conditioning Software developed with Embedded Coder. “Using Simulink for systems and software development has provided efficient means to validate the requirements and design the system and saves time on verification and validation.” Ronald Blanrue Eurocopter Group – Avionic System Avionic Certification/EADS Expert Primary Industry: Aerospace and Defense Secondary Industries: N/A Product Capabilities: Applications: Embedded Systems, Control Systems Products Used: MATLAB, Simulink, Embedded Coder, Simulink Verification and Validation Country: France

16 Best Practice # 5: Use migration to Model-Based Design as a learning opportunity
Learn what really happens in the current system Solicit help on process and tools, not on translation Focus on value-added features first Conversion is a tremendous learning and quality improvement opportunity True even in small code footprints and efficient organizations Getting process help is good, translation of (or automation of conversion) algorithm is not. Don’t model everything. The MathWorks

17 Best Practice # 6: Focus on design, not on coding
Software design is still taking place Software engineers establish and manage the code generation infrastructure Model refinement continues after the controls engineers finish their work and before model is ready to generate code, especially in a fixed- point implementation Legacy code must be integrated and maintained Focus on design not coding. Code generation doesn’t mean software people no longer have a role. The MathWorks

18 FLIR Accelerates Development of Thermal Imaging FPGA
Raw image (left) and image after applying filter developed with HDL Coder (right). Challenge Accelerate the implementation of advanced thermal imaging filters and algorithms on FPGA hardware Solution Use MATLAB to develop, simulate, and evaluate algorithms, and use HDL Coder to implement the best algorithms on FPGAs Results Time from concept to field-testable prototype reduced by 60% Enhancements completed in hours, not weeks Code reuse increased from zero to 30% “With MATLAB and HDL Coder we are much more responsive to marketplace needs. We now embrace change, because we can take a new idea to a real-time-capable hardware prototype in just a few weeks. There is more joy in engineering, so we’ve increased job satisfaction as well as customer satisfaction.” Nicholas Hogasten FLIR Systems Primary Industry: Electronics and semiconductors Secondary Industries: NA Product Capabilities: Data acquisition, Algorithm development, HDL code generation and verification Applications: Image and video processing, FPGA design Products Used: MATLAB, Fixed-Point Toolbox, HDL Coder, Image Acquisition Toolbox, Image Processing Toolbox, MATLAB Coder, MATLAB Compiler Country: United States FLIR Accelerates Development of Thermal Imaging FPGA Thermal imaging infrared cameras are widely used in commercial applications, including security, firefighting, gas leak detection, and test and measurement. FPGAs within the cameras filter and process signals generated by sensors and detectors. Often, turning a new signal processing concept into an algorithm that runs in real time on a production camera is a lengthy process, because hardware engineers must translate algorithms developed by algorithm engineers into HDL, without intimate knowledge of how the algorithms work. At FLIR Systems, engineers develop and simulate advanced algorithms in MATLAB® and then rapidly implement them on FPGAs with HDL Coder™. “In the past, we would rarely show simulations to our customers because it could take a long time for our ideas to make it into a product,” says Nicholas Hogasten, manager of image processing technology at FLIR. “Recently, we showed a key customer some simulations of a new thermal imaging filter, the most complex filter we had ever developed. Our customer was ecstatic when, a few months later, we showed them the first working camera with this new filter, generated using HDL Coder, and the camera performed exactly like the MATLAB simulations.” The Challenge Difficulties in FLIR’s earlier development process stemmed from a disconnect between the algorithm engineers who developed new ideas and algorithms and the hardware engineers who implemented the algorithms on FPGAs. Algorithm engineers would evaluate new techniques for noise reduction or dynamic range compression and then hand off written specifications to hardware engineers, who may not have full knowledge of the algorithms. “Often, the FPGA implementation would not perform like our simulations, and we never knew if there was a problem with the implementation or with the algorithm,” says Hogasten. “Also, because the hardware engineers did not have a deep understanding of the algorithm, they did not know what assumptions were safe to make in optimizing it. If we later made a small enhancement to the algorithm, most of the HDL potentially had to be rewritten.” “With MATLAB and HDL Coder we are much more responsive to marketplace needs. We now embrace change, because we can take a new idea to a real-time-capable hardware prototype in just a few weeks. There is more joy in engineering, so we’ve increased job satisfaction as well as customer satisfaction.” - Nicholas Hogasten, FLIR Systems The Solution FLIR established a new workflow for developing FPGA-based thermal imaging algorithms using MATLAB and HDL Coder. Algorithm engineers use MATLAB and Image Processing Toolbox™ to explore new algorithms based on morphological operations and multidimensional image filtering. These engineers select the algorithms for implementation and identify the algorithmic components that map to the target FPGA hardware. During this partitioning, the team replaces high-level functions from Image Processing Toolbox with MATLAB code that supports code generation. The Image Processing Toolbox algorithms provide a golden reference, easing verification of FLIR’s custom MATLAB code. To enable bit-true simulation and analysis, the engineers use integrated floating-point-to-fixed-point workflow in HDL Coder to automatically convert the floating-point MATLAB algorithms to fixed-point MATLAB code incorporating arithmetic and data types using Fixed-Point Toolbox™. To support other test environments in use at FLIR, the team uses MATLAB Coder™ to generate C code and MEX-files from the generated fixed-point MATLAB code. Next, the team generates synthesizable HDL code from the MATLAB algorithms using HDL Coder. The HDL code is then implemented and tested on the FPGA, and the results are verified against results from the fixed-point MATLAB algorithm. In a related project, the engineers used MATLAB Compiler™ and Image Acquisition Toolbox™ to build an application that acquires images from cameras and frame grabbers, processes them using a variety of algorithms, and displays the results. This application enables other FLIR engineers to assess algorithms for a range of inputs, even if they do not have MATLAB installed. The Results ■ Time from concept to field-testable prototype reduced by 60%. “With MATLAB and HDL Coder, we’ve eliminated the step of translating the initial algorithm to HDL by hand,” says Hogasten. “Now algorithm developers can produce an FPGA prototype on their own, which has cut prototyping time by up to 60%.” ■ Enhancements completed in hours, not weeks. “Recently, I asked one of our engineers to make a significant algorithmic change to a core filter,” Hogasten reports. “Three hours later, he had made the change in MATLAB and redeployed the algorithm to the FPGA using HDL Coder. Previously, that type of change would have required six weeks.” ■ Code reuse increased from zero to 30%. “We now have a common repository of algorithms, simple components, and MATLAB code that has been verified for HDL code generation,” says Hogasten. “Previously, we had practically no code reuse, but today we reuse 30% of our MATLAB code to generate HDL for other projects.” To learn more about FLIR Systems, visit Link to user story

19 Best Practice # 7: Integrate the development process
Develop a comprehensive plan – Training Modeling Style Enforcement. Supporting Tools Configuration Management Requirements Management Process Develop new metrics

20 GM Standardizes on Model-Based Design for Hybrid Powertrain Development
Badge for GM’s Two-Mode Hybrid powertrain, which is used in vehicles across several product lines. Challenge Develop new hybrid powertrain technology for GM vehicles Solution Standardize on MathWorks tools and Model-Based Design for control systems design and production code generation Results Aggressive delivery date met Worldwide collaboration and communication enabled Designs reused across product lines “The Two-Mode Hybrid powertrain took Model-Based Design to a new level within GM. This project provided the confidence and experience we needed to apply MathWorks tools for Model-Based Design on other large-scale global engineering programs." Kent Helfrich General Motors Primary Industry: Automotive Secondary Industries: n/a Application Areas: Code Generation, Early Verification - Segment 1, Event-Based Modeling, Model-Based Design, Verification, Validation, and Testing Products Used: MATLAB, Simulink, Embedded Coder, MATLAB Coder, Simulink Coder, Stateflow Country: USA GM Standardizes on Model-Based Design for Hybrid Powertrain Development General Motors’ Two-Mode Hybrid powertrain optimizes fuel efficiency for a range of driving conditions, including stop-and-go city driving, rapid acceleration, and steady-state highway driving. Widely recognized as a major advance in hybrid technology, the Two-Mode Hybrid combines a conventional engine with two 60 kW electric motors integrated into an automatic transmission with three planetary gear sets. GM engineers used Model-Based Design to develop the Two-Mode Hybrid powertrain control system, which is now in production in GMC Sierra Hybrid, GMC Yukon Hybrid, Chevy Tahoe Hybrid, Chevy Silverado Hybrid, and Cadillac Escalade Hybrid vehicles and will be adapted for use in the Chevy Volt, GM’s extended-range electric vehicle. “By enabling us to work at a higher level of abstraction, verify our designs through early system simulation, and automatically generate production code from our models, Model-Based Design gave us the flexibility to try new approaches and control strategies virtually, rapidly make changes, and eliminate translation errors common in hand-coding,” says Greg Hubbard, senior manager, Hybrid and Electric Drive Controls, GM. The Challenge GM wanted vehicles with the Two-Mode Hybrid powertrain in production within four years. For a conventional powertrain project, this timing would be typical, because the engineering team could start with an existing design. Early Two-Mode Hybrid technology had been developed by GM and Allison for use in transit buses now in operation in over 100 cities, but because the technology needed to be “leaner and greener” for passenger car and truck applications, the team had to start from scratch. “Creating well over a million lines of code on a compressed schedule, while ensuring that the control system meets GM’s high quality standards and complying with all legislative regulations and safety standards, was a tremendous challenge,” says Hubbard. GM engineers also had to optimize the design for several competing objectives, including fuel economy, responsiveness, and driver comfort, while keeping the design flexible enough to use across a range of vehicles. To do that, GM engineers had to ensure that several complex systems worked together to optimize performance. “Integrating the engine, transmission, electric motors, and battery with the power management strategy is the key to hybrid system design,” explains Kent Helfrich, director of Powertrain Software Engineering at GM. “These systems are too complex to build separately and integrate in a final step.” In addition, GM engineers needed to verify their designs before committing them to hardware. “The Two-Mode Hybrid powertrain took Model-Based Design to a new level within GM. This project provided the confidence and experience we needed to apply MathWorks tools for Model-Based Design on other large-scale global engineering programs.” - Kent Helfrich, General Motors The Solution GM used MathWorks tools and Model-Based Design to develop system models, verify designs using simulation, and generate production code for the Two-Mode Hybrid powertrain control system. This approach enabled GM engineers to explore multiple strategies, accelerate design iterations, minimize prototypes and rework, and verify the control system before hardware was available. Using MATLAB, Simulink, and Stateflow, GM engineers designed the control system architecture and modeled all the control and diagnostic functions, including hybrid operating strategy, engine start-stop, active damping, shift execution, and propulsion safety. At the same time, they created detailed plant models for all relevant physical systems, such as the engine, electric motors, battery, hybrid transmission, and vehicle dynamics. Running closed-loop simulations with the plant model, they verified the control system using standard city and highway driving fuel economy tests. After generating production code for the engine, transmission, and hybrid energy management ECUs using Embedded Coder, they further verified the control systems using Simulink Coder and hardware-in-the-loop (HIL) simulators with the plant models and test cases from the non-real-time verification phase. Comparing the results of these tests enabled the engineers to identify ECU integration issues. When the hybrid powertrain hardware became available, the team was able to move quickly from HIL to prototype vehicles for confirmation testing. The Two-Mode Hybrid powertrain has won several awards, including Technology of the Year from Automobile magazine and Green Car of the Year from Green Car Journal. The Results Aggressive delivery date met. “Just nine months after we started the project, we had our first prototype vehicle running,” says Hubbard. “We would not have been able to do that without MathWorks tools. The software enabled us to complete significant amounts of design work before hardware was available.” Worldwide collaboration and communication enabled. GM engineers in Michigan shared Simulink models with GM engineers in Europe and Asia. As a result, teams around the world could work on different aspects of the design—such as control strategies, software design, and physics problems—at the same time, leveraging each engineer’s strengths and eliminating integration issues. “The Simulink models served as a single source of truth for teams around the world,” says Hubbard. Designs reused across product lines. “We are reusing the controller architecture for additional vehicles that are in production, including the GMC Sierra and Chevy Silverado, as well as the forthcoming Chevy Volt,” says Hubbard. “The control system design for the Chevy Volt progressed quickly because we were able to reuse the controller architecture.” To learn more about General Motors, visit Link to user story

21 Best Practice # 8: Designate a champion who has influence and budgetary control
Assign priority Assign people Acquire tools, equipment, and services Sometimes act as a consensus builder Sometimes act as a benevolent dictator

22 Lockheed Martin Joint Strike Fighter
THREE AIRCRAFT, A SINGLE MODEL, AND 80% COMMON CODE. THAT’S MODEL-BASED DESIGN. To develop the unprecedented three-version F-35, engineers at Lockheed Martin created a common system model to simulate the avionics, propulsion, and other systems and generate final flight code. The result: reusable designs, rapid implementation, and global teamwork. To learn more, visit mathworks.com/mbd Accelerating the pace of engineering and science

23 Best Practice # 9: Have a long-term vision
Good things come to those who have a vision and work hard to achieve it The full transition from hand-coded, textual languages takes 2-3 years to fully implement in a production organization Research organizations often have fewer constraints and less legacy code, and can move faster

24 Best Practice # 10 : Partner with your tool suppliers
Suppliers bring the experience of working with entire industries and can help you avoid common pitfalls, accelerate your ROI breakeven point and quickly achieve productivity and quality goals Effort Time Do it yourself Leverage the supplier’s experience

25 Mazda Speeds Next-Generation Engine Development of SKYACTIV TECHNOLOGY
Mazda’s SKYACTIV-D engine. Mazda Speeds Next-Generation Engine Development of SKYACTIV TECHNOLOGY Challenge Optimize the efficiency of SKYACTIV engines while meeting strict emissions standards worldwide Solution Use Simulink and Model-Based Calibration Toolbox to accelerate the generation and development of optimal calibration settings, ECU-embeddable models, and engine models for HIL simulation Results Engine calibration workload minimized Model complexity cut in half Model accuracy improved “Model-Based Calibration Toolbox not only enabled us to identify optimal calibration settings for the SKYACTIV-D engine, it greatly reduced the engineering effort required. The models it generated accelerated control logic development, provided valuable insights, and made it easy to try new ideas.” Shingo Harada Mazda Primary Industry: Automotive Secondary Industries: NA Product Capabilities: Mathematical modeling, Algorithm development, System design and simulation Applications: Embedded systems, Control systems Products Used: MATLAB, Simulink, Model-Based Calibration Toolbox Country: Japan Mazda Speeds Next-Generation Engine Development of SKYACTIV TECHNOLOGY SKYACTIV TECHNOLOGY engine development is enabling Mazda to commercialize fuel-efficient diesel and gasoline engines that do not rely on downsizing and lean burn. SKYACTIV-G is the world’s first gasoline engine for mass production vehicles to achieve a compression ratio of 14.0:1, resulting in a 15% increase in efficiency and torque. Its diesel counterpart, SKYACTIV-D, has the world’s lowest diesel-engine compression ratio, enabling it to deliver 20% more fuel efficiency while meeting strict exhaust regulations—including Euro6 and automobile exhaust gas regulations in Japan—without using costly exhaust after-treatment that reduces nitrogen oxide (NOx) emission. Mazda engineers relied on MATLAB®, Simulink®, and Model-Based Calibration Toolbox™ for engine controller design, verification, and calibration. “SKYACTIV engines incorporate hardware advances that deliver more torque and improve fuel economy,” says Shingo Harada, assistant manager at Mazda. “Model-Based Calibration Toolbox helped us exploit these advances, extracting better fuel efficiency and lower exhaust emissions than would have possible with manual, spreadsheet-based calibration approaches.” The Challenge As Mazda engines have grown more complex, it has become increasingly difficult to find optimal calibration settings using traditional approaches. “Trial and error with a spreadsheet and a test cell required extensive lab time, making it difficult to meet delivery schedules,” says Harada. “More importantly, finding an optimal solution in a search space of five or more dimensions is difficult even for experienced calibration engineers, so we could never be certain that we had found the best possible settings.” Mazda wanted to reduce the SKYACTIV-D’s compression ratio to minimize soot and NOx emissions. To achieve this and other design objectives, engineers required ECU-embeddable statistical models of maximum cylinder pressure and exhaust gas temperature. Initial versions of these models had 40 parameters each and were too complex to run on the ECU. Mazda needed to reduce model complexity without sacrificing accuracy. “Model-Based Calibration Toolbox not only enabled us to identify optimal calibration settings for the SKYACTIV-D engine, it greatly reduced the engineering effort required. The models it generated accelerated control logic development, provided valuable insights, and made it easy to try new ideas.” - Shingo Harada, Mazda The Solution Mazda used Simulink and Model-Based Calibration Toolbox to define test plans, develop statistical models, and generate optimal calibrations for the SKYACTIV-D engine. They used the same products to develop statistical models for the SKYACTIV-G and perform hardware-in-the-loop (HIL) simulation of engine control logic. Mazda used Model-Based Calibration Toolbox to design an optimized test plan for the SKYACTIV-D engine based on design of experiments. The plan included only the test points required to characterize engine performance and emission responses, minimizing testing time. After conducting tests on a test cell, the engineers used Model-Based Calibration Toolbox to import the measured data and develop statistical models of the engine responses. Using the Calibration Generation (CAGE) tool in Model-Based Calibration Toolbox and a MATLAB based optimization interface developed in-house, the team generated optimal calibrations from the engine models. To define a realistic operating region for simulation, optimization, and embedded model evaluation, they used Model-Based Calibration Toolbox to create a boundary model. With Model-Based Calibration Toolbox, Mazda engineers generated embeddable models, including the maximum cylinder pressure model used on the production SKYACTIV-D ECU. For the same ECU, they generated a total mass of injected fuel as a function of multiple operating-point variables. This model was used with an exhaust temperature model, also generated by Model-Based Calibration Toolbox, to improve the reliability and performance of the fuel mass model. SKYACTIV-D engines meet stringent European and Japanese emission standards and are installed in production vehicles, including the Mazda CX-5. Engineers working on the SKYACTIV-G engine developed a statistical engine fuel-consumption model using Model-Based Calibration Toolbox. They exported this model to Simulink for use in the development, debugging, and HIL simulation of the engine control logic. The model was reused in automatic transmission fuel consumption simulations, further reducing the model development effort. The Results ■ Engine calibration workload minimized. “With traditional methods, getting data when calibrating a new engine required a large amount of testing,” says Harada. “With Model-Based Calibration Toolbox, we reused the existing data and simulated the responses, which enabled us to minimize both the workload to obtain test data and test cell usage.” ■ Model complexity cut in half. “Our initial embedded maximum cylinder pressure model had 38 parameters. With Model-Based Calibration Toolbox, we reduced that number to 20, which in turn reduced the load on the CPU,” notes Harada. “Similarly, the toolbox enabled us to reduce the number of parameters in our exhaust gas temperature model from about 40 to 20 while maintaining the same level of accuracy.” ■ Model accuracy improved. “Using a boundary model created with Model-Based Calibration Toolbox, we improved the accuracy of our smoke model and reduced its root-mean-square error (RMSE) by 80%,” says Harada. To learn more about Mazda SKYACTIV TECHNOLOGY, visit Link to user story

26 Mazda Speeds Next-Generation Engine Development of SKYACTIV TECHNOLOGY
Mazda’s SKYACTIV-D engine. Mazda Speeds Next-Generation Engine Development of SKYACTIV TECHNOLOGY Challenge Optimize the efficiency of SKYACTIV engines while meeting strict emissions standards worldwide Solution Use Simulink and Model-Based Calibration Toolbox to accelerate the generation and development of optimal calibration settings, ECU-embeddable models, and engine models for HIL simulation Results Engine calibration workload minimized Model complexity cut in half Model accuracy improved “Model-Based Calibration Toolbox not only enabled us to identify optimal calibration settings for the SKYACTIV-D engine, it greatly reduced the engineering effort required. The models it generated accelerated control logic development, provided valuable insights, and made it easy to try new ideas.” Shingo Harada Mazda Primary Industry: Automotive Secondary Industries: NA Product Capabilities: Mathematical modeling, Algorithm development, System design and simulation Applications: Embedded systems, Control systems Products Used: MATLAB, Simulink, Model-Based Calibration Toolbox Country: Japan Mazda Speeds Next-Generation Engine Development of SKYACTIV TECHNOLOGY SKYACTIV TECHNOLOGY engine development is enabling Mazda to commercialize fuel-efficient diesel and gasoline engines that do not rely on downsizing and lean burn. SKYACTIV-G is the world’s first gasoline engine for mass production vehicles to achieve a compression ratio of 14.0:1, resulting in a 15% increase in efficiency and torque. Its diesel counterpart, SKYACTIV-D, has the world’s lowest diesel-engine compression ratio, enabling it to deliver 20% more fuel efficiency while meeting strict exhaust regulations—including Euro6 and automobile exhaust gas regulations in Japan—without using costly exhaust after-treatment that reduces nitrogen oxide (NOx) emission. Mazda engineers relied on MATLAB®, Simulink®, and Model-Based Calibration Toolbox™ for engine controller design, verification, and calibration. “SKYACTIV engines incorporate hardware advances that deliver more torque and improve fuel economy,” says Shingo Harada, assistant manager at Mazda. “Model-Based Calibration Toolbox helped us exploit these advances, extracting better fuel efficiency and lower exhaust emissions than would have possible with manual, spreadsheet-based calibration approaches.” The Challenge As Mazda engines have grown more complex, it has become increasingly difficult to find optimal calibration settings using traditional approaches. “Trial and error with a spreadsheet and a test cell required extensive lab time, making it difficult to meet delivery schedules,” says Harada. “More importantly, finding an optimal solution in a search space of five or more dimensions is difficult even for experienced calibration engineers, so we could never be certain that we had found the best possible settings.” Mazda wanted to reduce the SKYACTIV-D’s compression ratio to minimize soot and NOx emissions. To achieve this and other design objectives, engineers required ECU-embeddable statistical models of maximum cylinder pressure and exhaust gas temperature. Initial versions of these models had 40 parameters each and were too complex to run on the ECU. Mazda needed to reduce model complexity without sacrificing accuracy. “Model-Based Calibration Toolbox not only enabled us to identify optimal calibration settings for the SKYACTIV-D engine, it greatly reduced the engineering effort required. The models it generated accelerated control logic development, provided valuable insights, and made it easy to try new ideas.” - Shingo Harada, Mazda The Solution Mazda used Simulink and Model-Based Calibration Toolbox to define test plans, develop statistical models, and generate optimal calibrations for the SKYACTIV-D engine. They used the same products to develop statistical models for the SKYACTIV-G and perform hardware-in-the-loop (HIL) simulation of engine control logic. Mazda used Model-Based Calibration Toolbox to design an optimized test plan for the SKYACTIV-D engine based on design of experiments. The plan included only the test points required to characterize engine performance and emission responses, minimizing testing time. After conducting tests on a test cell, the engineers used Model-Based Calibration Toolbox to import the measured data and develop statistical models of the engine responses. Using the Calibration Generation (CAGE) tool in Model-Based Calibration Toolbox and a MATLAB based optimization interface developed in-house, the team generated optimal calibrations from the engine models. To define a realistic operating region for simulation, optimization, and embedded model evaluation, they used Model-Based Calibration Toolbox to create a boundary model. With Model-Based Calibration Toolbox, Mazda engineers generated embeddable models, including the maximum cylinder pressure model used on the production SKYACTIV-D ECU. For the same ECU, they generated a total mass of injected fuel as a function of multiple operating-point variables. This model was used with an exhaust temperature model, also generated by Model-Based Calibration Toolbox, to improve the reliability and performance of the fuel mass model. SKYACTIV-D engines meet stringent European and Japanese emission standards and are installed in production vehicles, including the Mazda CX-5. Engineers working on the SKYACTIV-G engine developed a statistical engine fuel-consumption model using Model-Based Calibration Toolbox. They exported this model to Simulink for use in the development, debugging, and HIL simulation of the engine control logic. The model was reused in automatic transmission fuel consumption simulations, further reducing the model development effort. The Results ■ Engine calibration workload minimized. “With traditional methods, getting data when calibrating a new engine required a large amount of testing,” says Harada. “With Model-Based Calibration Toolbox, we reused the existing data and simulated the responses, which enabled us to minimize both the workload to obtain test data and test cell usage.” ■ Model complexity cut in half. “Our initial embedded maximum cylinder pressure model had 38 parameters. With Model-Based Calibration Toolbox, we reduced that number to 20, which in turn reduced the load on the CPU,” notes Harada. “Similarly, the toolbox enabled us to reduce the number of parameters in our exhaust gas temperature model from about 40 to 20 while maintaining the same level of accuracy.” ■ Model accuracy improved. “Using a boundary model created with Model-Based Calibration Toolbox, we improved the accuracy of our smoke model and reduced its root-mean-square error (RMSE) by 80%,” says Harada. To learn more about Mazda SKYACTIV TECHNOLOGY, visit Link to user story

27 Best Practices for Establishing a Model-Based Design Culture
Identify the problem you are trying to solve Use models for at least two things – “Rule of Two” Use models for production code generation Treat models as the sole source of truth Use migration as a learning opportunity Focus on design, not on coding Integrate the development process Designate champions with influence, expertise, and budgetary control Have a long-term vision Partner with your tool suppliers


Download ppt "Best Practices for Model Based Design (MBD)"

Similar presentations


Ads by Google