Textual Model Files written in the Tabular Data Blocks format contain blocks of data in the following order: Information Header, Case Parameters, Simulator Objects, Reference Objects, Component Objects, System Parts, Connection Links, Logged Attributes, and End Marker. Each block is started with a block title indicated by three leading pound-sign characters (###) followed by a space and the block name. The block contents are described in the Data Blocks section below following some explanations of special characters and formats.
Certain characters and strings of characters in the file have special meanings:
A single pound-sign (#) is used to indicate the beginning of a comment unless noted otherwise.
A string of pound-signs (########) is appended to the block title for legibility of the first block level.
A string of equal-signs (========) is appended to the second level block labels, used primarily for the separation of classes and cases.
A string of hyphens (--------) is appended to the third level block labels for the separation of variable name lists and data and in-between data objects.
The following sections describes the data blocks in detail.
Block Title: ### <Name> :Project Model ########
Starting out from the first line is the Information Header block title. The <Name> here is substituted with the actual name of the Project Model that the user created to generate the Model File.
All the lines in this block are comments, with the information as the following:
DATE: creation date of the Model File.
TIME: creation time of the Model File.
SIMULATOR: the name of the simulator and its version, followed by the description, the option, and then the company and the group information.
GENERATOR: SansGUI and its version in brackets [ ] for identification purposes.
CREATOR: the licensed user of SansGUI with license number in brackets [ ].
Block Title: ### Case Parameters ########
Case parameters contains bindings for all parameters. Each case has a leading title that starts with
Case <Number> ========
It is appended with the string of second level blocks. The <Number> in the title is substituted with the actual case number starting from 1. The format for each parameter binding is:
<CaseParameterName>=<Value>
In the binding syntax, <CaseParameterName> is substituted with the actual parameter name and <Value> is the binding value. There is an equal sign (=) in-between without any blank spaces. The bindings are separated with blank (space) delimiters. The first case contains a complete set of bindings for all parameters in the Project Model. Bindings in the subsequent cases override the bindings from their previous cases. Those without overriding bindings in a case will use the bindings in the previous case.
Block Title: ### Simulator Objects ########
This data block contains the the simulation control object in the Project Model. Only the Default external process simulation control object derived from the SimControl.XProc class path is listed.
Block Title: ### Reference Objects ########
All the reference objects are listed in this data block with the third level block separator (a comment sign with hyphens) between two objects. The objects are listed in the name order as in the Object Tree View in SansGUI.
Block Title: ### Component Objects ########
Component objects are listed in this data block. When any port attributes are present, the values of all ports are written behind all non-port values. See discussions below on Class Titles, Object Data, and Data Values for details.
Block Title: ### System Parts ########
This is the data block for all the parts in the assembly hierarchy. SansGUI flattens the assembly hierarchy into a model with a single level assembly before writing out the Model File. The header of the block shows the data in each field of the parts:
# SERIAL CLASS OBJECT PATH OVERRIDES
Each field is described in the following:
SERIAL: the serial number of the part, unique in all parts. It is the serial number of the part's parent assembly times 65536 plus the part number in the assembly. There is a space indentation before the SERIAL field in each part line.
CLASS: the full path name of the component class the part is derived from.
OBJECT: the name of the component object the part is derived from.
PATH: the name of the part with its full assembly path.
OVERRIDES: optional, contains <AttribueCode>=<Value> pairs of all the part overriding values using blank space delimiters
Each part occupies one text line without any wrapping. Therefore, if there are many part overriding values, the line can become very long.
Block Title: ### Connection Links ########
Similar to the System Parts block, connection links are listed in a single flat level to show all the connectivity in the model. When a link is used to connect to an assembly, the inner part is revealed as the connected part. Therefore, a link represents the connection between two end base parts. The header of the block indicates the fields of the links:
# SERIAL OBJECT PART1 PORT1 PART2 PORT2 PATH OVERRIDES
Each field is described in the following:
SERIAL: the serial number of the link, unique in all links. It is the serial number of the link's parent assembly times 65536 plus the link number in that assembly. There is a space indentation before the SERIAL field in each link line.
OBJECT: the name of the link object from which the link is derived. Different from the parts list, the class is not shown because there can be exactly one link class in the model.
PART1: the assembly path of the beginning part, from which the user started to create the link.
PORT1: the port number in PART1 used to attach to the link.
PART2: the assembly path of the ending part, to which the user completed the creation of the link.
PORT2: the port number in PART2 used to attach to the link.
PATH: the name of the link with its full assembly path.
OVERRIDES: optional, contains <AttributeCode>=<Value> pairs of all the link overriding values using blank space delimiters
Each link occupies one text line without any wrapping. Therefore, if there are many link overriding values, the line can become very long.
Block Title: ### Logged Attributes ########
The values in certain attributes of certain objects, parts or links may be logged during the simulation run, according to the user's request. This block contains the variable names of the logged attributes (codes) in all parts, links, and objects.
For parts, the title showing all the fields is:
Part ===================
# SERIAL PATH ATTRIBUTES
# ----------------------
SERIAL is the serial number of the part, PATH is the assembly path of the part, and ATTRIBUTES are requested attributes. A reminder here is that a part may have multiple port data in port attributes. If a port attribute is requested, data for all ports should be logged. There is a space indentation before the SERIAL field in each part line.
For links, the title is:
Link ===================
# SERIAL PATH ATTRIBUTES
# ----------------------
SERIAL is the serial number of the link, PATH is the assembly path of the link, and ATTRIBUTES are requested attributes. There is a space indentation before the SERIAL field in each link line.
For objects, the title is:
Object ================
# NAME CLASS ATTRIBUTES
# ---------------------
NAME is the name of the object, CLASS is the full path name of the class from which the object is derived, and ATTRIBUTES are requested attributes. There is a space indentation before the NAME field in each object line.
Each part, link, or object occupies one line. Therefore, if there are many logged attributes, the line may be very long.
Block Title: ### END ########
The end marker indicates the end of the file.
A class title leads a second level block with all objects derived from the class listed one by one. The syntax for the class titles is:
<ClassID> ======== [Version]
where <ClassID> is the full name path of the class and [Version] is the version number. The version number is right justified and a second level block string is filled between the class path and the version number. It is enclosed by a pair of square brackets [ ] with the major, minor, and patch numbers separated by a period (.). Examples are [1.2.0] and [2.0.alpha].
Following the identification line of the class title are the variable names of the class attributes (codes). They are written as comments for informational purposes only.
The variable names (attribute codes) in a class are written out before the data of the derived object, part, or link are written. A NAME label, indicating the names of the objects, is written before all the variable names.
If a class attribute has the Append Line Break flag set, the remaining variable list will start from a new line after the variable name is printed.
If a unit is associated with a variable, the variable name is followed by the simulator defined unit enclosed by a pair of brackets [ ].
For on-off switches, a [0|1] string is appended to the variable names to indicate possible values.
For tri-state switches, a [-1|0|+1] string is appended to the variable names to indicate possible values.
For enumerated items, all the selection items will be printed in a string according to the order of selections. The separator is the vertical bar (|) and the string is enclosed by a pair of brackets [ ].
For component classes with port attributes explicitly defined, the port attributes will be collected and written in each and every object before the port data; therefore, they are not listed under the class title. The port attributes forms a table with the attribute codes (variable names) written as the header, followed by the data of the ports. These tables are written in each object after the values of other scopes. The ports are written with a port numbers leading the data of each port.
The variable list is ended with a comment line filled with the third level block string (hyphens).
All the objects derived from the same class are listed after the class title. The NAME of the object leads all the data values without a line break. There is a space indentation before the object name. The data values of an object are written in the following manners:
Values in an object are listed in the order of the class attribute.
Data values are separated by blank spaces. There is a space indentation for the first data value in a text line.
A new line character is appended to the data value line each time when the associated attribute has the Append Line Break flag set.
Values of port attributes in component objects are printed behind all other object values. The variable names of the port attributes are listed as comments before the port data to form a port data table. Data associated with each port are printed separately with a leading port number.
A third level block label (a comment with hyphens) is inserted between two objects for separation.
Data values in Tabular Data Blocks are written as following:
A string of three question marks (???) is used to identify uninitialized (but allowed) data values.
If a variable has an associated unit of measure, the value will be converted to the unit specified by the simulation developer before printed out.
Vectors and matrices are enclosed by pairs of brackets [ ], as in the GUI controls.
Strings are always enclosed by double quotation marks ("). All the double quotes in the string are converted to single quotes (').
Masked strings are printed without the input mask literals.
Encrypted strings are decrypted before printed. Therefore, there is no advantage of using encrypted strings in an external process simulator.
The names of object references are printed as is, without any enclosing characters.
URL / File names are enclosed by the angle brackets < >.
Date values are printed as a string in the format of "yyyy/mm/dd", where yyyy is the year, mm is the month, and dd is the day.
Time values are printed as a string in the format of "hh:mm:ss", where hh is the hour in 24 hour format, mm is the minute, and ss is the second.
Quality values are enclosed by pairs of brackets [ ], as in the GUI controls.
In general, an array of data is printed with 10 data values per line. For continuation of data in subsequent lines, there are two spaces in front of the data values.
|
|
SansGUI Modeling and Simulation Environment Version 1.2
Copyright © 2000-2003 ProtoDesign, Inc. All rights reserved.