550 likes | 1.07k Views
MotoHawk Training. Model-Based Design of Embedded Systems. Course Outline. Why Model-Based Design? The MotoHawk ™ System w/ Demonstration The Simulink ® Model The MotoHawk ™ Way Advanced Software & Hardware Issues Real Application Challenge. Model-Based Design. Hand-Coding.
E N D
MotoHawk Training Model-Based Design of Embedded Systems
Course Outline • Why Model-Based Design? • The MotoHawk™ System w/ Demonstration • The Simulink® Model • The MotoHawk™ Way • Advanced Software & Hardware Issues • Real Application Challenge
Model-Based Design Hand-Coding H/W Verification against Specification Specification H/W Verification against Model Extra Time & Money Modeling S/W Design S/W Verification S/W Implementation S/W Debugging Time Why Model-Based Design?
Models Traditional Application Development Source code Application File Compiler Linker source Specification Loader code Application Engineers Software Engineers Model Based Application Development Models Source code Application File Code Gen Compiler Linker source Loader Interfaces code Application Engineers Development Process Comparison
MotoHawk™ ECU-based Rapid Prototyping • Key Benefits • Better testing using real ECU hardware • Faster cycle time for adding new features and enhancing existing features • Improved documentation of system design via working models of the system • Better ability to control IP development • Key Features • ControlCore enabled • Development is completed on the production capable ECU and related software • Calibration using MotoTune • Optional HUD • ECU’s available for development, pilot, or production
Custom HW Prototype MotoHawkTM Prototype Working Closer to Production Environment In Loop Testing Define Requirements& Architecture Hardware In LoopTesting Define Algorithms Production Code Generation
MotoHawk™ Demonstration • Open the model in Simulink • Generate Code • Compile and Link • Download to ECU • Run!
System Trigger Subsystem Block Port Signal The Standard Simulink® Model
Simulink Elements Systems, Blocks Port Signal Trigger Software Elements Functions, Encapsulation Interfaces Values, Variables Function-calls, Events Modeling Software with Simulink®
Modeling Software with Simulink® • Native Simulink block diagrams can represent signal processing very well • Blocks can represent H/W Input & Output • Function-call triggers can represent events • Library links can represent references and provide model reuse
The MotoHawk™ Way “Model the elements of the whole system, including the processor, build environment, memory, and operating system.” Elements of Simulink®: • Modeling & Simulation Environment • Code Generation Elements of MotoHawk™: • Input & Output Model • Operating System Model • Integrated Build Environment
Engine-specific peripherals MotoHawk™ Input & Output Model: • Model blocks for ECU I/O and engine-specific peripherals • Examples: • Digital Inputs & Outputs • Analog-to-Digital Inputs • PWM Outputs • Serial Inputs & Outputs • CAN Inputs & Outputs • Electronic Spark Timing Outputs • Engine Knock Inputs • Fuel Injector Control Outputs
MotoHawk™ Operating System Model • Model blocks for program flow and triggering • Examples: • Periodic Tasks • Interrupts • Operating System Events
MotoHawk™ Build Environment • Whole process, from pictures to working machine, in one environment • Simulation • System Verification • Code Generation • Makefile Generation • Compile, Link, Locate, and Program • Integration with Calibration Tools • Documentation
MotoHawk™ and Simulink® Together • Simulink® is excellent for modeling control laws • Native Simulink® is not very expressive for modeling general software systems • MotoHawk™ adds real-time software elements to the Simulink® environment
Control Law Design system simulation model Design MotoHawk™ software model Reuse control law Control System Example
Problems with the diagram • The control law should be designed using discrete elements • We would like to allow a continuous plant model • We would like to take advantage of Variable-Step simulation • We need to simulate discrete sampling of the control law
Designing a Control System • The control law example specifies ‘what’ to do in the controller, the ‘logic’ • To design a system, we need to also specify ‘when’ to execute the control logic • To test the control logic, we would like to simulate the controller with a continuous plant model
Sample Inputs Update Outputs Passive Control Law MotoHawk™ Software Model
Reuse & Abstraction • We reused the control law block, which we place into a library • We convert H/W input values to standard units used by the control law • We convert from standard units used by the control law to H/W output values
Hardware and Software Issues • We try to separate the controller design from the H/W and S/W issues • Some systems are more complex • Probes, calibrations, overriding signals • Distributed systems, with multiple controllers • Multi-rate and asynchronous systems • Task preemption and long calculations
Probes, Calibrations, and Overrides • MotoHawk™ seamlessly integrates with MotoTune™, a calibration tool allowing real-time observation and control. • Probes allow monitoring of values • Calibrations allow adjustment of constants • Overrides allow signal modification for testing • This typical S/W issue has been abstracted into the model
MotoTune®Development Tool • Used to program the MotoTron ECU(s). • Used to interact with the application running on the ECU. • Capable of modifying calibration parameters real-time. • Capable of monitoring and overriding values throughout the application software. • Capable of real-time charting of development data.
Distributed Systems, Multiple Controllers • The system simulation model may use more than one controller, but still use one plant model • Each controller has its own sampling trigger, possibly at different rates • Each controller will have its own MotoHawk™ software model, for code generation • The controllers may use different target hardware
Multi-Rate Controllers • System simulation uses same picture as the distributed system • Multiple tasks, each modeled as a unique controller • Only one MotoHawk™ software model, using multiple triggers, one for each task • The processor only runs one task at a time, so we must be aware of task priority and data coherency between tasks
Task Preemption • If we want to use multiple tasks, we must be very careful about the priority of tasks, and nesting of interrupts • MotoHawk uses ControlCore, MotoTron’s ECU-Based RTOS, with a foreground / background scheduler, and queued interrupt handlers.
Task Preemption • Lower priority tasks may be delayed by higher priority tasks • The system must be designed to allow for these delays • When a task interruption occurs, all data movement between tasks must be coherent • MotoHawk™ provides Critical Region blocks to handle atomic data transfer between asynchronous tasks
MotoHawk™ Application Challenge • Using Slider 1 as a throttle command, read the analog voltage and convert the output value (0-1023) to a 0-5V signal. • Read the throttle position from analog input AN4 and convert the output value (0-1023) to a 0-5V signal. • Determine the error and use a basic PI controller to provide PWM ETC A with a duty cycle command.
Conclusion • Why do model-based rapid-prototyping using MotoHawk™ • Better testing using real ECU hardware • Faster cycle time • Improved documentation of system design • Better ability to control IP development • Calibration using MotoTune • ECU’s available for development, pilot, or production