MotoHawk:Components Overview

Introduction

Three different issues that are important to large scale development are scalability, composability, and intellectual property protection. This section will summarize each of the different issues and how Simulink attempted to address each issue.

Scalability

A model is a hierarchical graphical tool composed of subsystems and blocks. Graphically, the structure is similar to a tree with branches and leaves where the branches are the subsystems and the leaves are the blocks. Figure 1 is an example of this structure.

Model editing tools such as Simulink must perform operations on each of the blocks present in the model when a user wants to verify port data types and attempting to generate code from his model. As models grow, more blocks are present in the model so these operations take longer and longer to complete. Production programs will run into this scalability issue with model-based software.

Simulink attempted to solve this problem using “model reference”. Similar to some other Simulink solutions, the Simulink solution was not sufficient for our needs. Model reference is limited in its ability to define a consistent interface because embedded systems need information in addition to signals and triggers. CAN, faults, and calibration/probes (aka Vardecs) are also a portion of the interface and model reference just isn’t sufficient for a complete component-level interface definition.

Composability

Composability is the system design principle that deals with the inter-relationship of separate system pieces. A highly composable system allows for the separate pieces to be moved around and assembled in different combinations while a non-composable system does not allow the separate pieces to move around. In particular, a composable system can be divided into separate pieces and has well defined interfaces. Thus, the development of a composable system can also be divided among multiple software developers.

A highly composable system can also contain highly reusable components. If components are easily movable, then they can be movable across different applications. Of course, this depends on the individual implementation and requirements placed on the original component, but the possibility of reuse is there.

Simulink uses libraries to create composable systems, however there is no data type enforcement since data types could be inherited across the interface. In addition, libraries offer no benefit as far as update/build times because the entire library and all sub libraries are loaded into memory at update time.

Intellectual Property Protection

In corporate software development, protection of intellectual property is important.

Description

Components satisfy all of three of these concerns, plus it provides a few more features.

The scalability of a system constructed with MotoHawk components is extremely high because you can effectively 'collapse' a branch of a given model into a single block. Figure 2 illustrates this concept. This single block is precompiled so it does not need to be rebuilt when the top level model is built. Building components in this way saves build/update time significantly.

The composability of a system constructed with MotoHawk components can be extremely high. This depends on the individual implementation of a given component, but the tools are there for a well defined, consistent interface, plus the ability to push other system-related interfaces such as CAN, faults, and vardecs into the top level. To further enhance composability, components can be placed inside other components and provide the same benefits to subcomponents.

The intellectual property is protected by precompiling the component into a binary file. The original model is not required for distribution, only the interface files and the precompiled binary file. For even stronger protection, encryption can be enabled on the generated file that requires a special pass phrase for a consumer of the component to use it.

Using the motohawk_project function and the 'Component' target type allows for multiple users to edit multiple components which leads to a configuration manage-able self-contained distributed design. The faster builds and updates are an added bonus to speed up development.

While a model is also the software definition, it is also the documentation of the software as well. An image file can be associated with a component which graphically displays the purpose of the component. This image is also self-contained in the component and is available for distribution.

Component Instance

Interface

• Outputs
  • Varies (see below)

• Inputs
  • Varies (see below)

• Internal State
  • Varies (see below)

Component Input Port

Interface

• Outputs
  • Signal

• Inputs
  • (none)

• Internal State
  • (none)

Component Output Port

Interface

• Outputs
  • Signal

• Inputs
  • Signal

• Internal State
  • (none)

Limitations

While Components have multiple advantages, including faster build times and protection of IP, there are some limitations and the model architecture must be considered.

1. There can’t be multiple instances of the same component in the model (each Component instance must have it’s own mhc file – can’t build once and rename to include multiple places).
2. I/O blocks can’t be used inside a component
3. You can’t pass busses through interface – input/output ports cannot be a bus, ports must be single signals
4. Stuctures – single data store w/ multiple fields, etc. Structures are not supported
5. Non Standard Types cannot be passed through boundry (index_T, fault_T..)
6. Components cannot be simulated
7. In order to guarantee compatible code, the MotoHawk, Matlab, and Compiler are required to be the same in each component and the master application that contains the components. If multiple persons in a team are using components, everything must be built with the same toolchain, and components must be rebuilt if the toolchain for the main application model changes.

How do I Implement a Component in a Model

Step 1: Create a New Component Model. This is the application model that is contained in your Component.

1. Open a new model (or a model that you wish to place into a Component) and Select an appropriate Component Target in the Target Definition Block, rather than the hardware target

2. Associate an Image file, if desired.

3. Select encrypting, if desired

4. Set the MotoHawk Trigger to Inherited. All execution must still be placed into a MotoHawk trigger, but the Trigger for the component must be INHERITED.

5. Construct the Component model inside the trigger. (see limitations below). Note that there are New MotoHawk Component Input and Output blocks to bring single singles into and out of the component. Busses cannot not flow into a component.

6. Build the componenet model (Cntl-B). Instead of creating an .srz and .dll, the MotoHawk Component build will create an .mhc file (MotoHawk Component).

Step 2: Place the Component into your Parent Model

1. To bring the Component into your parent model, place a Component Instance Block in your parent model.

2. Provide the filename of the .mhc file, and appropriate passphrases if required.

Frequently Asked Questions

• Can I use data stores in components?

At this time, data stores can be used within components.

There are a few exceptions though. Data stores defined in one component cannot be read or written in another component or the main model.

The second limitation is specific to structures. Structures cannot be used in a component.

• Can I pass references and other non-standard Simulink data types into components?

No, these cannot be passed into the component.

• Can I simulate components?

At this time, components cannot be simulated.