EHANDBOOK Container-Build Usage in General

For running EHB-CB in multi instance mode, the following have to be specified:

Please refer to the sample below with parameters that need to be provided for running EHB-CB in multi instance mode:

The maximum RAM memory that EHANDBOOK Container-Build is allowed to use is specified within the -Xmx parameter in the eHandbookCB.ini file.

In this example, the memory limit is set to 8 GB:

In order to render the graphics of Simulink blocks appropriately, a connection to MATLAB is required.

By default a connection from Container-Build to MATLAB is enabled and established when converting Simulink models. In order to prevent a connection to MATLAB, the command line option -nomatlab can be used.

With an active MATLAB connection, images of Simulink block masks or block decorations are exported and are available as an overlay on the respective block when loaded in EHANDBOOK-NAVIGATOR.

The command line parameter -matlabpath uses MATLAB during the build process for Simulink mask generation. This happens via a MATLAB API connection. To ensure, that EHB-CB is not blocked, there is a configurable timeout, if the connection hangs for any reason. For this, the parameter -DmatlabTimeoutThreshold=value can be specified in the eHandbookCB.ini file. The value should be an integer and unit corresponds to minute.

In the following example, the timeout is set to 10 minutes:

Without any given timeout specification in the ini-file, the default is set to 5 minutes.

Performance of Simulink model conversion has been improved by introducing caching mechanism for referenced Simulink models. This is achieved by caching the libraries that are already converted. For this, the parameter -DsimulinkLibraryCacheSize=value can be specified in the eHandbookCB.ini file. The value should be an integer and unit corresponds to number of libraries.

In this example, the cached number of library modules is set to 50:

Without any given specification in the eHandbookCB.ini file, the default is set to cache 100 library models.

Performance of Simulink mask generation has been improved by introducing a caching mechanism for Simulink mask types. Types with same mask data should be considered for caching. For this, the types of masks can be configured with -DtypesForMaskGenerationCaching=type1,type2,…​ in the eHandbookCB.ini file.

Example: If a block mask data has parameter "Type" with value TL_out or TL_in which are used in many blocks, such types can be cached as

Not all the mask data is currently interpreted by EHANDBOOK Container-Build. To overcome this, there is a new option which exports the Simulink Mask as an image and shows them in EHANDBOOK-NAVIGATOR. The option is enabled by default, to switch to mask interpretation add the following entry in the eHandbookCB.ini file:

By default, the option is disabled and set to false. The Simulink mask decorations as image is currently supported only for blocks which are rectangular in shape. This option requires a MATLAB connection for the build process. The earlier option -DenableSimulinkMaskDecorationsAsImage is deprecated.

With simulink mask decoration as image approach, it is possible to generate mask images for selected rectangular blocks with mask applied on them. A list of rectangular blocks with mask are identified and listed in eHandbookCB.ini file:

By default, this option specifies a set of rectangular blocks with mask applied on them. This list can be further extended with additional rectangular blocks with masks on them.

Currently EHANDBOOK has some limitations on Simulink Annotations which contain rich text formatting. To overcome this, there is a new option which extracts the textual content from rich text annotations and shows them as text in EHANDBOOK-NAVIGATOR. The option can be enabled with the following option:

Typically, you will have only one Simulink file per sub directory (Directory Based EHB-CB) or per functional component (ASAM based EHB-CB). EHB-CB also supports multiple Simulink files, where one main model file is referencing other model files. To make this happen, all files must be zipped, where the zipped file name must match to the main model name (default behavior). There should not be any hierarchy within the zip folder.

If this is not the case, you can specify one or more suffixes, which will be ignored from the zip name to still allow name matching with the main model name:

This option accepts multiple suffixes with comma separated values.

When there are multiple SIMULINK model files within a zip file input, this option allows name matching with the desired model file within the zip by ignoring the provided suffix from the model file names and matching the name against the zip file name.

Note: Both simulinkZipSuffix & simulinkModelFileSuffix arguments can be used together to enforce name matching according to user’s preference.

Mask documentation (referred as Base documentation) can be associated with a library model or a referenced model. Further uses are allowed to add an additional documentation (Referred as Custom Documentation) to the instance of library model or referenced model used in their model. In EHANDBOOK, mask documentation are indicated with tooltip as follows:

MATLAB provides capabilities to create protected models. In EHANDBOOK, such protected models are made non-expandable in order to maintain the confidentiality of the content.

PDF generation using command line argument -pdf is a multithreaded operation. This operation uses all the existing logical CPU cores available on the system for conversion. This might impact the overall system performance.

In order to make PDF generation more optimal, the maximum number of used threads that get spawned during PDF generation can be configured.

If the number of threads configured is greater than available logical CPU cores, then all the available logical cores are utilized.

This option accepts integer value.

ASCET project component serves as an entry point for processing an ASCET model in EHANDBOOK. However a user might not define an ASCET project in an ASCET model. In such an instance, EHANDBOOK would consider components with names matching with the ASCET model name for processing. Component types which are considered for name matching and processing further are as follows:

This behavior can be configured with the following argument.

ASCET project specification serves as an reference for processing components in an ASCET model in EHANDBOOK. However we could generate kaom and svg for the white-listed components specified in a JSON which are not part of specification. In such an instance, EHANDBOOK would consider such components in the ASCET model name for processing.

This behavior can be configured with the following argument.

Per default, the EHANDBOOK Container-Build tool starts with the GUI for Directory-based input data (i.e., if no command line parameters are given). To start the tool with the GUI for ASAM-based input data, the following entry has to be added in the eHandbookCB.ini file:

Configure path of MiKTeX location used for TeX formula conversion. By default TB_MIKTEX_HOME environment variable is used, otherwise the location provided with this option. Refer to MiKTeX.

Configure path of PDF FLY location used for EPS image to SVG image conversion. By default TB_PDFFLY_HOME environment variable is used, otherwise the location provided with this option. Refer to PDF FLY.