• Command Line
• API Functions
• XML Formats

XML Formats

The SADF tools utilise an XML syntax for specifying SADF graphs and for specifying the settings for simulation-based analysis.

Specifying SADF Graphs

The XML syntax for specifying SADF graphs is defined in sdf3-sadf.xsd. It allows standard XML parsers to check the validity of an XML specification. However, it excludes checks to ensure that an XML specification defines in fact a proper SADF graph. Such extended validation of the static semantics is performed by the XML parser for SADF graphs.

• Detailed explanation of the XML syntax for specifying SADF graphs
• Example XML specifications of SADF graphs

Main Layout

The main layout of an XML specification for SADF graphs is shown below. Assigning the value sadf to the type attribute of the sdf3 element specifies that the XML file contains the specification of an SADF graph. The (required) version attribute denotes the version of the XML syntax. The sadf element denotes the actual specification of an SADF graph, which should occur only once in the XML file. The optional name attribute for the sadf element enables specifying a name GraphName for the SADF graph, where the default value is SADF. The actual specification of an SADF graph consists of one structure and one set of properties.

Structure

The structure specification defines the processes and channels for an SADF graph, using the kernel, detector and channel elements as examplified below. Both the kernel and detector elements require specifying a name attribute to enable identifying the kernel or detector respectively by a name. The channel element also requires a name attribute. The required source and destination attributes of channel specify the processes that respectvely produce and consume tokens to/from the channel. The required type attribute indicates whether a channel is a data or control channel by using the value data or control respectively.

Properties

The properties define the behavioural properties of kernels and detectors as well as additional properties of channels using the kernel_properties, detector_properties and channel_properties elements respectively. These are explained in more detail below.

Kernel Properties

The definition of an SADF graph must include a specification of behavioural properties for each kernel using the kernel_properties element, which has a required attribute kernel to indicate the name of the kernel for which the properties are defined. The layout of the kernel_properties element is displayed below. It inlcudes at least one scenario specification using the scenario element. This element requires defining a name ScenarioName for the scenario by means of the name attribute. Scenarios for which a kernel is inactive do not need to be specified. The definition of a scenario may include four parts:

• Only in case a kernel has multiple control ports, the control element should be used for each control port to specify which combination of token values received through the control ports defines scenario ScenarioName. To this end, the control element requires specifying the channel name and token value received from that channel. In case the kernel has only one control port, the scenario is identified by matching the value of the received tokens with the ScenarioName
• In case a kernel consumes tokens from data channels in scenario ScenarioName, the consume element should be used. It requires specification of the channel name from which the tokens are received. Additionally, the number of tokens to receive (rate) must be specified using the tokens attribute
• When a kernel produces tokens onto data channels in scenario ScenarioName, the produce element should be used. It requires specification of the channel name to which the tokens must be send. Additionally, the number of tokens to send (rate) must be specified using the tokens attribute
• The optional profile element allows specification of an execution time distribution for scenario ScenarioName. In case no profile is specified, the execution time for scenario ScenarioName equals 0. The required execution_time attribute specifies the actual execution time (a positive real), whereas the optional weight attribute denotes the weight (a postive real) with which the execution_time should occur in relation to possible other execution times. In case the weight should equal 1, the weight attribute does not need to be specified. The XML parser converts the relative weights into probabilities

Detector Properties

The XML specification of an SADF graph must define the behavioural properties for each detector using the detector_properties element, which has a required attribute detector to indicate the name of the detector for which the properties are defined. The layout of the detector_properties element is depicted below. Only in case a detector has multiple control ports, the scenario element must be used for each scenario in which the detector can operate. It has a required attributed name to define a name ScenarioName for the considered scenario. The specification of the scenario must be completed by specifying which combination of token values received through the control ports defines scenario ScenarioName by using the control element for each control port. It requires specifying the channel name and token value received from that channel. Next to the possible specification of scenarios, the properties of a detector include at least one subscenario specification using the subscenario element. This element requires defining a name SubScenarioName for the subscenario by means of the name attribute. The definition of a subscenario may include three parts:

• In case a detector consumes tokens from data channels in subscenario SubScenarioName, the consume element should be used. It requires specification of the channel name from which the tokens are received. Additionally, the number of tokens to receive (rate) must be specified using the tokens attribute
• When a detector produces tokens in subscenario SubScenarioName, the produce element should be used. It requires specification of the channel name to which the tokens must be send. The number of tokens to send (rate) must also be specified using the tokens attribute. In case the channel is a control channel, the produced tokens are valued with the SubScenarioName. In case the produced tokens should be valued differently, the optional value attribute can be used
• The optional profile element allows specification of an execution time distribution for subscenario SubScenarioName. In case no profile is specified, the execution time for subscenario SubScenarioName equals 0. The required execution_time attribute specifies the actual execution time (a positive real), whereas the optional weight attribute denotes the weight (a postive real) with which the execution_time should occur in relation to possible other execution times. In case the weight should equal 1, the weight attribute does not need to be specified. The XML parser converts the relative weights into probabilities

Detectors involve specifying Markov chain(s) using the markov_chain element, which requires indicating an initial state via the initial_state attribute. The markov_chain element also has the optional attribute scenario, which must be used in case the detector has control ports. In such case, the number of specified Markov chains must match with the number of possible scenarios in which the detector can operate. If a detector has only one control port, the value ScenarioName of the scenario attribute must match with one of the possible values that tokens received via the control port may have. When multiple control ports exist, the ScenarioName should match with the name of a scenario defined using the scenario element (see above). Each markov_chain specification includes at least one state, which is defined using the state element. It requires the attributes name and subscenario to specify respectively the name of the state and the subscenario in which the detector will operates when visiting the state. Each state includes at least one transition to another state, which is specified using the transition element. The destination attribute of the transition element defines the destination state of the transition, while the weight attribute denotes the weight (a postive real) with which the considered transition should be taken in relation to possible other transitions from the considered state. In case the weight should equal 1, the weight attribute does not need to be specified. The XML parser converts the relative weights into probabilities.

Channel Properties

The specification of additional properties for channels follows the syntax displayed below. The required channel attribute of the channel_properties refers to the name of the channel for which additional properties are specified. To specify a number of initial tokens for data channels, the optional attribute number_of_initial_tokens can be used. In case the number_of_initial_tokens is not specified, the number of initial tokens equals 0. The specification of initial tokens for control channels can be accomplished using the optional attribute initial_tokens. The InitialTokenSequence consists of a comma separated list of elements of the form Number * TokenValue , where Number is a positive integer and TokenValue refers to the scenario value of the tokens. In case Number should be 1, the part with Number * can be ommited. Some examples of proper values for InitialTokenSequence are S1 and 2*S1,S2 as well as S1, 3 * S2 , 1 * S3 where the tokens will be consumed from left to right. In case the initial_tokens is not specified, the number of initial tokens equals 0. It is furthermore possible to specify a size for the buffer represented by the channel using the buffer_size attribute. Without explicitly extending an SADF graph with reverse channels to model finite buffer sizes, the SADF tools do take the availability of buffer space into account for channels for which the buffer_size is specified (after establishing the rates). If no buffer_size is specified, the buffer is considered to be unbounded. The optional token_size attribute allows specifying the size of a token communicated through the channel. Analysis results regarding the occupancy of the incorporated buffer are then expressed in the unit of the token size instead of in the number of tokens. Notice that InitialTokens, BufferSize and TokenSize must be positive integers.

Specifying Simulation Settings

The XML syntax for specifying the settings for simulation-based analysis is defined in sadf_settings.xsd.

• Detailed explanation of the XML syntax for specifying simulation settings