MetaTeD A Meta Language for Modeling. Telecommunication Networks. Kalyan S. Perumalla and Richard M. Fujimoto

Transcription

1 MetaTeD A Meta Lanuae or Modelin Telecommunication Networks Kalyan S. Perumalla and Richard M. Fujimoto (kalyan@cc.atech.edu and ujimoto@cc.atech.edu) Collee o Computin Georia Institute o Technoloy Atlanta, GA Andrew T. Oielski (ato@dimacs.ruters.edu) WINLAB Ruters University Piscataway, NJ GIT-CC December 31, 1996 (Last Updated June 13, 1998) ABSTRACT TeD is a lanuae desined mainly or modelin telecommunication networks. The TeD lanuae specication is separated into two parts (1) a meta lanuae (2) an external lanuae. The meta lanuae specication is concerned with the hih{level description o the structural and behavioral interaces o various network elements. The external lanuae specication is concerned with the detailed low-level description o the implementation o the structure and behavior o the network elements. The meta lanuae, called MetaTeD, is described in this document (An external lanuae specication, with C ++ as the external lanuae, is described in a separate related document.).

2 CONTENTS 1 Contents 1 Introduction 2 2 Backround 2 3 A Tutorial Overview o Concepts : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Entity Declaration : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Event and Channel Declarations : : : : : : : : : : : : : : : : : : : : : : : : Architecture Declaration : : : : : : : : : : : : : : : : : : : : : : : : : : : : : External Code Block : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 8 4 Syntax Reerence 9 5 Semantics Entity : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Inheritance : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Interace Enhancement : : : : : : : : : : : : : : : : : : : : : : : : : : Parametrized Structures : : : : : : : : : : : : : : : : : : : : : : : : : Implicit Parameter : : : : : : : : : : : : : : : : : : : : : : : : : : : : Parameter Lists : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Event : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Channel : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Inheritance : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Mappin : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Architecture : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Parameters : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Deerred Constants : : : : : : : : : : : : : : : : : : : : : : : : : : : : State : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Lare State : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Process : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Process Numberin : : : : : : : : : : : : : : : : : : : : : : : : : : : : Component : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Instance Namin : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Procedure : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Function : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Result : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Temporal Dependencies : : : : : : : : : : : : : : : : : : : : : : : : : File Inclusion : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : Conuration Specication : : : : : : : : : : : : : : : : : : : : : : : : : : : 25 6 Interoperability 25

3 1 INTRODUCTION 2 1 Introduction TeD is a lanuae desined mainly or modelin telecommunication networks. The TeD lanuae specication is split into two distinct parts MetaTeD and \external lanuae." MetaTeD denes a set o concepts or modelin the dynamic interactions o entities and their compositions, in an application-independent manner. MetaTeD is an incomplete lanuae it is more appropriately called a \ramework." When MetaTeD is appropriately combined with any reular eneral-purpose prorammin lanuae, say L, then a complete lanuae is ormed. Such a complete lanuae is called an L-instance or L-avor o TeD. For example, see [2] or the description o a C ++ -instance o TeD. In this document, only the MetaTeD concepts are described. Thus, the descriptions in this document apply to all instances o the TeD lanuae irrespective o the external lanuae used in the instance. 2 Backround Some o the main objectives in the desin o the TeD lanuae are: The lanuae should be suciently eneral or modelin current as well as uture telecommunication networks. The same lanuae should provide or specication, description as well as simulation o models (implies simulation-independent description). The lanuae should support object-orientation encapsulation, inheritance and polymorphism to acilitate hierarchical structure and behavior description. Models expressed in the lanuae should be amenable to hih-perormance parallel/distributed simulation (throuh automatic or semi-automatic translation). The lanuae should provide support or user-denable and extensible libraries. Our basic approach towards the desin o such a lanuae was as ollows. The analoous lanuae or hardware/vlsi domain, namely, the VHSIC Hardware Description Lanuae (VHDL), was examined[1]. Several concepts were borrowed rom VHDL and suitably modied to suit the telecommunication domain. Some VHDL concepts that are specic to the hardware domain were inored, and new concepts appropriate to the telecommunication domain were added. Also, support or object orientation was added to aid development o structural and behavioral heirarchies in the models. The result o this exercise is a new lanuae, which is an object-oriented, simulation-independent lanuae or modelin telecommunication networks. Throuhout the lanuae desin, emphasis was placed on stron modularity, and the separation o structure rom behavior, while at the same time retainin the ability to analyze the models throuh parallel simulation.

4 3 A TUTORIAL 3 Orthoonality o Concepts In the process o desinin the lanuae, it was observed that the set o concepts supported in this lanuae such as, elements o dynamic interaction amon entities is orthoonal to the set o concepts addressed in reular eneral-purpose prorammin lanuaes such as, data types and control ow. Most modelin lanuaes (VHDL, or example) combine these two orthoonal sets o concepts into one specication lanuae, even thouh it is oten possible to mix and match them toether. Hence, it was decided to careully separate the two sets o concepts. The concepts that speciy the relationships and dynamic interactions o the entities in the modelin domain are termed the meta lanuae MetaTeD. MetaTeD is datatype-unaware 1. When MetaTeD is suitably combined with any iven reular prorammin lanuae (called the \external" lanuae), a concrete instance o the TeD lanuae is ormed. For example, a C ++ instance o TeD is described in [2]. It is interestin to note that the use o an external lanuae is similar to the concept o \outsourcin"; in the context o the lanuae specication, it is wise to utilize the wellresearched and well-developed constructs o other lanuaes, and their well-tested tools, or the purposes o datatypes and control ow, instead o inventin and standardizin yet another eneral purpose lanuae. In the rest o the document, we shall use the terms TeD and MetaTeD interchaneably where no ambiuity exists. Also, by deault, we shall use C ++ as the external lanuae, ollowin the interace described in [2], in all the examples. 3 A Tutorial In the ollowin tutorial, the inormation on the constructs and semantics may be incomplete in the interest o clarity o basic introduction to the various concepts supported in the lanuae. The ollowin are some o the undamental concepts supported in the TeD lanuae: 1. Entity 2. Event 3. Channel 4. Architecture State Behavior Result Process Component In the ollowin sections, the basic terminoloy and semantics are introduced. 3.1 Overview o Concepts Fiure 1 illustrates the basic ramework underlyin the constructs in TeD, and their relation to each other. 1 With the exception o inteers; it reconizes inteers since it needs to \know" how to \count", in order to be able to dene parametrized structures (varyin number o entities and channels).

5 3 A TUTORIAL 4 ENTITY EVENT int a, b, c CHANNEL ARCHITECTURE STATE int i, j, k CHANNEL EVENT int l, m, n CHANNEL BEHAVIOR Process P { } Process R { } CHANNEL CHANNEL Component C Component D RESULT int x, y, z Fiure 1: Basic ramework o an Entity In TeD, physical and conceptual objects in the telecommunication domain are modeled in terms o entity descriptions. Entities are connected to- and interact with each other via channels. Channels are the only means o dynamic interaction between entities. Inormation units, called events, ow throuh channels. An output channel o one entity can be connected to the input channel o another entity. This allows or modelin o an arbitrary structure o connected entities. The dynamic behavior o each entity is described by its architecture. The architecture o an entity is expressed usin concurrent process semantics. It is essentially described in terms o the actions o the entity upon event arrivals on its input channels, and the production o events on its output channels. One or more processes can be dened to act upon events arrivin on the input channels o the entity. The processes may enerate events on output channels as part o their computation/action. An event enerated on an output channel arrives as input on the input channel to which the output channel is mapped. The architecture o an entity can also be expressed as as a composition o interactin components. Components are nothin but entities themselves (see ure 2) \loically enclosed" inside the bier entity. The channels o the components can be arbitrarily mapped amon each other or to the channels o the enclosin entity. Thus, the behavior o an entity can be described in terms o its structure (components) or dynamics (processes), or a combination o both. Entities are hihly modular. Except or the interaction throuh their channels, entities' state and behavior are completely encapsulated and invisible to other entities. The entity construct describes the entity's external input/output view, while the architecture construct describes the internal behavioral part o the object bein modeled. More than

6 3 A TUTORIAL 5 Entity E Architecture o E Entity E1 Entity E2 Process X channels Process P Process Y components o E Fiure 2: Entity with sub-entities Entity (External View) A A A A n (Bound) Architectures (Internal Views) Fiure 3: Sinle Entity { Multiple Architectures one architecture can be dened on/or an entity; however, exactly one o them must be chosen and bound to the entity or simulation-based analysis (see ure 3). Structural and behavior descriptions o an entity can be inherited by other similar entities, thus allowin object-oriented hierarchy-based desin and development. Inherited properties can be specialized, redened or overridden by the inheritin entity (sections 5.1 and 5.4 describe structure and behavior inheritance semantics). Fiure 4 is an illustration o some o the basic elements o a model and their relationship with respect to the physical object bein modeled. 3.2 Entity Declaration The entity construct is used to dene the external view o a physical or conceptual object. It essentially denes the input and output specications or the entity. In particular, it does not dene any internal behavior. The entity construct or the simple ATM multiplexer shown in ure 4 is as ollows:

7 3 A TUTORIAL 6 Model in TeD A[0] ATM Mux Entity S K B entity ATMMux( int N ) { channels { in ATMChannel A[N]; out ATMChannel B; } } arch RoundRobin o ATMMux { dconst{ int S, K; double T; } state{ int qlen, nsent, nlost; } A[N-1] #sent #lost } behavior{ process scan(...) {... } process update() {... } } result{ int totsent, totlost; } Fiure 4: Illustration o a physical entity and its model in TeD entity ATMMux ( int N ) channels in ATMChannel A[ $PARAM(N)$ ]; out ATMChannel B; In the above entity declaration, N is a parameter that denes the number o inputs. The multiplexer is dened to have N input channels, A[N], and one output channel, B. Each o the channels is o type ATMChannel, as dened in the next section. 3.3 Event and Channel Declarations A channel is a port o input or output or an entity. An output channel o an entity can be mapped to an input channel o another entity. An event is a unit o inormation that ows throuh channels. An event that is sent on an output channel, say, A in entity X, will appear as an arrival on the input channel, say, B in entity Y, i channel A is mapped to channel B. Each event type denition consists o the name o the event and the data associated with the event. Any number o event types can be dened per application. A channel type is dened as a set o event types. The channel type essentially denes that only those events belonin to the dened set o event types are allowed to \ow" throuh a channel o the iven type. Also, two channels can be mapped (connected) to

8 3 A TUTORIAL 7 each other i and only i they are o the same channel type (or compatible channel types see section 5.3). In the precedin ATM multiplexer example, the ATMChannel type can be dened as ollows: event ATMCell $ char data[ 53 ]; $ channel ATMChannel ATMCell The ATMCell declaration species an event type and its associated data. The ATMChannel declaration denes that any channel o type ATMChannel allows only ATMCell events to ow throuh it. Any number o event types can be specied in the list o event types or denin a channel type. The same event and channel types can be used in the denition o any number o entity types. In act, sharin the same event and channel denitions or several entity denitions aids in ensurin that those entities can be interconnected. 3.4 Architecture Declaration The architecture o an entity denes the internal behavioral model o an entity. The architecture description mainly consists o three parts the state, the behavior, and the result. The state is the set o variables that are used to denote the current status o the entity. The result consists o the set o variables that abstract the result o simulation o that entity. The behavior describes how the entity reacts on inormation arrival on its input channels, and how the entity enerates inormation onto its output channels. Two concepts process and component are available or the purpose o expressin the behavior. A process is a set o statements that are executed upon event arrival on an input channel. A component is just another entity, also called a sub-entity; thus, part o the behavior o the (enclosin) entity is expressed in terms o this (enclosed) entity. Any number o processes and components can be used in the architecture. Also, processes and components can both be used toether in the same architecture. To illustrate, ure 4 shows an internal view o the multiplexer o ure 4. In this view, the multiplexer uses a nite buer o size S, and the output link o the multiplexer is capable o transerrin K cells in one cell arrival time on any o the input links. Since the current occupancy o the buer is the only state inormation required, a variable qlen is used to represent the state. Additional measures, such as the cumulative number o cells transerred and the number o cells dropped due to buer overow, can also be added to the state. In such a case, this architecture may include those statistics as part o its result. For the description o the multiplexer's dynamic behavior, two processes are dened one process, scan, acts on cell arrivals on the input channels and enqueues them into the buer, while another process, update, models the transer o cells rom the buer onto the output link. The architecture construct or this behavior o the simple ATM multiplexer is as ollows:

9 3 A TUTORIAL 8 architecture RoundRobin o ATMMux ( int N ) dconst$ int S, K; double T; $ state$ int qlen, nsent, nlost; $ behavior process #1 scan( A ); process #2 update; result$ int totsent, totlost; $ The initialization o the state and result variables, and the denition o the code or the two processes scan and update are not dened here in the interest o brevity. Concrete examples, with complete source code and explanations, are iven in [2]. 3.5 External Code Block In MetaTeD models, external lanuae expressions and/or declarations are used or certain purposes. Such inserted code sements are called external code blocks. External code blocks are any valid external lanuae expressions (or declarations, dependin on the context) enclosed between a pair o $ sins, or between \{ and \} 2. The interace provided by the external lanuae environment to the external code blocks in MetaTeD models depends on the model development support provided or the particular external lanuae. 2 Linebreaks are not allowed to appear between $ sins.

10 4 SYNTAX REFERENCE 9 4 Syntax Reerence Keywords are set in bold. User-dened items are denoted in italics. Optional items are enclosed in [ square brackets ]. Alternative items are separated by j. use \model-unitname" import interace j implementation \ext-code-unitname" [ sure ] event event-type ext-var-decls channel channel-type [inherit base-channel-type] event-types entity entity-type [( param-decls )] [inherit base-entity-type [( param-decls )]] channels channel-decls where, param-decls is comma-separated list o one or more o: int var-name and, channel-decls is zero or more o: [overload] in j out j inout channel-type channel-var-name [[ ext-expr ]] ; architecture arch-type [( param-decls )] o entity-type [( param-decls )] [inherit base-arch-type [( param-decls )]] dconst ext-var-decls state ext-var-decls lstate ext-var-decls channels channel-decls behavior procedure #N procedure-name [( ext-ar-decls )] ; process #N process-name [( channel-vars )] [overload] ; component component-block-name ; [abstract] unction unction-name [( ext-ar-decls )] [returns ext-type] [overload] ; result ext-var-decls dconst entity-type : arch-type : init state entity-type : arch-type : init lstate entity-type : arch-type : init

11 4 SYNTAX REFERENCE 10 component entity-type : arch-type : component-block-name entities entity-instantiations map mappin-statement wrapup result-computation where, entity-instantiations is zero or more o: entity-name => entity-type [param-vals] : arch-type [param-vals] [[ ext-expr ]] ; mappin-statement and result-computation are s, and param-vals is %n( ext-ars ) process #N entity-name : arch-name : process-name [( channel-vars )] [waits wait-var-decls ] [calls call-var-decls ] [local ext-var-decls ] wait-statements and/or compute-statements where, channel-vars is comma-separated list o one or more o: channel-var [ [ ext-expr to ext-expr ] ] compute-statement is: wait-statement is: wait wait-clause ; wait-var-decls are zero or more o: var-name1, var-name2,... : wait-clause ; wait-clause is: on channel-vars until condition [ surely ] or expression condition and expression are: ext-exprs and, call-var-decls are zero or more o: var-name1, var-name2,... : procedure-name ; procedure: exactly same syntax as or process, except that channel-vars must be replaced with ext-ar-decls. unction entity-type : arch-type : unction-name [( ext-ar-decls )] [returns ext-type] result entity-type : arch-type : init result entity-type : arch-type : wrapup

12 5 SEMANTICS 11 ext-code-block: Any external lanuae source code enclosed between two $ sins, or between \{ and \}; newlines are not allowed between $ sins. ext-var-decls: ext-code-block containin variable declarations ext-expr: ext-code-block containin a valid expression ext-type: ext-code-block speciyin a sinle data-type ext-ar-decls: ext-code-block speciyin \ormal arument list" ext-ars: ext-code-block containin \actual arument list" : ext-code-block containin executable statement(s) 5 Semantics The ollowin sections describe the detailed semantics o each o the concepts in the TeD lanuae. 5.1 Entity The entity declaration is used to dene a black-box view o an entity. The entity could be a direct model o a real-lie object, such as a multiplexer, or o an abstract object, such as a protocol. The entity declaration only presents an external structural view o the object. It does not dene any behavior o the object. The syntax o the entity specication is as ollows: entity entity-type [( param-decls )] [inherit base-entity-type [( param-decls )]] channels channel-decls where param-decls is comma-separated list o one or more o: int var-name and, channel-decls is zero or more o: [overload] in j out j inout channel-type channel-var-name [[ ext-expr ]] ; Entities can have zero or more channels (called the interace channels), each o in, out or inout modes. Channels are typed (see Section 5.3 or a description o channel type declarations). The behavior o an entity is dened solely in terms o the entity's dynamic reactions to events on its input-mode channels, and the production o events on its outputmode channels Inheritance An entity, E2, can inherit the structure o another entity, E1, by usin the inherit clause as ollows: entity E2 inherit E1 E2 will contain all the interace channels o E1, in addition to any interace channels dened in E2.

13 5 SEMANTICS Interace Enhancement Entity E2 may \enhance" its interace by expandin the channel types o some or all o the inherited interace channels. For example, consider the ollowin declarations. event T1 event T2 channel C1 T1, T2 entity E1 channels in C1 A; event T3 channel C2 inherit C1 T3 entity E2 inherit E1 channels overload in C2 A; E2 enhanced its interace by includin acceptance o event type T3 on its inherited input channel A. Note that any behavior dened or E1 will still be valid or E2. The behavior can only be extended additionally to act on events o type T3 arrivin on A. Another type o enhancement is the promotion o the mode o an interace channel rom either in or out to inout. Both the mode and the type o an inherited channel can be enhanced by the inheritin entity. Note: I it is desired to enhance a sinle interace channel to an array o channels, it is necessary to dene the oriinal channel to be an array o lenth 1. Thus, the ollowin is invalid: entity E1 channels in C A; entity E2 inherit E1 channels overload in C A[ $100$ ]; Instead, E1 must be dened as ollows to achieve the desired eect. entity E1 channels in C A[ $1$ ] ; Parametrized Structures The parameter values can be used in the specication o sizes o channel arrays, thus eectively denin parametrized structures o entities. For example, a multiplexer entity parametrized by an interal value N can be dened as ollows.

14 5 SEMANTICS 13 entity E( int N ) channels in C A[ $ PARAM(N) $ ]; Implicit Parameter An implicit parameter, I, is predened or every entity. It denotes the index o the entity instance i the entity happens to be an element in an array o entities at the time o model execution. I the entity instance is not an element o an array, then the value o I is -1. No declared parameter o any entity must be named I Parameter Lists The parameter lists are concatenated when reerin to inherited entities. declarations illustrate the concatenation order. entity E1( int p1, int p2 ) The ollowin entity E2( int p3, int p4 ) inherit E1( int p1, int p2 ) entity E3( int p5 ) inherit E2( int p3, int p4, int p1, int p2 ) 5.2 Event Events are units o inormation exchaned between two dierent entities or between processes and components within an architecture o an entity. Events are \sent" throuh the interace channels between entities, or throuh the internal channels within the architecture o an entity. The ollowin is the syntax or declarin an event type: [sure] event event-type ext-var-decls The external lanuae shall provide a way to instantiate an event and to initialize the member variables o the event. No system-dependent inormation is provided to distinuish between any two instances o the same event type. I such a distinction is required, then distinuishin inormation must be included as event variables in an application-dependent ashion. The event may be sent and received in entities which are in two dierent address spaces; thus no assumptions may be made about shared address space. Thus, use o pointer values in events may not be supported by the external lanuae. Upon receipt o events on the channels o an entity, one or more actions can be perormed by the processes o that entity's architecture(s) (see Section 5.4.5). These actions,

15 5 SEMANTICS 14 in eneral, could potentially be executed more than once or the same event durin the simulation o the model (or example, i optimistic parallel simulators are used). In certain cases (such as, i input/output operations, or any other non-idempotent operations, are to be perormed as part o the event processin), it is desirable or some events to be taed so that the actions associated with their arrival are executed exactly once per event arrival. Thus, i an event type is taed with the sure keyword, then it is uaranteed that the actions upon arrival o any instance o the iven event type are executed exactly once per instance durin the simulation. 5.3 Channel Channels orm the medium or inter-entity or intra-architecture communication. Events ow throuh channels. The syntax or declarin a channel type is as ollows: channel channel-type [inherit base-channel-type] event-types The channel type declaration species the types o events that are permitted to \ow" throuh any channel o that channel type. Thus, a channel type is the denition o a subset o the set o all event types. Only instances o event types belonin to that subset are allowed to be sent and received on channels o the iven channel type. All channels are o inout-mode by deault. It is an error to send events on an in-mode channel, or listen on an out-mode channel. No more than one event can exist at any iven moment in simulated time on a channel. I an event \arrives" on an end o a channel while another event is \active," then the new event destroys the old event Inheritance When a channel type, C2, is declared to inherit another channel type, C1 (called the basechannel-type o C2), it implies that C2 includes all the event types o C1 in addition to those dened or C2. A channel type, C2, is said to be a superset o another channel type, C1, i and only i C2 is declared to inherit C1, either directly or by an inheritance-chain Mappin A channel can be mapped to another channel 3. By deault, external (interace) channels remain unmapped to any channels, while internal channels map to themselves. It is valid to send events on unmapped external channels; such events o into oblivion. The deault mappin (to themselves) o internal channels can be chaned by mappin them to channels o component entities. However, the internal channels cannot be reverted to unmapped condition. Two channels can be mapped to each other only i they are compatible with each other. Mappin compatibility o channels is dened as ollows. 3 Current specication allows or at most one channel to be mapped to any iven channel.

16 5 SEMANTICS 15 mode1 C1 ch1; mode2 C2 ch2; Given the precedin declarations, channels ch1 and ch2 are mappin-compatible i all the ollowin conditions are satised: Either C1 and C2 must be the same type, or one must be a superset o the other. I C1 is the same as C2 then: mode1 and mode2 cannot be the same, unless both are inout. I C2 is a superset o C1, then mode2 must be in, and mode1 must be out or inout. Similarly, i C1 is a superset o C2, then mode1 must be in, and mode2 must be out or inout. 5.4 Architecture The behavior o an entity is dened in terms o its architecture. While the entity declaration is analoous to an \interace" specication, the architecture declaration is analoous to an \implementation" specication. More than one architecture can be dened or the same entity type. For example, one architecture may be used to model the entity at at very ne level o ranularity o behavior usin several processes and components, while another architecture or the same entity may be dened or a coarser specication o behavior, perhaps usin just one process. The ollowin is the syntax or declarin an architecture o an entity: architecture arch-type [( param-decls )] o entity-type [( param-decls )] [inherit base-arch-type [( param-decls )]] dconst ext-var-decls state ext-var-decls lstate ext-var-decls channels channel-decls behavior procedure #N procedure-name [( ext-ar-decls )] ; process #N process-name [( channel-vars )] [overload] ; component component-block-name ; [abstract] unction unction-name [( ext-ar-decls )] [returns ext-type] [overload] ; result ext-var-decls The architecture o an entity is divided into the ollowin sections: A set o inteer variables that are used in denin parametrized strucutures/templates o entities and architectures. Parameters (param-decls):

17 5 SEMANTICS 16 Deerred Constants (dconst): A set o items whose values could be dierent or dierent instances o entity, even i the instances are o the same entity and architecture types. State (state): A set o variables that toether orm a part o the abstract state o the modeled entity. Lare State (lstate): A set o variables that are similar to the state variables, with the dierence that the memory size o these variables could be sinicant. Internal Channels (channels): A set o channels that are used or communication amon the internal processes and components o an architecture. Behavior Processes (behavior-process): A set o threads o computation that act on the events arrivin on the interace and internal channels. Behavior Components (behavior-component): A set o entities that loically orm subentities o an entity's behavior. Result (result): A set o values that are an abstraction o the \result" o \execution" o the model. Each o these concepts is described in the ollowin sections. Inheritance An architecture o an entity can inherit rom another architecture o the same entity type or rom an architecture o an entity type that is inherited by the iven entity type. An inheritin architecture inherits all the items o the inherited architecture. Thus, Parameters, Deerred constants, State, Lare State and Result variables, processes and component blocks are all inherited. All inherited items are visible in all inheritin architectures. There is no concept o limitin the scope o visibility in the inheritance o architectures Parameters Parameters are variables o type int. They are mainly desined to be used in the denition o parametrized structures. The parameters o entities can be used in the denition o external interace structure (external channels), while the parameters o architectures can be used in the denition o internal communication interace (internal channels). The external lanuae shall provide some way o accessin the values o the entity parameters in the declaration o external channels. Similarly, architecture parameters shall be available in the declaration o internal channels. Both types o parameters shall be accessible inside the processes and unctions o the architecture. When speciyin parameters or an entity-architecture pair, the parameter lists o the architecture and the entity are concatenated, with architecture parameters rst. I an architecture inherits another architecture, then their parameter lists are concatenated, with the inheritin architecture's parameters rst.

18 5 SEMANTICS Deerred Constants Deerred Constants are those that can be set to dierent values or dierent instances o entities. The external lanuae interace shall provide ways to initialize the constants to user-specied values, either at compile-time or \later than compile time". Facilities shall be provided to set dierent values to the deerred constants o dierent entity instances even i the instances are o the same entity and architecture types. The names and types o the deerred constants are declared in the dconst section o the architecture declaration. The syntax or the declaration o deerred constants inside an architecture is iven in section 5.4. The settin o instance-dependent values to these constants is perormed in the dconst-init construct outside o the architecture declaration, with the ollowin syntax. dconst entity-type : arch-type : init Once the values o the dconst variables are set, they remain constant throuhout the execution o the model; the external lanuae may enorce this by providin readonly access to the dconst variables, thus preventin their modication. In the initialization o dconst variables, the values o entity and architecture parameters o the object are available or use (parameter values are set beore deerred constants are initialized). I the architecture inherits another architecture, the deerred constants o the inherited architecture are initialized beore those o the inheritin architecture are initialized. The external lanuae shall provide some way o accessin the values o the deerred constants in the declaration o internal channels, and inside the processes and unctions o the architecture State State variables are those that toether constitute the internal data representation o the object's behavior. Given any instant in time, the values o the state variables toether uniquely and suciently dene the object. However, these values vary with time this variation constitutes a part o the dynamic behavior o the object. The syntax or the declaration o state variables is included in the architecture syntax. The syntax or the denition o initialization o the state variables is as ollows. state entity-type : arch-type : init In the state initialization, the values o entity and architecture parameters o the object, and the values o its deerred constants are available or use (deerred constants are initialized beore state variables are initialized). I the architecture inherits another architecture, the state variables o the inherited architecture are initialized beore the state variables o the inheritin architecture are initialized.

19 5 SEMANTICS 18 The external lanuae shall provide some way o accessin the state variables inside the processes and unctions o the object Lare State lstate entity-type : arch-type : init The external lanuae interace is ree to implement this set o variables in an applicationdependent ashion. On one extreme, these variables could be mered with the state variables. On the other extreme, severe restrictions on the datatypes, operations and access o these variables may be placed. The lstate construct is considered a \non-standard" part o the lanuae, and not all external lanuaes and all TeD modelin tools may support it. Similar to state variables, in the lare state initialization, the values o entity and architecture parameters o the object, and the values o its deerred constants are available or use (deerred constants are initialized beore state variables are initialized). I the architecture inherits another architecture, the lare state variables o the inherited architecture are initialized beore the lare state variables o the inheritin architecture are initialized Process Processes are the lea elements in the behavior tree dened by a hierarchy o entities. These are threads o computation actin on behal o the entities that own them. The owner entity's channels (internal and external) and state variables are accessible by the entity's processes. The basic unctionality o processes consists o combinations o two types o actions: computation (usin the state variables), and synchronization (usin channels or Time). Computation is some sequence o operations perormed on the state variables. Synchronization is some sequence o actions on the channels or Time. Processes can be cateorized into two types based on their channel-synchronization method. Arrival-driven processes are those that wait or activity on a set o channels, and perorm a sinle set o computation actions upon arrival o events on those channels. Such processes are said to occupy zero Time. Sel-driven processes are those that contain combinations o one or more computation and synchronization actions. Such processes are said to occupy positive Time. The syntax o process denition is as ollows:

20 5 SEMANTICS 19 process #N entity-name : arch-name : process-name [( channel-vars )] [waits wait-var-decls ] [calls call-var-decls ] [local ext-var-decls ] wait-statements and/or compute-statements where, channel-vars is comma-separated list o one or more o: channel-var [ [ ext-expr to ext-expr ] ] compute-statement is: wait-statement is: wait wait-clause ; wait-var-decls are zero or more o: var-name1, var-name2,... : wait-clause ; wait-clause is: on channel-vars until condition [ surely ] or expression condition and expression are: ext-exprs and, call-var-decls are zero or more o: var-name1, var-name2,... : procedure-name ; Computation actions are specied usin action statements in the external lanuae. The external lanuae interace shall provide means to access the parameter, deerred constant, state and lare state variables in such computation statements. The external lanuae interace shall also provide means to call procedures and unctions o the entity rom the computation statements o the process. Synchronization in Processes Synchronization actions in a process are specied usin the wait statement. The wait on channel-vars causes the process to wait until at least one event arrives on at least one channel in the list o channels iven by channel-vars. The wait or expression statement causes the process to wait or the amount o time iven by the expression. The wait until condition statement species that the process shall remain waitin until such time that the condition evaluates to \true". The or clause can be used alon with the on clause to achieve a timeout period on channel activity. The until clause can be used in conjunction with the on clause to achieve a wait or a parametrized instant in time or synchronization. Waits and Calls Synchronization can also occur inside the external lanuae computation statements usin implementation-dependent constructs that are equivalent in behavior to the external wait statements. The waits and calls declarations can be used in such synchronization. The waits construct is used to name distinct points inside external lanuae statements where time synchronization occurs. The same wait-clause can be used or more than one

21 5 SEMANTICS 20 wait-point, by declarin (bindin) those comma-separated wait variables to the same waitclause, and usin those variables inside the external lanuae code. Procedure invocations can occur inside the external lanuae statements. Each such invocation can be declared usin the calls construct. Multiple invocations o the same procedure in the same process (or procedure) can be specied by declarin (bindin) multiple comma-separated variable names to the same procedure name, and usin those variables inside the external lanuae code. Notes: The waits and calls declarations can be used only with procedures (see Section 5.4.9) and sel-driven processes. It is illeal to use them with arrival-driven processes. The waits and calls declarations should only name the wait-points and call-points that occur immediately in the iven process or procedure. Thus, the declarations must not include the transitive (indirect) synchronizations and invocations (or example, those that occur in the procedures invoked by the iven process or procedure). Local Variables Variables that are used locally in a procedure or process may be declared usin the local clause. Implementations may enorce other rules on the types o the variables that can be used or local variables. Also, typical implementations may require that those variables that need to retain their value across wait and call statements must be declared usin the local clause. Other The surely ta or the or clause can be used or achievin timin semantics in a manner analoous to the sure ta or events (see Section 5.2). When a process is active due to activity on the channels, then all the events at that instant o Time are available at the same time on all the channels that have arrivals on them at that moment o Time. In other words, all simultaneous events are presented on the channels simultaneously; hence, the process must act on all its active channels instead o just one o them. In a iven instance o an entity+architecture, the state variables o the architecture are \shared" by all the architecture's processes. Read/write conicts are resolved usin the implicit Time instant o access. Simultaneous accesses are serialized usin the order o declaration o the processes in the architecture declaration. The rank o a process in this orderin is based on initial point o declaration o the process, and the rank remains unchaned even i the process is overloaded in an inheritance chain. Note that orderins other than the deault can be achieved usin appropriately desined synchronization via internal channels.

22 5 SEMANTICS Process Numberin Any number o processes can be dened or a iven architecture. The process number is the key in distinuishin it rom other processes within the same entity. Hence, the process name can be treated merely as a mnemonic. Two dierent processes in the same architecture cannot have the same number; however, process numbers o two processes in two dierent architectures o the same entity can be the same. Moreover, i one o the architectures inherits rom the other, and a process o the inheritin architecture has the same number as the number o a process o the inherited architecture, then the process in the inheritin architecture must be explicity declared to overload the correspondin process o the inherited architecture usin the overload a in the process declaration. Such an overloadin process in the inheritin architecture completely replaces the overloaded process in the inherited architecture. I two processes are loically distinct, then they must have distinct process numbers, even across inherited architectures. Thus, process numbers in an inheritin architecture must not overlap with the process numbers in the inherited architecture, unless the overlap is intended (or overloadin the process, as previously explained) Component An entity that is used as a means o denin the behavior o another entity is called a component. An entity's architecture can use one or more components. The components in an architecture may be rouped into one or more non-overlappin blocks accordin to the loical relationships amon them. Each such roup is called a component block. The components in a component block can be interconnected to each other. The components may also be connected to the processes o the enclosin architecture via internal channels. In other words, the basic behavior o an entity's architecture can be dened in terms o processes and component blocks, where the channels o the entites within each component block are connected to the channels o other entities in the same component block, or to the internal channels o the architecture, while the processes act on the entity's interace channels as well as internal channels. Any number o component blocks can be dened or a iven architecture. The syntax or the declaration o a component block is included in the syntax or architecture. The syntax or the denition o a component block is as ollows: component entity-type : arch-type : component-block-name entities entity-instantiations map mappin-statement wrapup result-computation where, entity-instantiations is zero or more o: entity-name => entity-type [param-vals] : arch-type [param-vals] [[ ext-expr ]] ; mappin-statement and result-computation are s, and param-vals is %n( ext-ars )

23 5 SEMANTICS 22 The entities section declares the entity and architecture types o one or more component entities comprisin a component block o the architecture. The map section denes the mappin pattern amon the channels o the enclosin entity and the component entities. The wrapup section is used to extract the results o the component entities at the end o the model-exection. The component block denition may speciy a iven entity+architecture type or its component entity instances, thus, eectively bindin the instance to that entity type and architecture at compile time. Alternatively, the bindin can be postponed or later-thancompile-time by speciyin a? in the place o the entity-type or arch-type. I? is used to postpone the specication o the entity type, then no architecture type must be specied. However, i an entity type is specied, then the bindin o architecture type can be postponed by usin? or arch-type. The runtime component o the external lanuae interace shall provide means o bindin the entity and/or architecture types in a later-than-compiletime ashion (or example, usin a Conuration Lanuae). I an entity type or architecture type is specied, then the inteer parameter values required or instantiatin such an entity must also be specied. I the entity requires no aruments, then the parameters can be omitted. Otherwise, the aruments must be specied within parentheses, and the count o aruments in the parameter lists must be specied ollowin a % precedin the parentheses Instance Namin All entity instances in a iven model execution are assined unique strin names. These names are independent o the entity and architecture types o the instances, and the namin scheme is uniorm and independent o the instance types. It is assumed that there is exactly one entity that is initially instantiated per model-execution. This entity, called the root entity, may be o any entity type and architecture type, and it may speciy one or more entities as its components in its architecture, as is the normal capability available in any entity's architecture. The namin scheme is as ollows: The name o the root entity is always root. I a iven entity is not the root entity, then it must be a component entity o another (parent) entity. Let the parent entity's instance name be denoted as PARENT. Suppose the component block o the architecture o the parent entity names the iven component entity instance as comp (as specied usin the entity-name clause in the component block denition see Section 5.4.7). Then, the name o a component o an entity is iven by PARENT.comp. I the component is an element in an array o entities (aain, as iven by the component block denition), then, the component's instance name is iven by PARENT.comp[n], where n is the index o the element in the array.

24 5 SEMANTICS Procedure A Procedure is almost identical in syntax and semantics to a Process. They dier as ollows: Processes can call procedures, but procedures cannot call processes. however, can call procedures and unctions, just as processes can. Procedures, Processes are spontaneously triered upon initialization o the ownin entity; procedures are not activated until invoked by some process or procedure o the entity. Upon executin the last statement, processes loop back to the rst statement, thus runnin or ever, but procedures return immediately to their caller. Processes take channel variables as aruments, but procedures (like unctions) take eneral external variables as aruments. Note that, unlike processes, the presence or absence o aruments does not aect the semantics o procedures (the semantics o processes, on the other hand, is dierent dependin on presence or absence o channel aruments). The same procedure can be invoked by more than one process at the same time. Procedures are re-entrant, and use the stack o the correspondin callin process or each invocation. Procedures can take aruments, just like unctions (see Section ). However, unlike unctions, they cannot evaluate to a return value. I the procedure needs to return a result value, it can do so usin its aruments. The syntax o procedure denition is as ollows: procedure: exactly same syntax as or process, except that channel-vars must be replaced with ext-ar-decls Function Functions are units o external lanuae code, dened or convenience in model development. The external lanuae shall provide means or invokin unctions rom the statements o processes. Functions are scoped similar to processes and state variables. The syntax or the declaration o unctions is included in the syntax or the architecture declaration. The syntax or the denition o unctions is as ollows: unction entity-type : arch-type : unction-name [( ext-ar-decls )] [returns ext-type] Result The syntax or the initialization o result variables is as ollows:

25 5 SEMANTICS 24 result entity-type : arch-type : init The syntax or usin the result variables at the end o model-execution is as ollows: result entity-type : arch-type : wrapup Temporal Dependencies The ollowin is the set sequence o actions perormed or each entity upon creation, in the specied order o precedence: 1. Parameter values are set. 2. Deerred constants are initialized. 3. State variables are initialized. 4. Lare State variables are initialized. 5. Result variables are initialized. 6. Component entities are created. 7. Component channel mappins are perormed. Durin the model execution, in any iven entity, processes are executed accordin to the timeline o activity. I more than one process is active at the same point on the timeline, then processes are executed in the order in which the processes are declared in their architecture declarations. At the end o \model execution," the ollowin sequence o actions is perormed or each entity, bottom-most entities rst to the root entity last. 1. component-wrapup is perormed or each component block. 2. result-wrapup is perormed. The precedin sequence is perormed or all component entities beore the same is perormed or the entity that encloses those component entities. 5.5 File Inclusion To aid in modular development and reuse o models, compiler directives are provided that permit inclusion o reerences o other models in the denition o a iven model. The units o model development may vary with the taret system such as les in a le-based system, or table names in a database-based system. Two orms o directives are supported: