MotoHawk ™ Components Scalable, Secure, Model-Based Design of Embedded Systems

1. MotoHawk™ ComponentsScalable, Secure, Model-Based Design of Embedded Systems

2. 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 Scalable Designs

3. Monolithic Model All control logic in one model Target is a module

4. 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 Problems with Monolithic Model

5. 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 Problems with Monolithic Model (cont’d)

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. 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 MotoHawk Component File (.mhc)

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.