Scenario (CAD) Files

Scenario files contain declarations of the component instances that comprise a system. The examples presented below describe the structure of these files and illustrate the different aspects of the language. The formal grammar can be found here.

Example 1 : Scenario file imports, rates, and locations


system BasicScenario {
  importLIB common.*;
  importCPS common;

  Rates 20;

  Locations Board1, Board2, Board3;
}

This first example shows the section of a scenario file that specifies the external dependencies of the system and sets variables that may be used when declaring component instances and their connections. The first thing to note is that everything is enclosed within a system block. A system must have an identifier; in this case it is "BasicScenario". The identifier is similiar to a Java class name. The name of the scenario file, however, does not need to be the same as the system name.

The first keyword inside the system block is importLIB. importLIB tells the system which components it needs to import from the IR. Groups of components can be imported by using "<module name>.*", or individual components can be imported by giving their full name, such as "common.EventChannel". In Example 1, all of the components that are contained within the "common" module are being imported.

The importCPS keyword specifies which CPS files the system is dependent on. For every importCPS statement, there should be a corresponding file in the "system/cps" directory. Since Example 1 imports the "common" CPS file, there should be a CPS file called "common.cps" within the "system/cps" directory.

The Rates keyword specifies the rates at which periodic events arrive. Once established, these rates can then be used later in the file when declaring connections for component instances. In Example 1, the only rate declared is "20". Multiple rates are declared by using a comma-separated list of values, such as "5,10,20". A rate thread group is made for each different rate.

The final keyword used in Example 1 is Locations. Locations specifies where component instances can be placed. Location names are not bound to physical locations, but will subsequently be mapped to CORBA specific notions such as containers and nodes at deployment time.

Example 2 : Declaring component instances


system BasicScenario {
  importLIB common.*;
  importCPS common;

  Rates 20;

  Locations Board1, Board2, Board3;

  Instance EventChannel implements EventChannel on Board1 {
  }

  Instance GPS implements BMDevice on Board1 {
    connect this.timeOut to EventChannel.timeOut20 runRate 20;
  }

  Instance AirFrame implements BMClosedED on Board2 {
    connect this.inDataAvailable to GPS.outDataAvailable runRate 20;
    connect this.dataIn to GPS.dataOut;
  }

  Instance NavDisplay implements BMDisplay on Board3 {
    connect this.inDataAvailable to AirFrame.outDataAvailable runRate 20;
    connect this.dataIn to AirFrame.dataOut;
  }

}

Example 2 shows a scenario file that contains all of the elements of the CAD language. As the name implies, the Instance blocks declare actual instances of components. A similiar example in Java is creating an object that is an instance of a particular class. In Example 2, "GPS" is an instance of the component "BMDevice". It is important to note that the components implemented in scenario files must be declared in the IDL3 file. The location of the component is set by the identifier that follows the on keyword. This location must have been declared above by the Locations keyword. In Example 2, the "NavDisplay" component is located on "Board3".

Instance blocks are also used to specify how ports of one instance are connected to ports of other instances. This is done using the connect keyword. For example, the "dataIn" port of "NavDisplay" is connected to the "dataOut" port of instance "AirFrame". The standard convention is to declare connections on the client-side of a connection.

Both facet/receptacle and event source/sink connections can be described. Each event sink port connection uses the runRate clause to indicate the rate thread group that should run the event handler. The rate thread groups are declared above using the Rates keyword.

Last modified: 07/16/2003 4:12pm