Downloaded 250 times
![Simulation
Simulink scopes
Code debugging
Data analysis in MATLAB
Magnitude [dB]
0
-50
-100
-150
-200
-250
0
1000
2000
3000
Frequency [kHz]
4000
5000
0
1000
2000
3000
Frequency [kHz]
4000
5000
Phase [Degrees]
0
-1000
-2000
-3000
23](https://image.slidesharecdn.com/mbdembeddedworld-140305141020-phpapp02/75/Model-Based-Design-For-Motor-Control-Development-23-2048.jpg)
Uploaded byThe Hartford
Model-Based Design For Motor Control Development
The document discusses model-based design for developing motor control applications. It describes modeling motor control systems using Simulink, simulating the models to analyze system behavior, and automatically generating C code to run on an embedded platform. Key aspects covered include modeling the motor, electronics, interfaces and control algorithm, generating generic C code, and interfacing this code to the embedded target using device drivers. The approach allows debugging the application through offline simulation and testing on the embedded hardware in real-time.
More Related Content
Similar to Model-Based Design For Motor Control Development
Model-Based Design For Motor Control Development
- 1. The World Leaderin High Performance Signal Processing Solutions Model-Based Design For Motor Control Development Paul Crook – Analog Devices
- 2. Topics Developing motor controlapplications using modelbased design and automatic code generation Hardware platform Model-Based Design overview Modeling of motor control systems Simulation and automatic code generation Running generic C-code on embedded platform When to use MBD and when to use “traditional” design methods 2
- 3. ADI Demo Platforms MotorDrive hardware 3 phase PM motor PC with MATLAB®, Simulink®, and IAR Embedded Workbench 3
- 4. HW Platform 100V-250V ACinput with PFC, 5A Isolated current, position, voltage and diagnostic feedback 3-phase, 0.55kW, permanent magnet synchronous motor 4
- 5. ADSP-CM40x EmbeddedTarget Key Points ARM CORTEX M4F 240MHz Two 16-bit ADCs 380ns conversion time SINC filter 384kB SRAM 2MB Flash 20 DMA channels Peripherals for motor control Communication interfaces 5
- 6.
- 7. Why Model-Based Design? • • • • 7 RequirementsDevelopment System Simulation Automatic Code Generation Continuous Verification
- 8. The Traditional DesignProcess Requirements Phase Design Phase Realization Phase Testing Phase 8
- 9. Traditional Design ofa Multi-Domain System Research & Requirements Hardware Software Mechanical Requirements Requirements Requirements Design Design Design Realization Realization Realization Testing Testing Testing Integration, Test & Certification 9
- 10. The Cost ofa Traditional Design Process Source: ROI for IV&V, NASA 10
- 11. Model-Based Design RESEARCH • Modelmulti-domain systems REQUIREMENTS • Explore and optimize system behavior in floating point and fixed point DESIGN Environment Models Algorithms IMPLEMENTATION TEST & VERIFICATION Physical Components • Collaborate across teams and continents • Generate efficient code • Explore and optimize implementation tradeoffs C, C++ ARM • Automate regression testing • Detect design errors • Parameter tuning INTEGRATION 11 • Support certification and standards
- 12. Model-Based Design forEmbedded System Development Executable models - Unambiguous -“One Truth” Executable Specifications Simulation - Reduces “real” prototypes - Iterative “what-if” analysis Design with Simulation Models Continuous Test and Verification Automatic Code Generation Automatic code generation 12 - Minimizes coding errors Test with Design - Detects errors earlier
- 13. Steps in MBDapproach 1. Plant modeling - Motor, load, power electronics etc. 2. Interface modeling - Sensors, device drivers 3. Controller modeling - Field oriented control of 3 phase PM motor 4. Analysis and synthesis - The models created in step 1-3 are used to identify dynamic characteristics of the plant model. - Tuning and configuration of system 5. Validation and test - Offline simulation and/or real-time simulation - Time response of the dynamic system is investigated 6. Deployment to embedded target - Automatic code generation - Test and verification 13
- 14. Steps in MBDapproach System Model Test Signals Controller Model Motor/inverter Model Verify PC Code Generation System Embedded Controller Motor/inverter Target HW Motor Drive System Simulation of Controller and Plant model Off-line development of algorithms without access to HW Code generation and deployment to embedded controller Comparison between simulation and actual implementation 14
- 15. Model complexity What isa good model? Represent the states of interest Supports automatic code generation Execute fast Use existing (trusted) libraries Reusable across platforms Right balance Too little 5 15 ? Too much
- 16. Model complexity Understanding strengthsand weaknesses of tools is critical when defining model scope Strength Weakness 16 - Solving differential equation - Time domain modeling - Visualization - Target specific setup - Managing system resources - Time scheduling - Register setup and control - Managing System resources - Time scheduling - Real time control systems - Debugging and test - Visualization
- 17. Interfacing to EmbeddedTarget SW architecture C-code needs to be tied to embedded platform Utilizing strength of multiple environments Graphical environment for application code development “Classic” C-code for target specific control Platform independent Generic Control Algorithm Platform dependent HW interface layer Embedded Platform 17
- 18. Interfacing Embedded Target Two platforms – one implementation Common control algorithm for Simulation and Embedded system Platform specific device drivers or behavioral models Debug algorithm using simulation and test on embedded platform 18
- 19. Drive system feedbackand control Feedback 19
- 20. Motor Control ApplicationProgram Power Inverter and Motor Device Driver Auto code MC Algorithm MC Application Firmware 20 MC „C‟ code CC & Link Device drivers Application code Sensors, interfaces and Device Drivers
- 21. AC Motor Algorithm(Field Oriented Control) 21 Shaft position sensor measures rotor magnet (flux) position – velocity is calculated. Two/three motor currents measured (two is enough). Clarke-Park transfer calculate Torque (Iq) and Flux (Id) components of current. Speed loop generates Iq reference; Id reference set to zero for PMSM. Current loops and Field alignment generates a,b,c voltage commands.
- 22.
- 23. Simulation Simulink scopes Code debugging Dataanalysis in MATLAB Magnitude [dB] 0 -50 -100 -150 -200 -250 0 1000 2000 3000 Frequency [kHz] 4000 5000 0 1000 2000 3000 Frequency [kHz] 4000 5000 Phase [Degrees] 0 -1000 -2000 -3000 23
- 24.
- 25. Building and Linking– IAR EWB 25
- 26. Building and Linking ARMLibrary Motor Control - M3/M4 support - FOC functions Matlab/Simulink Legacy code Device Drivers - Existing code - Functional model C-code Device drivers System resources - SW enablement package - Allocation & setup C-code Workbench Application code - State machines Scheduling Executable CM40x 26 C-code - IRQs/RTOS
- 27. Running target MATLAB GUI+ embedded engine Streaming data back to MATLAB Captured runtime data Duty-cycle 1000 500 0 -500 -1000 Phase current 4 0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 140 160 180 200 0 20 40 60 80 100 120 Sample number 140 160 180 200 x 10 4 3.5 3 2.5 Rotor angle 8 6 4 2 0 27
- 28.
- 29. Summary Model-Based Design Systemmodeling and simulation Automatic code generation Modeling of motor control systems Electronics/mechanical Interfaces Control algorithm Interfacing generic C-code to embedded target Use of different environments Device drivers Debugging Off-line In 29 real-time and test
- 30.
Editor's Notes
- #2 Welcome (30 mins)Introduce selfIntroduce topic – utilising model based design for motor control development and featuring our latest mixed signal processor aimed at these applications – the ADSP-CM40x
- #4 Picture of the development platformPM motor110/220V power boardMCU development boardEmulatorIAR Embedded WorkbenchMatlab Simulink
- #5 Block diagram of the hardware400W (0.5 HP) PM motorDriven by 3 phase driveIGBT moduleDriven by PWM signals Isolated measurment of DC link voltage and currentPFC circuitryOptions for phase current sensing:HEShunt via isolated sigma delta modulatorsPosition feedback optionsResolver via RDCEncoderADSP-CM40xARM Cortex M414 bit dual simultaneous sampling ADC4 channels of sinc filters for glueless interfacing to isolated sigma delta modulatorsComminations interfaces – CAN, RS485 and Rs232
- #6 A little more detail on the MCU….
- #7 Now moving on to discuss the development tool chain and, specifically MBD related to this application
- #8 So what are the advantages to taking a MBD approach to development:The method allows clear and early inclusion of the system requirements within the modelPrior to the availability of hardware, system simulationAutomatic code generation from the modelThe ability to continuously verify results obtained from the hardware against the those obtained for the model
- #9 The traditional design sequence
- #10 This traditional design sequence can be expanded to encompass each aspect of the system:HardwareSwMechanicalFinally there is the need for integration and system verification testing
- #11 Chart shows relative costs of defects found at various stages of developmentNote how costly it can be if issues with the requirements are identified during the testing phase….
- #12 Diagram illustrates the flow of implementation using MBD:Model can incorporate mechanical, hw and sw systems allowing collaboration across multi-disciplinary teamsThe effect of different degrees of precision on system performance can be exploredCode can be automatically and efficiently generated from this model for the target hardwareThe effects of modification to the model can be easily explored bpthsithin the simulation environment and within the target system
- #13 Adding further detail:Requirements specifications can be accurately and unambiguously captured within the modelSimulation allows us to conduct what if scenario testingFrom the model we can generate code which minimizies errors which may be introduced from hand codingThe model based approach allow coninuous testing and verification agains requirements
- #14 Here we have the standard ‘V’ model of project development.The model for this motor control application was developed in the following sequence:
- #15 Here we show the discrete models for the controller and plant.The controller algorithms can be developed without access to hardware and code automatically generated for the embedded targetThe results from both the simulation and implementation on target hardware can then be compared.
- #16 Results are only as good as the modelUse of libraries is essential – if everything has to be developed from the ground up the work is significant
- #17 The scope of the model should be confined to exploit the strengths of the modelling environment:Algorithm developmentVisualisationTasks such as time scheduling and management of systm resources are bedt handled outside of the model
- #18 Architecture is similar to “normal” systemThe development sequence and development method is different
- #19 Simulation, debugging, development -> PC platformSystem test, production code -> embedded platformOne system needs to run on two platformsSimulation environment has functional model of device drivers (type, interface)
- #20 Model must reflect the real systemExpected to be a clear link between system block diagram and model
- #21 Electric and electromechanicalMeasurement systemDevice driversControl algorithmCode generation for SILCode generation for embedded target
- #22 Diving down from top level into Motor Control AlgorithmFOC of 3 phase PM motor
- #23 Modeling technique relates to nature of systemDifferential equationsState-machinesContinuous/discrete timeTime/frequency domainDemo program demonstrates how to use all common modeling techniquesStandard Simulink blocksSimScape modelsMatlab scriptsLegacy C-code
- #24 Time and frequency domain analysis
- #25 Parts or all of the model can be build into C-codeExtensive configuration optionOptimization and cross-optimizationStatic testAdvisories
- #29 Two sampling domains