1

The RealityGrid Steering Grid Service.

Andrew Porter, SVE Group, Manchester Computing.

30th April 2004.

This document describes the RealityGrid Steering Grid Service (SGS) – what it is, how to install it and how to use it.

Change Log

Author Comments Date

Andrew Porter As released with v.1.1 of the RealityGrid steering software. 30th April 2004

Table of Contents Hosting Environment ..............................................................................................................2 Use Case .................................................................................................................................2 Launch Sequence – simulation component..............................................................................3 Launch Sequence – visualization component...........................................................................7 Steering Protocol ..................................................................................................................10 Methods supported by the Steering Grid Service...................................................................12

SGS-specific Client-side methods .....................................................................................12 Generic grid-service methods used for steering-related activity .........................................14 Internal methods................................................................................................................14

The Service Data Elements of the SGS..................................................................................16 The XML Schema for RealityGrid Steering ..........................................................................18

2

Hosting Environment The current implementation of the SGS is in Perl and uses the OGSI::Lite hosting environment created by M Mc Keown. The container will run under the latest version of Perl. However, in case of difficulties it should be noted that it was originally developed under Perl 5.6.1 and there are known problems with it under Perl 5.8.0. The hosting environment is available from http://www.sve.man.ac.uk/Research/AtoZ/ILCT. In the OGSI-Lite directory obtained from the tarball there is an extensive README file giving details on the configuration, launching and use of the Container.

Use Case For the purposes of this document we will consider a grid application consisting of two components; a simulation and a visualization. The simulation periodically produces data sets which are passed to the visualization component. Each component has an associated grid-service (GS) interface provided by a separate SGS process, as shown in Figure 1.

Figure 1: Architecture of example use case.

3

The grid application has an associated registry grid service that contains details of all of its constituent components. This allows another service (such as a steering client) to dynamically discover which components are steerable and how to contact them. It also facilitates the boot-strapping of a sockets-based connection between the simulation and visualization for the purpose of transmitting data. In the next section we describe the steps required to construct this example grid application.

Launch Sequence – simulation component This section assumes that you have the OGSI::Lite Container up and running and that its address is <container_address>, e.g. http://my.machine.ac.uk:50000/ (note that the terminating ‘/’ character is required). It also assumes that you have a simulation that has been ‘steering enabled’ and built against the RealityGrid steering library. The basic sequence of steps that must be performed to launch the simulation is as follows:

1. Create Registry factory GS 2. Use factory to create Registry GS 3. Create SGS factory GS 4. Register factory GS with Registry 5. Use factory to create SGS 6. Launch simulation and pass it address of SGS

This sequence is illustrated more fully in Figure 2. Once the simulation is up and running, it supplies the SGS with details of what commands it supports, what steerable parameters it has etc. This information is then available via the standard Grid Service method findServiceData.

4

SGS Container LauncherSGS FactoryRegistry

Init (Registry GSH, Content)

Application SteererRegistry Factory

Init

Launcher takes address of

Container as input.

Application passed

GSH of SGS.

findServiceData (some UID?)

GSH of SGS

Attach

SteererState = ATTACHED

<SGS:Supp_cmds/>

findServiceData <SGS:Param_defs/>

<SGS:Param_defs/>

findServiceData <SGS:IOType_defs/>

<SGS:IOType_defs/>

findServiceData <SGS:ChkType_defs/>

<SGS:ChkType_defs/>

setServiceData <SGS:ChkType_defs/>

setServiceData <SGS:IOType_defs/>

setServiceData <SGS:Param_defs/>

setServiceData <SGS:Supp_cmds/>

AppState = RUNNING

AppStart

Launch application

CreateService Registry

Factory GSH

Create Factory for registry

Get(factory_address)

Get(factory_address)

Create Factory for SGS

Factory GSH

CreateService SGS (Registry GSH, Content)

SGS GSH

Register SGS (Content)

Registry GSH

Figure 2: Sequence diagram showing simulation start-up.

5

We will now describe each of these steps in more detail: 1. Create Registry factory GS This presents a bit of a chicken-and-egg scenario – what should create a factory? The standard way of doing this is an http ‘get’ command. In this case therefore, if one were using Perl’s LWP::Simple module, one would do: $GSH = get("<container_address>ServiceGroupRegistration/factory");

(one can also use a standard web browser or the curl package). On successful execution of this command, a Grid Service Handle (GSH) for the factory is returned. This will look something like:

<container_address>SGS/factory/<long sequence of digits>,

(e.g. http://my.machine.ac.uk:50000/SGS/factory/55283031045120065675)and is the address1 used to contact the service. 2. Create Registry GS This is done by calling the standard createService method of the factory service we created in the first step. This method takes one argument, the ogsi:terminationTime of the requested service. Using the Perl SOAP::Lite package this would be done as follows: my $func = “createService”; my $result = SOAP::Lite ->uri(“factory”) ->proxy(“$ServiceGroupRegistration_factory_GSH”) ->$func(“<ogsi:terminationTime after =\”infinity\”/>”);

The createService method returns a locator and a termination time for the new grid service: <ogsi:createServiceResponse> <ogsi:locator> <ogsi:handle> http://my.machine.ac.uk:50000/ServiceGroupRegistration/service/4419303104512003702 </ogsi:handle> </ogsi:locator> <ogsi:currentTerminationTime> <ogsi:terminationTime before="2014-04-28T09:01:44Z" after="2014-04-28T09:01:44Z" timestamp="2004-04-30T09:01:44Z" /> </ogsi:currentTerminationTime> </ogsi:createServiceResponse>

The locator must be parsed in order to obtain the GSH for the newly-created service.

1 Strictly speaking it is therefore also a Grid Service Reference (GSR). OGSI::Lite does have a handle resolver for translating from a GSH to a GSR but, as at version 0.4, it need do no more than return the specified GSH. It is possible that this may change in future versions.

6

3. Create SGS factory GS As for step 1 with “SGS” replacing “ServiceGroupRegistration”. 4. Register SGS factory with Registry This is achieved by calling the add method of the ServiceGroupRegistration service. In SOAP::Lite this looks like: my $location = <<EOF; <ogsi:locator> <ogsi:handle>$sgs_GSH</ogsi:handle> </ogsi:locator> EOF my $content = “SGSfactory”; my $timeToLive = “<ogsi:terminationTime after=\”infinity\”/>”; my $func = “add”; my $result = SOAP::Lite ->uri(“ServiceGroupRegistration”) ->proxy(“$ServiceGroupRegistration_GSH”) ->$func($location, $content, $timeToLive);

The add method returns a locator and termination time for the resulting service entry (each entry in a ServiceGroupRegistration is itself a GS). 5. Create SGS This is similar to step 2. However, the createService method of the SGS factory has been extended and takes three additional arguments: the GSH of a registry, a string to associate with the entry in the registry and the GSH of the node in the checkpoint tree from which this job is starting. The latter may be omitted if there is no checkpoint tree associated with the job. The registry GSH and descriptive string are used to automatically register the SGS with the specified registry. (This is performed by the init method of the SGS which is called by the factory immediately upon creation of the SGS. The return value of the call to init is returned as an ogsi:extensibilityOutput element in the ogsi:createServiceResponse document.) 6. Launch simulation and pass it address of SGS The address of the SGS (its GSH) is passed to the simulation by setting the REG_SGS_ADDRESS environment variable before starting the executable.

7

Launch Sequence – visualization component Once the simulation component (consisting of the application and associated SGS) is up and running, we can add our visualization component to the grid application. The steps for doing this are as follows:

1. Query the registry for the Grid Service Handle of the simulation SGS; 2. Query the SGS to discover what IOTypes it has; 3. Choose one or more suitable IOTypes to be used as input to the visualization; 4. Create SGS factory GS (or possibly use existing factory service); 5. Create SGS for visualization component; 6. Initialise SGS with information on data source(s) to be used; 7. Launch visualization and pass it address of its SGS; 8. Visualization component connects to selected source when the Register_IOTypes

routine is called.

This sequence is illustrated more fully in Figure 3. We now treat each of these steps in more detail. 1. Query the registry for the Grid Service Handle of the simulation SGS We use the standard findServiceData method for this. In SOAP::Lite this is done as follows: my $func = “findServiceData”; my $sgs_list = SOAP::Lite ->uri(“ServiceGroupRegistration”) ->proxy(“$registry_GSH”) ->$func(“<ogsi:queryByServiceDataNames names=\”ogsi:entry\”/>”) ->result;

This query returns an xml document containing the handles and ‘content’ (describing the service and originally supplied as an argument to the add method) of each service registered. We might then let the user select the service they want to use as a data source from this list. 2. Query the SGS to discover what IOTypes it has Again, we use the findServiceData method to do this – calling it for the GS with the GSH we obtained in the first step. The query string for this step is: <ogsi:queryByServiceDataNames names=\”SGS:IOType_defs\”/>. This returns an XML document containing the definitions of the various IOTypes that the simulation has registered.

8

Registry App SGS Vis SGS Application VisualisationLauncherFactory

Register_IOTypes

Launch visualisation (GSH of vis. SGS)

GetNthDataSource

Address of listener

globus_io connect

setServiceData <SGS:Data_source_list/>

Choose data source (IOType_ID)

<SGS:IOType_defs/>

findServiceData <SGS:IOType_defs/>

Init (Registry GSH, Content)

CreateService SGS (Registry GSH, Content)

SGS GSH

Register SGS (Content)

findServiceData <SGS:IOType_defs>

Figure 3: Launching sequence for visualization component.

3. Choose one or more suitable IOType(s) to be used as input to the visualization It is up to us to parse the document obtained in the previous step to find those IOTypes that are for output and match our requirements – maybe by giving the user a list of the labels associated with these IOTypes and letting them choose at deployment time. (This assumes that the labels act as Unique Identifiers for the IOTypes.) 4. Create SGS factory GS, 5. Create SGS for visualization component These steps are essentially identical to those performed in launching the SGS associated with the simulation. The only difference is likely to be the ‘content’ specified when registering the service (passed to the createService method) as this needs to identify the component as being some sort of visualization (e.g. “vtk 4.2 volume visualizer”). Note also that it may not be necessary to create another SGS factory; the registry may be queried for any pre-existing factories and one of those used instead.

9

6. Initialise SGS with information on selected data source(s) For this we call the setServiceData method of our visualization’s SGS and set its <SGS:Data_source_list> service data with the data obtained in step 3 (essentially a list of GSH, IOType label pairs). In SOAP::Lite this can be done as follows: my $dataSources = “<SGS:Data_source_list> <SGS:Data_source> <SGS:Source_GSH>“ . $GSH_of_sim_SGS . “</SGS:Source_GSH> <SGS:Source_label>“ . $Chosen_IOType_label . “</SGS:Source_label> </SGS:Data_source> </SGS:Data_source_list>”; my $func = “setServiceData”; my $arg = "<ogsi:setByServiceDataNames>".$dataSources. "</ogsi:setByServiceDataNames>"; my $result = SOAP::Lite ->uri(“SGS”) ->proxy(“$vis_SGS_GSH”) ->$func(“$arg”); 7. Launch visualization and pass it address of its SGS As with the simulation, this is done by setting the REG_SGS_ADDRESS environment variable prior to running the executable. 8. Visualization component connects to selected source when Register_IOTypes called The visualization component must be built against the RealityGrid steering library and use its support for data sample consumption. When a call to Register_IOTypes is made, the library queries the SGS for the <SGS:Data_source_list> service data. Each successive IOType that is registered is mapped to successive entries in this list. Each entry in the <SGS:Data_source_list> contains the GSH for the SGS of the data source and the label of the IOType to use from that source. The visualization SGS queries the specified SGS for the definition of that IOType using findServiceData (see Figure 3) and can thus discover how to connect to it (i.e. obtain a hostname and port).

10

Steering Protocol The SGS makes use of both standard GS methods (such as setServiceData) and steering-specific methods in allowing a client to perform steering actions. The steering-specific methods are summarised in the state diagram of the SGS which is shown in Figure 4.

Figure 4: State diagram for the SGS.

Those methods beginning “App” are intended to be called by the simulation/visualization program. The remainder are intended to be called by a steering client and take no arguments.

11

The following pseudo-code gives an indication of how the methods supported by the SGS (highlighted in red) might be used by a steering client. Note that the SGS has Service Data Elements (SDEs) which are used to store aspects of both its state and that of the application for which it is providing an interface. // Attach to the application to be steered. Get back an XML // document describing the commands it supports. supportedCommands = Attach(); // Start of main loop – continue until user exits or // application detaches while(!done){ // Notifications take priority so check for them first GetNotifications(); if(got some notifications){ // Get the contents of any modified SDEs findServiceData(…); take appropriate action (e.g. detach if application has stopped, store checkpoint-type definitions etc.); } // Now check for standard status reports from the application GetStatus(); if(got a status message)parse it; // Respond to user requests (normally in a separate thread) if(user requests built-in action){ Pause(); or Resume(); or Stop(); } else if(user edits a parameter, requests data emit or checkpoint){ Generate XML doc describing action; PutControl(); } } // We’re done – detach from the SGS Detach();

Note that GetStatus and PutControl deal in XML documents conforming to the ReG_steer_message schema (distributed with the steering library and given at the end of this document).

12

Methods supported by the Steering Grid Service This section describes all of the methods of the SGS.

SGS-specific Client-side methods Attach If successful, returns an xml document containing the steering commands that the application supports. This document will be of the form: <SGS:Supported_cmds> <ReG_steer_message> - - </ReG_steer_message> </SGS:Supported_cmds>

i.e. it consists of a standard RealityGrid steering message (conforming to the http://www.realitygrid.org/xml/steering schema as distributed with the steering library and given at the end of this document) wrapped by tags identifying which service-data element of the SGS it comes from. If unsuccessful (e.g. if another steering client is already attached), returns the string “SGS_ERROR”. Detach Informs the simulation that the steerer has detached. Simulation should call AppDetach to confirm (this is done automatically by the steering library). Returns “SGS_SUCCESS” on successful completion, “SGS_ERROR” otherwise. GetNotifications Returns a (space-delimited) list of the names of the service data elements that have changed since the last call of this method. It is then up to the client to get their new values using findServiceData. Intended for monitoring of e.g. simulation state (running, stopped etc.). Using this approach to notifications (as opposed to the official OGSI mechanisms) has the advantage that the SGS never has to initiate a connection to the steering client. Such a connection could prove problematic when the machine running the client is behind a firewall.

13

GetNthDataSource Intended for use by visualization components – i.e. they call this method on their SGS in order to get details on where to get data from (see Figure 3). Takes an integer argument (i.e. N) which is ≥ 1 and returns the end-point of that data source. Currently this is specific to the sockets-implementation of IOTypes in the RealityGrid steering library and so returns a string of the form: “fully_qualified_hostname:port”. This routine is called when the visualization component calls Register_IOTypes in the steering library. N is 1 for the first IOType registered, 2 for the second etc. GetStatus Returns the next status message emitted by the simulation or an empty string if no new status message is available. Messages are returned to the client in the order they are received from the simulation. The status message is an XML document conforming to the RealityGrid steering schema (given at the end of this document). Pause Instructs the simulation to pause. Returns “SGS_SUCCESS” or “SGS_ERROR”. The latter may occur if the simulation’s state is not “RUNNING” (see Figure 4). PutControl Send a control message to the simulation. This message is an XML document conforming to the RealityGrid steering schema. Returns “SGS_SUCCESS” on successful completion, “SGS_ERROR” otherwise (which may indicate that the SGS has run out of free buffers in which to store control messages or that the client is not attached). Resume Instruct a paused simulation to resume execution. Returns “SGS_SUCCESS” or “SGS_ERROR”. The latter will occur if the simulation is not already paused. Stop Instruct a simulation to stop executing. Returns “SGS_SUCCESS” or “SGS_ERROR”. The latter may indicate that no simulation is in contact with the SGS or that its state is not “RUNNING” or “PAUSED”.

14

Generic grid-service methods used for steering-related activity Destroy Destroy the SGS. Only to be used for clean-up – no checking is done on the state of any attached steering client or simulation. If the SGS being destroyed was automatically registered with a Registry on creation (by supplying the GSH of a Registry service in the call to createService) then calling this method causes the service to un-register itself (by destroying its associated ServiceGroupEntry service). findServiceData Query the grid service to find the content of the specified service data element(s). See the OGSI specification. Calling this method also unsets any pending notifications on the specified service data elements (since the client now has their current contents). setServiceData Set the content of the specified service data element(s). See the OGSI specification.

Internal methods These methods are listed for completeness although they are intended only to be called by the simulation or visualization for which the SGS is the interface. AppStart Called to signal to the SGS that the simulation (or visualization) is now running/available to be steered. AppStop Called to signal the SGS that the simulation is no-longer available to be steered. AppDetach Called by the steered component to confirm receipt of a Detach command. GetControl Used to get the next control message from the steering client. Returns an XML document conforming to the RealityGrid steering schema or an empty string if no message available. Messages are obtained in the same order as they are produced by the steering client.

15

PutStatus Used to send a status message to an attached steering client. Again, the message is an XML document conforming to the RealityGrid steering schema.

16

The Service Data Elements of the SGS In this section we list the SDEs of the SGS in alphabetical order. These may be queried using the standard OGSI findServiceData method. The only SDE intended to be modified by a steering client is SGS:Status_msg_queue_size (see below).

SDE Name Description SGS:Application_name The string supplied by the application when it called

Steering_initialize. Intended to contain the name and version of the application.

SGS:Application_status Holds a string indicating the current status of the application associated with the SGS. Possible values are: NOT_STARTED, RUNNING, STOPPING, STOPPED, PAUSED

SGS:Chkpoint_GSH Holds the GSH of the node in the checkpoint tree associated with the checkpoint from which the job has been started (or the most recently created checkpoint from the current run). If the application is not associated with a checkpoint tree then this SDE will contain an empty string.

SGS:ChkType_defs Holds an XML document describing the checkpoint types registered by the application. Conforms to the ReG_steer_message XML schema.

SGS:Creation_time Holds a string containing the date and time at which the SGS was created.

SGS:Data_source_list Holds an XML document listing the data sources available to this SGS (set-up at launch time by client, typically after allowing user to select SGSs to act as data sources). Document is of the form: “<SGS:Data_source_list><SGS:Data_source> <SGS:Source_GSH>GSH</SGS:Source_GSH> <SGS:Source_label>label</SGS:Source_label>

</SGS:Data_source></SGS:Data_source_list>” GSH identifies the Grid Service acting as the data source and label identifies the IOType (of its associated application) to use.

SGS:Input_file Holds the raw input file used to start the associated application. Is raw text, not XML so if it contains XML special characters it may become corrupted during parsing (e.g. “<” will be replaced by “&lt;”). Input files should therefore not contain these characters or special care should be taken in handling the text returned by findServiceData.

SGS:IOType_defs Holds an XML document describing the IOTypes registered by the associated application. Conforms to the ReG_steer_message XML schema.

17

SGS:Machine_address Holds the fully-qualified hostname of the machine on which the application is running. (In the case of a machine with private backend nodes then this may specify the publicly-accessible address of the login node.) Discovered dynamically by the steering library when Steering_intialize is called.

SGS:Param_defs Holds an XML document describing the Parameters registered by the associated application. Conforms to the ReG_steer_message XML schema.

SGS:Registry_GSH The GSH of the registry with which the SGS is registered. SGS:serviceGroupEntryLocator Contains the ogsi:locator (see the OGSI spec.) of this

service’s entry in the registry identified by the GSH in SGS:Registry_GSH. It is this serviceGroupEntry service that must be destroyed to un-register the SGS.

SGS:Start_time Holds a string containing the date and time (according to the SGS) at which the application called the AppStart method of the SGS to signal that it had begun execution.

SGS:Status_msg_queue_size The length (number of message buffers) of the queue of status messages held by the SGS, constrained to be ≥ 1. Can be set at any time, even if the client is not currently attached. Note that if the queue is shortened then some status messages may be lost. Since messages are stored in cyclical fashion, the lost messages will effectively come from a random section of the existing queue (i.e. in general, they will be neither the most recently generated nor the oldest).

SGS:Steerer_status Holds a string indicating the status of any attached steering client. Possible values are: DETACHED, ATTACHED, DETACHING

SGS:Supp_cmds Holds an XML document describing the commands supported by the associated application. Conforms to the ReG_steer_message XML schema.

SGS:Working_directory Holds a string giving the absolute path of the application’s working directory. Used to locate checkpoint files.

18

The XML Schema for RealityGrid Steering This is the XML schema used for all steering messages. It is also used to specify the content of some of the SDEs of the SGS. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.realitygrid.org/xml/steering" targetNamespace="http://www.realitygrid.org/xml/steering" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="ReG_steer_message"> <xs:complexType> <xs:choice maxOccurs="1"> <xs:element name="Supported_commands" > <xs:complexType> <xs:sequence> <xs:element name="Command" type="CmdType" minOccurs="1" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Param_defs" > <xs:complexType> <xs:sequence> <xs:element name="Param" type="ParamType" minOccurs="1" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="App_status" type="StatusType" /> <xs:element name="Steer_control" type="ControlType" /> <xs:element name="IOType_defs" > <xs:complexType> <xs:sequence> <xs:element name="IOType" type="IOTypeType" minOccurs="1" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="ChkType_defs" > <xs:complexType> <xs:sequence> <xs:element name="ChkType" type="IOTypeType" minOccurs="1" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="Steer_log" > <xs:complexType> <xs:sequence> <xs:element name="Log_entry" type="LogEntryType" minOccurs="1" maxOccurs="unbounded" />

19

</xs:sequence> </xs:complexType> </xs:element> </xs:choice> </xs:complexType> </xs:element> <xs:complexType name="StatusType"> <xs:sequence> <xs:element name="Param" type="ParamType" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="Command" type="CmdType" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="ControlType"> <xs:sequence> <xs:element name="Command" type="CmdType" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="Param" type="ParamType" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="IOTypeType"> <xs:sequence> <xs:element name="Label" type="xs:token" minOccurs="1" maxOccurs="1" /> <xs:element name="Handle" type="xs:integer" minOccurs="1" maxOccurs="1" /> <xs:element name="Direction" type="xs:token" minOccurs="1" maxOccurs="1" /> <xs:element name="Freq_handle" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="Address" type="xs:token" minOccurs="0" maxOccurs="1" /> </xs:sequence> </xs:complexType> <xs:complexType name="ParamType"> <xs:sequence> <xs:element name="Label" type="xs:token" minOccurs="0" maxOccurs="1" /> <xs:element name="Steerable" type="xs:boolean" minOccurs="0" maxOccurs="1" /> <xs:element name="Type" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="Handle" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="Value" type="xs:token" minOccurs="0" maxOccurs="1" /> <xs:element name="Is_internal" type="xs:token" minOccurs="0" maxOccurs="1" /> <xs:element name="Min_value" type="xs:token" minOccurs="0" maxOccurs="1" />

20

<xs:element name="Max_value" type="xs:token" minOccurs="0" maxOccurs="1" /> </xs:sequence> </xs:complexType> <xs:complexType name="CmdType"> <xs:sequence> <xs:element name="Cmd_id" type="xs:integer" minOccurs="0" maxOccurs="1" /> <xs:element name="Cmd_name" type="xs:token" minOccurs="0" maxOccurs="1" /> <xs:element name="Cmd_param" type="ParamType" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="ChkLogEntryType"> <xs:sequence> <xs:element name="Key" type="xs:integer" minOccurs="1" maxOccurs="1" /> <xs:element name="Chk_handle" type="xs:integer" minOccurs="1" maxOccurs="1" /> <xs:element name="Chk_tag" type="xs:token" minOccurs="1" maxOccurs="1" /> <xs:element name="Param" type="ParamType" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="SteerLogEntryType"> <xs:sequence> <xs:element name="Command" type="CmdType" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="Param" type="ParamType" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> <xs:complexType name="LogEntryType"> <xs:sequence> <xs:element name="Seq_num" type="xs:integer" minOccurs="1" maxOccurs="1" /> <xs:element name="Steer_log_entry" type="SteerLogEntryType" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="Chk_log_entry" type="ChkLogEntryType" minOccurs="0" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:schema>