A connection represents the usage of an interface by a single client. The interface is provided by a server.

Connection structure:

(client_id, client_port, interface_name, server_id, server_port)

Client and server identifiers are symbolic names that denote communicating parties. The identifiers are unique in the scope of the events file. A communication party can play the role of a client in one connection and the role of a server in another one. For example, a component instance with a given name (declared in the component declarations section) can be a server for connections on the provided ports, and a client for the connections originating from its required ports.

An events file has to contain at least one connection declaration and may optionally contain declarations of component instances. If component instances are declared and used in the connections then the port names and their interfaces as given in the component definition must be used consistently in the connections. This is explained below.

In the example, a single component instance c0 of type Imaging is declared. The definition of Imaging is as follows (as a part of a definition not fully shown here):

component Imaging

provided port IImaging iImagPort

provided port ITemperature iTempPort

provided port IVacuum iVacPort

The names of the ports in the definition have to be used in the connections in which c0 participates. In the example file there is one client for each port (Client1, Client2, and Client3 respectively). This is captured in the declaration of three connections. As can be seen, the server ports and the associated interfaces match the component definition. The client identifiers and the client ports in this case are just names, there is no component declaration for them.

It is possible that a component instance is a client for another component instance. In this case the client port name in a connection must be equal to the name of a required port in the component definition. Circular connections in which a communicating party is a direct client of itself in the same connection are not allowed.

It is allowed to declare multiple component instances with different identifiers. Multiple component types can be used in component instance declarations.

There is a validity check for events that involve component instances:

A violation of the rules above will be indicated as an error in the events file editor when used in the Eclipse IDE. This is useful when the engineers experiment with small manually created event files in order to understand the file structure.

Component instances that appear as parts of another component instance have names that follow special convention. Assume we have three component models, namely A, B, and C, where A has two parts b, and c of type B and C respectively. If an instance a of type A is declared then its parts have to be declared in the following way:

In other words, the identifiers of the parts include the identifier of the containing instance.

Events are occurrences of commands and their replies, signals and notifications as defined in a CommaSuite signature.

An event has the following structure:

_EventId
Event_description
…
parameter
parameter
…
End

EventId is optional. If given, it is placed on the line before the event. It is useful for visualization purposes and for facilitating the correspondence between the error reports and the events where the error is detected.

The Event_description gives the type and the name of the event and time information about its occurrence. An event may have zero or more parameters, each on a separate line. The keyword ‘End’ indicates the end of the event description, it must always be present and placed on a new line.

The event description has the following format:

event_type timestamp time_delta source_id source_port target_id target_port interface_name event_name

Event descriptions are placed on a separate line.

An event may have zero or more parameters. Commands may have in, inout, and out parameters. A command event gives its in and inout parameters in the order of their definition in the signature.

A reply to a command gives parameters in the following order: inout and out parameters (if any) in the order of their definition, reply value (if any)

Every parameter is given in a separate line and has the following structure:

type_indicator value

Some examples:

command 1.0 0.0 Client2 p2 c0 iTempPort ITemperature SetTemperature
int 80
End

Reply 2.005 0.005 c0 iImagPort Client1 p1 IImaging PrepareImage
enum Result Ok
End

Record values have the following general structure:

Record_type_name field_values END

If the record type is defined in a CommaSuite interface, the name looks like:

_commaInterface interface_name type_name

If the record type is defined in a type file the name is just the name of the record type.

Field values are enumerated with a space as a delimiter and without giving the field names. Please note that type indicators for field values are not given either.

Examples:

Record type defined in an interface:

signature ITest
Type
enum Status {OK Failed}
record Point {real x, real y}

Record value of type Point:

Reply 0.4 0.04 Server ev Client1 p ITest getOnePoint
record _commaInterface ITest Point 0.0 0.0 END
End

Nested record type defined in an interface:

record Point {real x, real y}
record Arrow {Point begin, Point end}

Record value of type Arrow expressed in CommaSuite expression syntax:

Arrow{begin = Point{x = 0.0, y = 0.0}, end = Point{x = 0.0, y = 0.0}}

The same record value as a parameter in events file:

Reply 0.4 0.04 Server ev Client1 p ITest getArrow
record _commaInterface ITest Arrow _commaInterface ITest Point 0.0 0.0 END _commaInterface ITest Point 0.0 0.0 END END
End

Vector values have the following general structure:

Base_type_indicator size values END

Examples:

Vector type of records defined in an interface:

record Point {real x, real y}
vector Points = Point []

Value of type Points expressed in CommaSuite expression syntax:

<Points>[Point{x = 1.0, y = 2.1}, Point{x = 2.3, y = 3.2}]

The same vector value as a parameter in events file:

Notification 0.2 1.96 Server ev Client1 p ITest activePoints
vector record 2 _commaInterface ITest Point 1.0 2.1 END _commaInterface ITest Point 2.3 3.2 END END
End

Important: please note that maps are not supported as values carried by events. They, however, can be used in the models as variable values.