1 / 12

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

Achieve scalable, secure, and model-based embedded system design with MotoHawk Component Target. Simplify large projects, manage components efficiently, and protect intellectual property. Enhance development speed and system performance.

miltonm
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 (cont’d) • 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

More Related