MotoHawk:Model-Based Design

Why Model Based Design?

Model Based Design can save Time and Cost.

The V diagram below compares hand coding with Model Based Design. The process starts at the upper left with Specifications. Often, these specifications are in the form of graphical representations such as a flow chart. The process continues downward along the left to modeling of the system and then Designing and Implementing Software to meet the requirement. Once the software is written, then the process continues up along the right of the V, towards debugging the software, SW verification, and then to verification on hardware. This is in low level code.

Model Based design allows the Application Designer to work at the Model Level, cutting out the time and expense involved in SW Design, Implementation, SW Debugging, and SW verification. The low level software for drivers, communication links, RTOS is done upfront.

Model Based Design allows for Flexibility to Unexpected Changes.

The Design Process is often shown as linear. One develops a set of Requirements, Designs to meet the requirements, Implements the Design, Verifies the implementation, and the Produces the product.

But, in reality this is rarely the case! Unexpected changes to the requirements creep in. The scope may change. Unexpected issues may arise in verification. The Process is in reality more like a circle. Model Based Design allows the project to progress easily between the various stages of the design process.

Model Based Design Allows Software and Application Engineer to work together right from the beginning, rather than 'throwing things over the wall' as unexpected changes occur. This provides faster more rapid development, and also improves validation and verification capacity because changes can be quickly simulated or applied and tested on real hardware.

Summary

• Simpler, faster development cycle that is flexible to unanticipated changes

• Model re-use -- Sections of application logic can be stored in controlled libraries to share for re-use

• Hardware can be used generically for multitude of applications.

• Testing using real production control hardware - prototype to production with same tool

• Readable documentation of system design automatically created from models

What is MotoHawk's Role?

MotoHawk is a Toolbox to Simulink and is the glue that connects the Model Based Developer with real production hardware.

It is a toolbox to Simulink that uses the customization features to interact with the Woodward Operating System – ControlCore and the hardware devices it supports. This enables a Simulink user to construct models that will be executed on the target hardware that MotoHawk supports using a combination of the native Simulink blocks and the custom MotoHawk blocks.

MotoHawk also interacts with a variety of protocols that are transmitted over a variety of hardware platforms. CAN and Serial are two examples of the hardware. On the software side, we support CCP, XCP, J1939, UDS, among others (and the list is growing). These protocols also support the ability to calibrate MotoHawk applications using Woodward MotoTune, Toolkit, or industry standard tools such as INCA or ATI Vision.

MotoHawk provides an interface to Digital and Analog Input behaviors, as well as more complex behaviors such as Position Synchronized Pulses syncronized by the crank/cam encoder to engine position.

It also provides access to different types of memory such as NonVolatile, RAM and calibration.

Blocks for Fault Detection and Diagnostics (including a blockset for OBD fault management) are also provided to the application developer.

The User Works Directly in the Simulink Environment

The MotoHawk Blockset is a Toolbox in Simulink, so the user works directly in the Simulink Environment.

MotoHawk - One Step Build from Model Based Design to Production Hardware

Application Engineers work at the Application Layer, implementing for example Sensor Characterizations, Actuator Components, etc in the MotoHawk model. MotoHawk provides the Model Based Developer a blockset to abstract behavior on the hardware (ex. Operating System, Communication, Complex Device Drivers, Module Configuration) as well as build support to allow a one step build from the MotoHawk model to files that can be directly flashed to real production hardware.