Altia Design is graphics and user interface software used in conjunction with The MathWorks' Simulink

simulation product. Simulink simulations are very detailed, powerful and complex. Consequently, people unfamiliar with the Simulink’s methodology and its syntax can have difficulty understanding the simulation results. This is a problem since these unfamiliar observers are often developers, managers and customers who need to make critical decisions about a product’s development.

Altia solves this problem by helping modelers quickly create a user interface prototype for product

simulations that looks and behaves like the product’s real user interface. As a result, the people who need to make critical development and marketing decisions can easily operate and understand the simulation.

In addition to being an important communication tool, Altia can help the modeling expert during the design process. Altia’s animated graphical objects can monitor important internal system parameters in a visually compact, domain specific manner. This makes debugging and testing significantly more accurate and efficient.

In all cases, the animated graphics and user interfaces are created without programming.

With the Altia/Simulink connection, Simulink simulations can easily interface to Altia Design displays. Altia's connection to Simulink is through an S-Function. You must be familiar with Simulink, as well as Altia, to effectively use the connection.

With the Altia S-Function connection, a Simulink simulation can easily communicate with an Altia interface. The Altia S-Function is provided as a dynamically loadable executable that has the ability to connect to an Altia interface process using Altia's API (Application Programming Interface) library. The library uses a TCP/IP socket to communicate with the Altia interface process. The Simulink user is completely insulated from the details of the communication protocol by the API and the supplied S-Function code.

The Altia windows that display an interface are controlled by a separate process, Altia Runtime. This is a royalty free runtime engine that displays Altia user interface designs in a run-only mode. A user interface design resides in a file initially created using the Altia Design editor. Altia Runtime opens the file and reads its contents to display the graphics and control any animations associated with the various graphical objects.

The connection established by the API between Altia Runtime and the S-Function is TCP/IP socket based. For this to work properly on Windows 95, the system must have a network card installed that is properly configured for the TCP/IP protocol. Windows/NT systems provide socket support with or without a network card if the system is configured for the TCP/IP protocol.

To execute the supplied automobile demonstration, follow these simple steps:

cd c:\altiasim

copy altias51.dll altiasfn.dll

3. In Matlab, type:

sf_car

4. In the sf_car model window, open the Simulation menu and choose Start.

5. Two Altia windows will appear and the simulation will start running. In this simple demonstration, you can press your left mouse button on the gas pedal and drag the pedal down or up while continuing to press on the left mouse button. This inputs new throttle angle values to the model which in turn will cause changes to the position of the Speedometer and RPM needles in the Altia Automobile Demo window. In addition, the outputs in the strip charts displayed in the Altia Automobile System View window will also change along with the gear position indicator if appropriate. You can also drag the brake pedal down or up to input different brake torque values.

6. When the simulation runs to completion or is stopped, the Altia windows remain open. This allows you to view the final visual state of the system. If a new simulation is started again from the same Simulink session, the current Altia windows are closed and new windows are reopened. If you completely exit Matlab while the Altia windows are still open, simply close them using the close (x) button at the top of the Altia Automobile Demo window.

A second demonstration is provided that is a simpler version of the automobile demonstration. This model contains no Stateflow block. To execute this model, follow these simple steps:

The number of inputs must match the number of outputs for the S-Function. To match these numbers, set the number of inputs for the Mux to the same number of outputs for the Demux where the number should be the larger of the actual number of inputs or outputs required for the S-Function. If this leaves some Mux inputs unused, add a Ground block from the Connection library for each unused input and connect each Ground block to one of the unused Mux inputs. If, however, some Demux outputs are left unused, add a Terminator block from the Connection library for each unused output and connect each Terminator block to one of the unused Demux outputs. In the sf_car example, terminators are attached to the outputs of the Demux because some of these outputs are unused.

After creating your Altia interface design, you'll need to describe the Altia/Simulink mappings in a configuration file. See Configuration File Overview - A Must Read!, Configuration File Format and Configuration File Examples for more details.

The first step in creating a configuration file is determining which Altia animation, stimulus, or control names you should map to Simulink model inputs and outputs. An output from the Simulink model would typically map to an animation associated with one of your Altia interface objects. For example, if output element 1 (i.e., vector element 1 coming from the Mux attached to the S-Function) is vehicle speed, then it would make sense that it maps to a speedometer needle animation in Altia. To determine the needle's animation name and range, select the object in the Altia Design Editor and open the Animation Editor. The name, low state, and high state will appear in the Animation Editor's list area. If the range of states for the object is not an exact match to the range of values from the Simulink model, the S-Function supports a multiplier and offset for the Simulink value to easily adjust it for the range expected by Altia.

You can also map an output to the name used in an Altia control WHEN statement or the start or stop condition name in a timer stimulus definition. This is possible because the Altia S-Function generates an event to Altia for each change in the value of an output (assuming the output is mapped to the appropriate name in the configuration file). The event to Altia contains the name specified in the mapping and a value determined by the output’s value. When the event gets to Altia, it is broadcast to all animations with the same name, all control WHEN blocks that reference the name, and all timer stimulus definitions that use the name for starting or stopping. If the value for the event is in the proper range, it can change the state of one or more animations, trigger execution of one or more control WHEN blocks, and start or stop one or more timers. In summary, a single change at an output can affect the state of an Altia interface in a simple way or a very complex way using Altia's easy to learn capabilities.

The configuration file also defines mappings of events generated by Altia to inputs into the Simulink model. Altia generates events when a user's input (e.g., mouse click or key press) causes a stimulus definition to execute, or each time an active timer's interval expires, or whenever a control block executes a SET or MATH statement. As with the events sent to an Altia interface by an Altia S-Function, each event that Altia generates has a name and a value. If a configuration file contains a mapping of a Simulink model input to a name, the Altia S-Function selects to receive events from Altia for the same name. The S-Function is automatically notified by the Altia interface whenever a new event with a selected name is generated. Altia passes the value for the event to the S-Function and it in turn assigns the new value to the appropriate pin. The Altia S-Function can select to receive any number of event names from an Altia interface. The events arrive from Altia in the exact order they were originally generated by input stimulus, timer stimulus, or control statement execution. If the range of values generated by Altia don't match the range expected by the Simulink model, the S-Function supports a multiplier and offset for the Altia value to easily adjust it for the range expected by Simulink.

The configuration file starts with one or more initialization directives, one per line, and each is completely optional. Following the initialization directives are the input and output mappings, one mapping per line, in any order, and any number. Blank lines and lines that begin with the # character are ignored.

The following initialization directives are supported (Please note that white space within individual fields is only allowed if it is explicitly shown in the description):

The appearance of this option implies that an Altia interface is already running and was started with the

The standard Altia S-Function is linked with the socket version of the Altia API library so only [HOST]:SOCKET (PC or Unix) and DOMAIN_SOCKET_NAME (Unix only) are appropriate.

This maps the Simulink model input number # to values received from Altia events with the name ALTIA_EVENT_NAME. The input number # can only be a number from 1 to the maximum inputs defined for the Demux block on the output side of the S-Function. Please note that an input pin number here is really an S-Function output pin number. To put it better, an in#=... line is declaring an input into the model from an external point of view. From a view within the model, this input is coming into the S-Function from the external world and it exits on an S-Function output to the rest of the model. Hence, in#=... lines should only reference valid S-Function output numbers.

If an input is declared as a discrete type, each value received from Altia with the given name is returned to the Simulink model. If an input is declared as a continuous type, the most current value for the name is returned to the Simulink model. A discrete type is appropriate for a button because each state change is of interest. A continuous type is desirable for some types of knobs or sliders where only the latest state (i.e., most current position) is interesting. If no type is specified, then discrete is assumed.

If the optional x# argument is present, than each integer value from Altia is multiplied by the number # (using floating point arithmetic) before it is returned to the Simulink model. The number in x# can be an integer or a float. Usually, it is less than 1.0 to translate integer values from Altia into smaller floating point values. For example, x.01 would be used to translate Altia event integer values 0 to 100 to floating point values 0.00 to 1.0 for the Simulink model. This feature is provided because Altia only sends and receives integer values with its events. Only one x# is supported for each input description

The optional +# or -# argument declares an offset that should be added to or subtracted from the incoming Altia event value after the multiplier from the x# argument is applied if a x# is present. This order of execution is followed even if the +# or -# argument appears before the x# argument. The number in +# or -# can be an integer or a float and only one +# or one -# is supported for each input description.

If the optional min=# argument is present, values returned to the Simulink model are adjusted to be greater than or equal to the number specified in min=# after applying the optional multiplier and offset numbers. If a value is less than #, it is set equal to #. The number in min=# can be an integer or float and only one min=# argument is supported for each input description.

With the optional max=# argument present, values returned to the Simulink model are adjusted to be less than or equal to the number specified in max=# after applying the optional multiplier and offset numbers. If a value is greater than #, it is set equal to #. The number in max=# can be an integer or float and only one max=# argument is supported for each input description.

As a final note on input description lines, you can map a single input number to more than one Altia event name by having more than one input description line for the given input number. In addition, more than one input number can map to the same Altia event name if desired.

This maps Simulink model output number # values to Altia events with the name ALTIA_EVENT_NAME. The output number # can only be a number from 1 to the maximum outputs defined for the Mux block on the input side of the S-Function. Please note that an output pin number here is really an S-Function input pin number. To put it better, an out#=... line is declaring a model output as viewed from outside of the model. From a view within the model, this output is leaving the S-Function for the external world which means it was an input into the S-Function from the rest of the model. Hence, out#=... lines should only reference valid S-Function input numbers.

If the optional min=# argument is present, output values from the Simulink model are adjusted to be greater than or equal to the number specified in min=#. If a value is less than #, it is set equal to #. The number in min=# can be an integer or float and only one min=# argument is supported for each output description.

With the optional max=# argument present, output values from the Simulink model are adjusted to be less than or equal to the number specified in max=#. If a value is greater than #, it is set equal to #. The number in max=# can be an integer or float and only one max=# argument is supported for each output description.

After the Simulink model output value is optionally adjusted using the information from the min=# and max=# arguments, an offset is added to or subtracted from the result if a +# or -# argument is present. The offset is always applied after any minimum or maximum value adjustments are made even if the +# or -# argument appears before a min=# or max=# argument. The number in +# or -# can be an integer or a float and only one +# or one -# is supported for each output description.

If the optional x# argument is present, than a Simulink model output value is multiplied by the number from x# after any optional min/max and offset adjustments are made. The number in x# can be an integer or a float. It is usually greater than 1.0 to translate small floating point values from Simulink to larger values that can be cast to integers for Altia without losing too many digits of accuracy. For example, x100 would be used to translate output values in the range of 0.00 to 1.00 to integers from 0 to 100. This feature is necessary because Altia only receives integer event values.

If the %... conversion specification is not present, then the double floating point Simulink model output value is truncated to an integer after any min/max, offset, and multiplier adjustments are made. The resulting integer is used as the value for a new Altia event with the name ALTIA_EVENT_NAME.

As a final note, you can map a single output number to more than one Altia event name by having multiple out#=... lines where # is the same for each line. You can also map more than one output number to the same Altia event name by using the same event name in more than one out#=... line. The Altia S-Function generates events for Altia based on the ordering of the out#=... lines in the file starting with the first line and finishing with the last line.

# Altia/Simulink connection configuration file for automobile

# demonstration. This file can be used with the Altia sf_car.dsn

# design file and Simulink sf_car.mdl model file. It must be named

# altiasfn.txt to be recognized by the Altia/Simulink S-function.

# Request Altia S-Function to start Altia Runtime and load the Altia

# user interface design found in sf_car.dsn.

#

start sf_car.dsn

# Gas pedal value is input #1 (throttle %) into the model (which means

# it is output #1 from the S-Function). The gas pedal generates values

# from 0 to 100 which is a perfect match for percent of throttle.

#

in1=gas_pedal continuous

# The brake pedal value from Altia is input #2 into the model

# (which means it is output #2 from the S-Function). Simulink wants a

# torque value. Through experimentation, a multiplier of 40 for

# Altia brake pedal values from 0 to 100 seems to give the best braking

# response. This means the values going into Simulink are 0 to 4000.

#

in2=brake_pedal x40 continuous

# Output #1 from the model (input #1 for the S-Function) drives the

# speedometer needle animation in Altia. Values from the model go

# from 0 to ? while the needle animation handles values from 0 to 100.

# A maximum of 100 is established so that we set the needle at 100

# for values greater than 100. That is to say, the needle will peg

# at 100 if a value that is less than 100 is immediately followed by

# a value that is greater than 100 - Altia animations simply ignore

# values outside of their defined ranges so specifying a maximum is

# important if larger values can potentially arrive from the model.

#

out1=speed_needle max=100

# Output #2 from the model (input #1 for the S-Function) drives the RPM

# needle animation up to 6000.

#

out2=rpm_needle max=6000

# Output #1 from the model is also displayed in a strip chart. The

# strip chart takes values from 0 to 74 so the model output (which has

# a range from 0 to 200+) is bound to the range 0 to 200 and then

# multiplied by .37 to bring it into the range of 0 to 74. It is

# declared as a continuous output so that the strip chart's data moves

# continuously (i.e., once for each major time step). The strip chart

# only draws its data when a draw event is provided hence the second

# definition for sending events to the strip chart's draw animation -

# the values for the draw events don't matter.

#

out1=speed_strip_nexty continuous min=0 max=200 x.37

out1=speed_strip_draw continuous

# The RPMs are also plotted in a strip chart. For our system view,

# we want to handle a range beyond that shown in the RPM gauge so we'll

# allow 0 to 10000. We have to multiply that by .0074 to bring it into

# the range of the strip chart which handles values 0 to 74.

#

out2=rpm_strip_nexty continuous min=0 max=10000 x.0074

out2=rpm_strip_draw continuous

# And the throttle percent is also plotted in a strip chart. We will

# handle a range of values from 0 to 100 and multiply by .74 to bring

# them into the range of 0 to 74 for the strip chart.

#

out4=throttle_strip_nexty continuous min=0 max=100 x.74

out4=throttle_strip_draw continuous

# We also output the gear number to our gear_position animation and

# we bound the gear value to the range 1 to 4 which is really

# unnecessary since this is the gear's actual range in Simulink.

#

out3=gear_position min=1 max=4

Altia S-Function source, header, and library files for recompiling and relinking the S-Function executable are provided with the demonstration software. Rebuilding the S-Function should not be necessary unless you wish to try the S-Function for a newer release of Matlab/Simulink. If it is necessary, you can use the altiamex2.m Matlab script to initiate the recompile and relink. The script file may require some customization for your particular Matlab/Simulink software installation.

The Altia Runtime program and its support files:

The Altia S-Function executables:

The Altia user interface design files for the automobile and engine demonstrations:

The Altia S-Function configuration files for automobile demonstration:

The Altia S-Function configuration file for engine demonstration:

The Altia S-Function source files, libraries, and Matlab build script:

If you have additional questions, feel free to contact an Altia Technical Support Representative at 719-598-4299 in the United States. Or, contact your Altia software distributor if you are located outside of the U.S.