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

Why Model-Based Design? Hand-Coding Model-Based Design Specification Modeling S/W Implementation S/W Design S/W Debugging S/W Verification H/W Verification against Model H/W Verification against Specification Time Extra Time & Money

Development Process Comparison source code Software Engineers Source Compiler Linker Application File Specification Application Engineers Models Loader Traditional Application Development Code Gen Model Based Application Development Interfaces

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

Working Closer to Production Custom HW Prototype Define Requirements & Architecture MotoHawkTM Prototype Environment In Loop Testing Define Algorithms Hardware In Loop Testing Production Code Generation

Code Generation Process Flow

Modeling with MotoHawk™

Blinking LED: MotoHawk™

MotoHawk™ Demonstration Open the model in Simulink Generate Code Compile and Link Download to ECU Run!

The Standard Simulink® Model Trigger Block Signal Subsystem Port System

Modeling Software with Simulink® Simulink Elements Systems, Blocks Port Signal Trigger Software Elements Functions, Encapsulation Interfaces Values, Variables Function-calls, Events

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

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 Engine-specific peripherals

MotoHawk™ Input & Output Model:

MotoHawk™ Operating System Model Model blocks for program flow and triggering Examples: Periodic Tasks Interrupts Operating System Events

MotoHawk™ Input & Output Model:

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 System Example Control Law Design system simulation model Design MotoHawk™ software model Reuse control law

Control Law Example

Simulation with the Control Law

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

Improved System Simulation

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

MotoHawk™ Software Model Sample Inputs Passive Control Law Update Outputs

Sampling Inputs from the Hardware

Updating Outputs to the Hardware

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

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

Calibratable Lookup Tables

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.

The MotoTune® Display

Distributed Systems, Multiple Controllers

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

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

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

MotoTron Control Solutions Production Controls in a Flash   MotoTron Control Solutions Production Controls in a Flash