MotoHawk Components

1
MotoHawk Training
MotoHawk Components Scalable, Secure, Model-Based
Design of Embedded Systems
2
Scalable Designs

• MotoHawk has already been successful on
  module-level designs
• Large projects require many engineers to design
  in concert, piecing together components to create
  an application
• Components need to be managed, version-controlled,
  validated, and deployed independent of the
  component users
• Intellectual property within a component needs to
  be exposed by choice, not by necessity

3
Monolithic Model
All control logic in one model
Target is a module
4
Problems with Monolithic Model

• Simulink libraries have been the only mechanism
  to separate diagrams into multiple files
• Libraries are great for small, multiply-used
  operations, such as integrators, PID controllers,
  and sensor characterizations
• Unfortunately, libraries are simply a method to
  put more blocks into a model, and do not reduce
  the size of a model
• Very large models take a long time to browse,
  update, code-generate, and compile
• Versions of MATLAB and MotoHawk for the developer
  of a library must match the user of a library
• Using a library does not hide or protect the
  implementation of a block at all

5
Problems with Monolithic Model (contd)

• Importing a library block from someone else
  usually involves importing the entire environment
  from its designer, such as scripts on the MATLAB
  path, or other library references
• Getting all of these dependencies to match up at
  the top-level of a large design takes serious
  effort, and coordination. Few mechanisms exist
  to enforce encapsulation of the environment
  within a model
• Library blocks are not fixed, meaning that when
  they are used, mask parameters, data types and
  sizes of I/O ports, and the existence of other
  data in the system can determine how the block
  will actually behave
• This makes it more difficult to validate a
  library block, because its usage in part
  determines its interface, rather than having its
  interface fixed at design time. When problems
  occur, it becomes difficult to determine whether
  the designer or the user is not meeting the
  interface contract

6
Introducing the Component Target
Instead of selecting a hardware module, the
target can now be Component (PPC)
Components have an associated image file (.jpg),
which is provided here
Components may be encrypted, which is selected
here
All execution must still be placed into MotoHawk
triggers, but an INHERITED trigger is available
in components
7
Introducing the Component Target
New MotoHawk input and output port blocks are
available in Component targets
All ports have a name, help, units, data type,
size, and may optionally attach a VarDec, to be
visible from MotoTune
Input ports may have an optional default value,
which is used in simulation of the component, or
if the user does not connect the port. This
allows optional ports, which are not available
with Simulink libraries.
8
Introducing the Component Target
Instead of producing an .srz and a .dll, building
a component target with CTRL-B generates an .mhc
file, for MotoHawk Component
9
MotoHawk Component File (.mhc)

• During a component build, code is generated and
  compiled and several files are produced.
• These are all zipped and optionally encrypted
  into the resulting .mhc file
• For simulation and design
• A .dll S-Function, for simulation and interaction
  with Simulink
• A .p descriptor file, containing I/O port
  information, VarDecs, Faults, and CAN messaging,
  all in MATLAB accessible format.
• For the embedded target
• Object code for the component, in an archive .a
  file
• Interface .h header files
• A .tlc code-generation proxy file

10
Using a Component
A new MotoHawk Component Instance block is
available
To use a component, simply provide the filename
of the .mhc file, and provide the appropriate
passphrases, if required.
The block will update to show all I/O ports
defined in the component.
11
MotoHawk Component Summary

• Components are pre-generated and pre-compiled.
• Build times for module applications are
  significantly reduced.
• Models will contain fewer blocks, so Simulink
  will perform much faster and require less RAM on
  the PC.
• The .mhc file becomes the unit of deployment and
  testing. No other files or setup are necessary
  to use a component.
• Encryption is provided for the entire component,
  and also for embedded builds. This allows
  intellectual property protection, as well as
  component advertising by encrypting just the
  build.
• Even without encryption, intellectual property
  is protected, because the contents of the .mhc
  file are pre-compiled.

12
 
MotoTron Control SolutionsProduction Controls in
a Flash