Altia® Design

The Altia/Statemate simulator connection is controlled by a program named altia_stm that has been written using Altia's C/C++ application programming interface (API) and a C API provided by Telelogic for the Statemate simulator. The altia_stm program connects elements that appear in a Statemate model to animation, stimulus, or control names in an Altia panel. For most elements, changes made in the Statemate simulation are sent to the Altia panel and changes made in the Altia panel are sent to the Statemate simulation. There is no distinction made between input elements and output elements. That is to say, any element can be an output in Altia and an input in Statemate or vice-a-versa.

The elements monitored by the altia_stm program are defined in a bindings file. The file contains a list of element names and a type for each element. The type is used to determine if an element requires buffering (as is the case for strings) or if a special form of conversion should be performed by the connection program when an element event is handled. Connections can only be made for Altia animation, stimulus, and control names that have the same names as Statemate elements. Altia names are case sensitive so names in the bindings file must match exactly with names used in the Altia panel.

If you are receiving a full Unix Altia Design product distribution and you requested the Statemate connection software, it will come on the standard product distribution media. The label on the media will indicate that the Statemate connection software has been included. In these situations, simply install the software as outlined in the standard installation instructions for the particular media. After installation, the Altia/Statemate MAGNUM connection files are located in altia/altiastmm. Change directory to altia/altiastmm before attempting to execute the HVAC demonstration described later.

If the Unix Statemate connection software has been provided on media separate from the Altia Design product (this would be the case for a SUN floppy distribution), you may install it relative to any existing directory following the installation instructions on the media label. The installation will create a sub-directory named altiastmm relative to the current working directory. Change directory to altiastmm before attempting to execute the HVAC demonstration described later.

PC users with Statemate MAGNUM for Windows/NT can receive the Statemate connection software on a PC floppy. The floppy contains a self-extracting zip archive file, altiastm.exe. To unpack the archive, execute:

A dialog will appear that allows you to select a destination directory for the extracted files. When the extraction is complete, the destination directory that you chose will have a new sub-directory named altiastmm that contains the Altia/Statemate MAGNUM connection software.

altia_stm - Altia/Statemate binding program

It is significant to note that the Altia Design editor can connect to the Statemate tool as easily as Altia Runtime. This allows you to edit your Altia design, test it with the Statemate simulator, and then re-edit the design without ever having to quit or restart the Altia tool. This run/edit capability also applies to the Statemate tool. One can start a simulation, stop it, edit the state charts, and restart the simulator without ever quitting and restarting the Statemate tool. In the Altia Design editor tool, you edit a design by putting the tool into edit mode via the Edit toggle button under the color palette. When you wish to have object stimulus definitions interpret mouse and keyboard events, the tool is put into run mode via the Run toggle button. At all times, whether in edit or run mode, new events coming from the Statemate simulator will automatically update animations in the Altia design if the events are recognized by the altia_stm program.

If you are using a remote X-terminal or another machine's X-server, the machine that the Altia tool is running on can be different from the machine where the Altia tool interface is displayed. In this configuration, it would be most common to start the altia_stm program on the system that is also running the Altia tool. However, it is also possible to run altia_stm on an entirely different system. In this case, you should start the Altia interface program (e.g., altia/bin/altia) with an option similar to -port :5100 where 5100 is an unused TCP-IP socket number. Then, start altia_stm with the option -port host:5100 where host is the name of the system executing the Altia interface program.

Also, when using a remote X-terminal or X-server, the DISPLAY environment variable must be set for the altia_stm program so that it refers to the same X display that is being used by the Statemate tool. This is because altia_stm uses the X display socket to facilitate communications with the Statemate tool.

In summary, the Altia interface program, altia_stm, and the Statemate tool may all be running on separate systems as long as Altia and altia_stm are started with the same "-port host:socket#" arguments and the DISPLAY environment variable is set the same for altia_stm and Statemate.

A working demonstration has been provided along with the altia_stm program. A supplied databank directory contains an Altia/Statemate integration example using an Altia HVAC design.

Starting Altia for the HVAC demonstration should NOT be necessary because the example bindings.txt file for the demo contains a start directive for the hvac.dsn design. The start directive instructs the altia_stm program to start Altia Runtime automatically and open hvac.dsn into it. The Altia Runtime program (altiart.out on Unix or altiart.exe on the PC) is included as part of the connection software and is automatically installed in the altiastmm directory. This guarantees that altia_stm will always successfully start Altia Runtime as long as the working directory is the altiastmm directory.

If you have the full Altia product, you can manually start the Altia Design editor instead of having altia_stm automatically start Altia Runtime. To do this, you must first edit the bindings.txt file in the altiastmm directory and comment out the start directive line by placing a pound sign character (#) or double dashes (--) at the beginning of the line. You can use your favorite simple text editor to modify bindings.txt and save the change. Now you are ready to start the Altia Design editor. On Unix and the PC, you can easily do this from a command prompt window. For example, on Unix, change to the altiastmm directory and start the editor with the following commands:

This example assumes that /usr/altia/altiastmm contains the Altia/Statemate connection software and /usr/altia is the Altia product software directory. If your software installation directories are different, change the path names accordingly. On the PC, you would execute similar commands in a command prompt window:

where c:\altiastmm contains the Altia/Statemate connection software and c:\usr\altia is the Altia product software directory. If your software installation directories are different, change the path names accordingly. On the PC, you can alternatively open the HVAC design file into the editor by choosing the Altia Editor icon from the Altia Design program group and selecting Open… from the editor’s File menu. Because hvac.dsn ends in a .dsn extension, you also have the option of double-clicking on hvac.dsn from a file browser window to open it directly into the editor.

If you choose to start the Altia Design editor, you must press on the toggle button labeled Run in the editor in order to switch to run mode. You must be in run mode for your mouse and keyboard events to be interpreted by object stimulus (and hence passed on to the Statemate simulation via altia_stm). If you are not in run mode, your mouse and keyboard events will only allow you to select objects in the design and edit the objects (for example, move, stretch, or rotate them).

The altia_stm program is ready to run directly from a command prompt window whose present working directory is the altiastmm Altia/Statemate connection software directory. Alternatively, you can start altia_stm from a file browser window that is currently viewing the altiastmm directory. For the HVAC demonstration, altia_stm requires no optional arguments which makes it very simple to start.

As the altia_stm program initializes, it always displays several messages in a command prompt window. For PC users, the first message looks similar to:

These are perfectly normal. The altia_stm program is attempting to confirm the existence of the names listed in the bindings file. It is asking the Altia process if it recognizes these names and it does not. This is normal for names that are only used in stimulus definitions and are not defined as animations.

The altia_stm program is the link between an Altia user interface and a Statemate simulation. It passes events between the two processes. To limit traffic, it only passes events that are declared in the bindings file. If the file is incomplete or there are typographical errors, the connection will not perform correctly.

Once the hvac.dsn design is opened into the Altia window and the bindings program is initialized, you can click on the button labeled Climate on to activate the climate control unit. At this point, the TEMP, FAN, and AIR FLOW rocker switches are fully functional as are the RECIRC and AC toggle buttons. The Instrumentation button opens an additional window that displays the status of various Statemate variables that may be of interest to the system developer. The Cabin View button opens a window that displays air flow levels from the cabin vents.

You can stop altia_stm by typing a <Cntrl>-c key sequence to the program from the command prompt window. If you exit the main Altia interface window (for an Altia Runtime session, a <Cntrl>-c key sequence within the Altia window will terminate Altia Runtime), this will also terminate the connection program. In addition, the connection program and Altia Runtime will also quit if you terminate the Statemate simulation.

If you terminate the Altia interface window (which terminates the connection program) for the HVAC demo and you wish to start the connection again, you should first stop the simulation in Statemate, exit the Simulation Execution window as well as the Simulation: AC_PROF_1 window and start the simulation again from the Simulation icon in the main Statemate MAGNUM window. When the new simulation is in AutoRun mode, you can restart the connection program. For the HVAC demonstration, the Statemate HVAC model must perform its initialization sequence for each new connection session or the Altia interface will not respond correctly. Not every Statemate model has the same initialization requirements so models that you create may allow the starting and restarting of the connection program and Altia interface during the same Statemate simulation session.

1. You will probably want to start by developing a Statemate model or maybe you have a model already developed. As you develop a model or prepare an existing model for use with Altia, please be aware that only BASIC elements in Statemate can be connected to Altia .

2. Use the Altia Design editor to create a user interface design. If you have not used Altia before, please consult the on-line tutorials and User's Guide portion of the User's Manual for assistance. To connect Altia animation, stimulus, and/or control names to Statemate elements, the names used in Altia must exactly match the element names in Statemate. It is acceptable to use the extended naming conventions of Statemate (e.g. CHART:ELEMENT) in the bindings file. In such cases, the full name must also be used in Altia. For simplicity, you may want to use only upper-case characters in Altia for names that will be connected to Statemate elements. This is not required, but may make the writing of the bindings file easier because the character case for names appearing in the bindings file must match the character case for the names in Altia. For example, if an animation in Altia is named meter, a reference to it in the bindings file must also read as meter and not Meter or METER.

3. As you are developing the Altia user interface design, you may wish to simultaneously construct the bindings file. You can use the bindings.txt file from the HVAC demonstration as a template. The format of the bindings file is described later under The Statemate Simulator Connection Bindings File Format.

4. After you have an Altia user interface design file and bindings.txt file, you will need a copy of the simulator connection program. You can copy the program from the altiastmm directory created during the Altia/Statemate connection software installation. On Unix, copy the files altia_stm and altiastm to your local working directory. On the PC, copy altia_stm.bat and altiastm.exe.

5. You should now be ready to run a simulation. Open your Statemate model and start a simulation session. Put the simulator into auto-run mode by choosing Go>AutoRun in the Simulation Execution window.

6. If you enable the start directive in your bindings.txt file, the initialization portion of the connection program will attempt to start Altia Runtime and request it to open the design file designated in the start directive. For this to work properly, the Altia Runtime executable (altiart.out on Unix or altiart.exe on the PC) must be accessible to the connection program. If the full Altia product software is installed in /usr/altia on Unix or \usr\altia on the PC, Altia Runtime is automatically accessible because it resides in /usr/altia/bin or \usr\altia\bin. If this is not the case, it may be easiest to simply copy the Altia Runtime executable to the local directory. You can copy the program from the Altia product software bin directory or from the Altia/Statemate connection software altiastmm directory. On Unix systems, you must also copy fonts.ali from the same directory if it is present. On PC systems, you must copy fonts.ali and colors.ali from the same directory. Failure to copy these files, if they are present, along with the Altia Runtime executable will result in unusual looking fonts and possibly unusual colors when a design opens into the Altia Runtime window(s). Another alternative to copying the runtime files to the local directory is to set the ALTIAHOME environment variable if you have a full Altia product software installation. For example if the Altia software bin directory is /opt/altia/bin, set ALTIAHOME to /opt/altia. If you are unsure how to set environment variables for your particular system, please consult your local Systems Administrator.

7. If you choose to disable the start directive in your bindings.txt file, you must manually start Altia Runtime or the Altia Design editor before executing the connection program. If Altia Runtime is in the local directory, you can do this on Unix from a command prompt window with the command:

8. The altia_stm connection program should be ready to run. It should be located in the same directory as your bindings.txt if you copied it from the altiastmm directory as suggested in an earlier step. To run it from a command prompt window, change to the directory and execute altia_stm. You can also run it from a file browser window by viewing the directory and double-clicking on altia_stm (altia_stm.bat on the PC).

9. After the Statemate simulator, Altia tool, and altia_stm are started and initialized, you are ready to exercise the simulation. If you started the Altia tool as an editor session, you must put it in run mode (from the Run toggle under the color palette). If you started Altia Runtime instead of the editor or altia_stm started Altia Runtime for you (via the start directive in the bindings file), it is always in run mode.

10. You can stop altia_stm by typing a <Cntrl>-c key sequence to the program from the command prompt window. If you exit the main Altia interface window (for an Altia Runtime session, a <Cntrl>-c key sequence within the Altia window will terminate Altia Runtime), this will also terminate the connection program. In addition, the connection program and Altia Runtime will also quit if you terminate the Statemate simulation.

Source files for recompiling and relinking the Statemate simulator connection program are provided in the altiastmm directory. The supplied Makefile file will probably need to be customized for your environment before executing make. Under normal circumstances, it should not be necessary to recompile or relink the program.

Before an Altia panel and Statemate model simulation can be connected, a textual bindings file must be created. The altia_stm program assumes the bindings file is named bindings.txt and it resides in the current working directory. As an option, a bindings file of a different name can be specified as an argument to altia_stm. The bindings file contains a list of elements that should be connected between Altia and Statemate. Each element is listed on a separate line followed by a single character that indicates the type of the element in the Statemate model. In two cases (for types r and R), an additional value follows the element type. The Altia user interface design and Statemate model can each contain many other different element names. These elements will go about their business as usual. Only the elements listed in the bindings file will be monitored and updated by the altia_stm program.

It is assumed that an Altia name (i.e., an animation name, stimulus enable condition name, stimulus execute name, or a name used in a control block WHEN, SET, MATH, or EXPR statement) corresponds to an element name in Statemate. The current version of the altia_stm connection program will not allow you to bind elements with different names. And, only BASIC elements in Statemate can be bound in this way.

Before any specific element bindings, the bindings file can contain a start directive line. The word start is followed by an Altia user interface design file name. This is a request to the connection program to start Altia Runtime and open the specified design file. The example bindings.txt file for the HVAC demonstration contains just such a directive for the design file hvac.dsn. Starting Altia Runtime requires the existence of the runtime program (altiart.out on Unix or altiart.exe on the PC) in the current work directory or in the standard Altia bin directory /usr/altia/bin (\usr\altia\bin on the PC). If you execute altia_stm from the altiastmm directory that was created during the Altia/Statemate connection software installation, an Altia Runtime program is always present because it is one of the installed files. If you have the complete Altia Design product including the editor, you also have the option of commenting out the start directive in bindings.txt, starting the editor, opening the hvac.dsn file into the editor, and then executing altia_stm from a command prompt window or file browser window. The program will attempt to connect to an existing Altia session which will work because the editor is running. Putting the editor into Run mode (using the Run toggle button below the color palette) will enable interaction with the Statemate simulation.

In addition to the start directive, the bindings file can also contain a debug directive line before any specific element bindings. The word debug is followed by a number 1, 2, or 3 where 1 is the least verbose debug level and 3 is V-E-R-Y verbose. Debug messages are printed to the altia_stm program's command prompt window. On the PC, altia_stm creates a command prompt window of its own if it is not started from one. On Unix, you should start altia_stm from a shell prompt window if you wish to view the debug messages. A debug directive in the bindings file overrides a debug level argument on the altia_stm command line.

b - bit data-item in Statemate, integer in Altia

c - condition in Statemate, integer in Altia

e - event in Statemate, integer value 1 in Altia (only transmitted from Altia to Statemate)

i - integer data-item in Statemate and an integer in Altia

u - integer data-item in Statemate, unbuffered integer in Altia

r - float in Statemate, integer in Altia multiplied by a user-defined constant

R - float in Statemate, float in Altia multiplied by a user-defined constant

s - string in Statemate and a string in Altia

t - integer in Statemate, string representation of an integer in Altia

f - float in Statemate, string representation of a float in Altia

A - Activity in Statemate, integer in Altia (only transmitted from Statemate to Altia)

S - State in Statemate, integer in Altia (only transmitted from Statemate to Altia)

A u type is unbuffered from Altia to Statemate. That is to say, if the connection program detects several values in sequence from Altia for a u type name, only the newest value is sent to Statemate. A u type is most often appropriate for components like sliders and knobs in Altia where the Statemate model is only interested in the current position of the device. In contrast, each and every value from Altia for an i type name is sent to Statemate.

An e type is only transmitted from Altia to Statemate. In general, any name and value pair coming from Altia can be thought of as an event and can therefore be bound to Statemate as an e type element. A Statemate event, however, has no value. As a solution to this discrepancy, a new name and value from Altia is only passed on to Statemate as an event if the value is not equal to zero. This approach works well for the various momentary buttons available from Altia's standard component libraries. Typically, these buttons generate a name (e.g., push) with a value of 1 when they are pressed and generate the same name with a value of 0 when released. If one of these buttons is bound to Statemate as an event, a push of the button will generate an event to Statemate and the release of the button will be ignored.

The r type allows for the translation of Statemate floating point (real) types to integers for the Altia panel and vice-a-versa. It does this by multiplying a Statemate floating point value by a constant provided by the bindings file. The result is then truncated to an integer and passed on to Altia. When an integer comes from Altia, it is divided by the constant using floating point arithmetic and the result is sent as floating point data to Statemate. An r type specification in the bindings file would look similar to:

realvalue r 1000

In this case, a realvalue event coming from Statemate would be multiplied by 1000 and truncated to an integer before being passed on to Altia. If a realvalue event is generated by Altia, it would be divided by 1000 and passed to Statemate as a floating point (real) data item. The r type is necessary because the Altia tool only accepts and generates character or integer events in most cases (see More on the R type for some exceptions). If a multiplier is not specified, 1 is assumed.

The R type is similar to the r type except that the value is assumed to be a floating point (real) in Statemate and a float in Altia. As of the writing of this document, only two special Altia objects - the Auto Strip object and the List object - have specific animations that can handle floating point values. If you are using one or both of these objects, please consult the documentation supplied for the object(s) to further understand the floating point capabilities. If you are binding one of the special floating point animations to a Statemate element, you must declare the type as R so that the connection program knows to treat values from Altia as floats and send values to Altia as floats instead of integers. Like the r type, the R type supports a multiplier although it is probably not necessary for most situations since the floating point nature of the value is preserved between Altia and Statemate.

An s type originating from an Altia Design 2.0 or newer text entry area would typically be bound to the text i/o object's text function and not to the character function. This is because Statemate deals with changes to strings in an atomic manner and events from the text function are more suitable for this type of architecture. For Altia Design 1.40 or earlier releases, an s type originating from an Altia text entry area would be bound to the getchar function, but typically never the putchar function.

An s type originating from Statemate should be bound to an Altia Design 2.0 or newer text i/o object's text function. For an Altia Design 1.40 or earlier release input/output text object, it should be bound only to the putchar function and never to the getchar function. This is because the getchar function generates characters, but it cannot receive them.

A t type originating from an Altia Design 2.0 or newer text entry area would typically be bound to the object's text function. But, instead of just sending the string on to Statemate, the altia_stm program will first convert the string to an integer and send the resulting value as an integer type. The t type is typically used to input numbers into Statemate from Altia text entry areas. For an Altia Design 1.40 or earlier release text entry area, the t type would typically be bound to the object's getchar function.

A t type originating from Statemate should be bound to an Altia Design 2.0 or newer text i/o object's text function. For an Altia Design 1.40 or earlier release input/output text object, it should be bound only to the putchar function and never to the getchar function. This is because the getchar function generates characters, but it cannot receive them.

The f type is similar to the t type except that it translates Altia text input from a text function (or a getchar function for Altia Design 1.40 or earlier release text entry areas) to a Statemate floating point (real) type. Any f type originating from Statemate should be bound to an Altia Design 2.0 or newer text i/o object's text function. For an Altia Design 1.40 or earlier release input/output text object, it should be bound only to the putchar function as with the s and t types.

A bindings file may also contain comments. Comment lines start with a double-dash (--) or pound sign character (#).

As an example, here are some lines from the bindings.txt bindings file for the HVAC demonstration:

To support the transition, Altia provides a special user_activities.c file that can be compiled and linked with the code generated by Statemate. When Statemate generates code, it always generates a simple user_activities.c file. Normally, a developer customizes this file if they wish to interface the generated code to external data and/or events. For example, reading or writing to files or I/O devices. Altia’s user_activities.c file interfaces generated code to Altia and it requires no customizations by the developer. Instead, a simple C header file, bindings.h, is created by the developer (from an easy to follow template) to provide bindings information for Altia’s user_activities.c just like the bindings.txt file provides bindings information for the altia_stm simulator connection program.

To demonstrate the generated code connection, the Altia/Statemate connection software includes the generated code for the HVAC model in the altiastmm sub-directory named code_link. This code was generated from the HVAC model using a Compilation Profile named HVAC which is included in the Statemate HVAC model databank. Altia’s special user_activities.c file is pre-installed in the code_link directory along with a bindings.h file that is appropriate for the HVAC model generated code.

In a command prompt window, you should change directory to the code_link directory located under the altiastmm Altia/Statemate connection software directory. Alternatively, you can view the contents of the code_link directory in a file browser window.

The generated code for the HVAC example is already compiled and linked into an executable program. You can use the go script (go.bat on the PC) located in the code_link directory to automatically start Altia Runtime and the generated code program. The go script knows how to start the Altia Runtime that resides in the altiastmm parent directory and open the hvac.dsn design file, which also resides in the parent directory, into the Altia Runtime. The script also starts the generated code executable (hvac on Unix or hvac.exe on the PC). As with the bindings.txt file for the simulator connection, the bindings.h file for a generated code connection can contain a start directive. However, without an Altia Runtime program and hvac.dsn design file in the code_link directory, the start directive is likely to fail so it is not enabled in the example bindings.h file. The go script succeeds because it starts things up manually using .. relative path names for Altia Runtime and hvac.dsn. If you like, feel free to study the script with your favorite text editor.

If you have the complete Altia Design product including the editor, you also have the option of starting the editor, opening the hvac.dsn file into the editor, and then directly executing the generated code program (hvac on Unix or hvac.exe on the PC) from a command prompt window or file browser window. The generated code program attempts to connect to an existing Altia session which will work because the editor is running. Put the editor into run mode (using the Run toggle button below the color palette) to interact with the generated code program.

1. Copy the user_activities.c and bindings.h files from the code_link sub-directory of altiastmm to the directory containing the generated code for your own Statemate model.

2. The user_activities.c file requires no modifications. The bindings.h file, however, must be modified. This is usually very easy to do if the model was connected to Altia while it was being run in the Statemate simulator. In this case, a bindings.txt file should already exist and the information it contains is easily migrated to your copy of bindings.h. To do this, open bindings.txt and bindings.h into separate text editor windows. For example, on the PC you could use Notepad or Wordpad. The bindings.h file is well commented and the comments are intended to walk you through the process of migrating the information from your bindings.txt file to your bindings.h file. In general, the information in bindings.h is just a C language form of the simple text information in bindings.txt.

3. Custom make files are generated for you when you generate the Statemate code. These make files already know how to compile user_activities.c and link it into the generated code executable; however, changes must be made to the make files so they find the necessary Altia include and library files. First, edit the User_Makefile file generated by Statemate and add:

4. Now you are ready to make using the Makefile file. In a command prompt window, you must change directory to your generated code directory. On Unix, simply execute make from the command (i.e., shell) prompt window. On Windows/NT with Microsoft 32-bit C/C++, execute nmake instead of make. In either case, here is a warning worth taking into consideration:

5. If the make completes successfully, you will have a new program in the current directory that is ready for execution. The name of the program depends on the name of the Statemate Compilation Profile used to generate the code. On Unix, the program will have no extension. On the PC, the program will have a .exe extension. The new program contains the Statemate generated code as well as the Altia user_activities.c file and bindings.h information. Because the bindings.h file is linked directly into the program, you must recompile the program (i.e. execute make or nmake again) and restart it if changes are made to bindings.h.

6. If you enable the start directive in your bindings.h file, the initialization portion of user_activities.c will attempt to start Altia Runtime and request it to open the design file designated in the start directive. For this to work properly, the Altia Runtime executable (altiart.out on Unix or altiart.exe on the PC) must be accessible to the generated code program. If the full Altia product software is installed in /usr/altia on Unix or \usr\altia on the PC, Altia Runtime is automatically accessible because it resides in /usr/altia/bin or \usr\altia\bin. If this is not the case, it may be easiest to simply copy the Altia Runtime executable to the local directory. You can copy the program from the Altia product software bin directory or from the Altia/Statemate connection software altiastmm directory. On Unix systems, you must also copy fonts.ali from the same directory if it is present. On PC systems, you must copy fonts.ali and colors.ali from the same directory. Failure to copy these files, if they are present, along with the Altia Runtime executable will result in unusual looking fonts and possibly unusual colors when a design opens into the Altia Runtime window(s). Another alternative to copying the runtime files to the local directory is to set the ALTIAHOME environment variable if you have a full Altia product software installation. For example if the Altia software bin directory is /opt/altia/bin, set ALTIAHOME to /opt/altia. If you are unsure how to set environment variables for your particular system, please consult your local Systems Administrator.

7. If you choose to disable the start directive in your bindings.h file, you must manually start Altia Runtime or the Altia editor before executing the generated code program. Or, copy the go script (go.bat on the PC) from the altiastmm code_link directory to the local directory, modify it to suit your specific environment, and execute it to start Altia and the generated code program.

8. You can stop the generated code program by typing a <Cntrl>-c key sequence to the program from the command prompt window. If you exit the main Altia interface window (for an Altia Runtime session, a <Cntrl>-c key sequence within the Altia window will terminate Altia Runtime), this will also terminate the program.

It is useful to note that the overall architectures of a simulator connection and generated code connection are similar. Only small differences are necessary to handle the variations in function call syntax between the Statemate simulator interface library and the Statemate interface library for generated code. As a result, the user_activities.c file in the code_link directory is actually an identical copy of the altia_stm.c source code file for the simulator connection. The C preprocessor #ifdef directive is used in the file to select between the different calling methods based on the compilation mode (simulator vs. generated code). For this reason, you can copy altia_stm.c to any generated code directory and name it user_activities.c.

For interfacing to the simulator, the standard altia_stm program reads a bindings file and performs simple translations between Statemate elements and Altia elements (i.e., animation, stimulus, or control names). Sophisticated users may outgrow the capabilities of the altia_stm program with a complicated model and user interface. For example, it may become necessary to provide a mapping between Statemate and Altia elements that have different names. Or, one might wish to manage the updating of Altia plots and strip charts, the opening of multiple views or designs, or the creation of Altia object clones given simple Statemate model changes (see the Models Libraries chapter in the Altia User's Guide for information on plots and strip charts and section III and IV of the Altia Reference Manual for descriptions of the Altia API functions available for managing views and clones).

For a custom simulator connection, the source file custom_altia_stm.c is provided as a starting point. It is a custom simulator connection for the HVAC demo. It emulates the functionality of altia_stm when it is used with the Altia HVAC design, Statemate HVAC model, and bindings.txt bindings file. The source file is well commented to help you customize it to suit your own Altia interface and Statemate model requirements. The example is already compiled into custom_altia_stm. It can be executed in place of altia_stm by simply typing custom_altia_stm provided Altia and Statemate have been started and set up according to the directions given earlier in this document. The Makefile file may be used to recompile the program with the command "make custom_altia_stm". To begin work on your own custom simulator connection, copy the custom_altia_stm.c source and the make file to your own working directory and dig in.

Please note that custom_altia_stm (custom_altia_stm.bat on the PC) is really just a script that checks the environment’s configuration and executes the program customaltiastm ( customaltiastm.exe on the PC) which is the actual custom simulator connection program. On the PC, the custom_altia_stm.bat script requires that the STM_ROOT environment variable be set for proper execution. This environment variable should be set automatically if Statemate is properly installed.

For a generated code connection, the files in the code_link sub-directory provide a sample of the code generated for the HVAC model. The custom_altia_stm.c file can be copied to the code_link directory as user_activities.c to demonstrate a custom generated code connection. All of the other source files are standard generated code except that minor changes were made to the Makefile and User_Makefile files so that they include the necessary Altia paths to header files and libraries. Copy the custom_altia_stm.c file to your own generated code working directory as user_activities.c and use it as a starting point for a custom generated code connection. Also, look at the Makefile and User_Makefile files in the code_link directory to determine the changes you must make to your own generated make files to resolve the Altia specific function and variable declarations in user_activities.c. If you wish to return to a standard generated code connection in the code_link directory, simply copy altia_stm.c from the altiastmm directory to the code_link sub-directory. The code_link directory also contains a README file with additional code generation information.

To summarize, custom_altia_stm.c is the starting point for a custom simulator connection and it can be used as a starting point for a generated code user_activities.c file. The overall architectures of a custom simulator connection and generated code connection are the same. Only small differences are present to handle the variations in function call syntax between the Statemate simulator interface library and the Statemate interface library for generated code. The C preprocessor #ifdef directive is used in the file to select between the different calling methods based on the compilation mode (simulator vs. generated code). If you edit custom_altia_stm.c and use the same #ifdef methods when making changes, you can use the file to create a custom simulator connection program or as the user_activities.c file for generated code! The benefit is that you can interface your Statemate model to an Altia design whether your model is running in the simulator or as generated code.