**7. Examples of potential SEIS applications**

#### **7.1 Example 1: dynamic graphical status display**

A lift group controller supplies a SEIS conformant XML document, on demand, to a standard web browser. The browser invokes a locally held XML Style-sheet (XSL) transform to render the raw XML as an HTML graphical representation of the current status of the group (so, if desirable, the presentation might be rendered differently in each browser instance):

A static version of the display can be accessed from the SEIS website [41]. The displayed graphic (i.e. right-hand panel of **Figure 1**) is interactive so that car and landing calls may be registered by clicking on the 'button' images where calls are not currently registered (hovering over the button normally displays the text of the request that would be generated in the browser's status bar).

This example demonstrates how SEIS supports and promotes the Model-View-Controller (MVC) [42] software design pattern – SEIS defines the Model. The lift data is made independent of its presentation, so it is the choice of the client application (in this case a simple web browser) as to how to represent the data. If the client is a data logger then it may be that no transform is needed. The example graphic display is very crude and not easy to read, but a more sophisticated transform might produce a very attractive result. Of course, it is not necessary to display the XML source and XSL Stylesheet frames as they are simply there to illustrate this example.

*Standard Elevator Information Schema: Its Origins, Features and Example Applications DOI: http://dx.doi.org/10.5772/intechopen.92552*

**Figure 1.**

*XML source (left) is transformed by XSL (centre) renders HTML dynamic graphic status display (right).*

### **7.2 Example 2: auto validation**

This example shows how simply by referencing the SEIS schema (**Figure 2**, line 3 highlighted), an XML document [43] is validated. An error has been introduced (**Figure 2**, line 107 highlighted) into the document, assigning an invalid value to the Direction of Car 1's CarDynamicData, which is only valid if selected from the enumeration defined in the schema. The error is generated by the common class libraries that support XML. It has then been picked up and displayed to the user (**Figure 2**, bottom left circled), by the XML editor program in which the XML is being viewed. The resulting action will differ depending on the type of application which is receiving the erroneous XML, but the error detection is common.

#### **Figure 2.**

*XML document containing enumeration value error fails validation against SEIS schema.*

This example demonstrates the support, which the schema provides for its own inevitable updates and enhancements that may be introduced over the lifetime of an application which depends on it. Maintaining the application validation software is greatly simplified (so is much less costly) because it is unlikely that each installed instance of the application will need to be upgraded on site.

## **7.3 Example 3: dispatcher interface**

This example illustrates a group dispatcher published as a RESTful interface, conforming to SEIS and supporting the 'publish and subscribe' mode of interaction. The role of a dispatcher is to allocate passenger calls to the optimal lift in a group, as evaluated by an internal algorithm. The published interface is independent of the algorithm and it is the intention of the design that the dispatcher interface may be implemented in any installation configuration.

The aim of the example is to demonstrate how, by reference to a schema (i.e. SEIS) the dispatcher can operate simply through queries to and updates of the information without the need for a specific 'allocate this call' function. The benefits of this approach are that:


Because the computing power and network bandwidth available to such an application, probably running in the lift motor room, are likely to be 'constrained' this example was implemented for the CoAP [44] protocol, which is specifically designed to minimise processing and communication demands. CoAP messages have a similar format to HTTP messages used by web-browsers to access a web server – each request includes:


CoAP devices (endpoints) include a standard address '.well-known' which responds to a GET request by listing all the resources that the device supports so that, in this example, any lift can discover what nodes of the SEIS information model are supported by the dispatcher under the <GroupDynamicData> node as well as information on the algorithm and the group configuration under <GroupStaticData>. In this example we concentrate on the <RegisteredC alls><LandingCalls> sub-nodes within both the <GroupDynamicData>

*Standard Elevator Information Schema: Its Origins, Features and Example Applications DOI: http://dx.doi.org/10.5772/intechopen.92552*

and <CarDynamicData> nodes of a SEIS-conformant information model – these are published as CoAP resources.

Subscribing to a node is equivalent to making a GET request (with an 'Observe' flag) where the response containing the requested information is delayed until a change of state occurs in the node, and a response is re-sent with every subsequent change. Call stations (and mobile devices, etc. via secured apps on the Internet) subscribe to the <GroupDynamicData><RegisteredCalls><LandingCa lls> node. Lift car controllers subscribe to the same node.

In this example messages are formatted in JSON, replacing the long XML element tag-names with short two-letter acronyms, to reduce message size. So for example LandingCallType data is represented as:

the query – {"Fr=01","Dr="UP""} and

the payload:

{"Ss":0,"Df":0,"St":0.0,"Dn":0.0,"Ct":0.0,"Rk":0,"La":0, "Id":12345678}

where:

FloorFr; DirectionDr; StatusSs; DestinationDf; StartTimeSt; DurationDn; AssignedToLa; CallIDId; etc.

The transformation to JSON and auto-validation (as shown in Example 2) can still be achieved using standard software development tools to generate code automatically, by making reference to a schema definition.

The following sequence describes the process of allocating landing calls to lifts:

1.When a passenger registers a landing call, a POST message containing <Call-Registration> data is directed to the <GroupDynamicData><Register edCalls><LandingCalls> node (**Figure 3**):

```
Address of node:"GroupDynamicData/RegisteredCalls/
LandingCall"
```

```
Node query:{["Fr=01","Dr="UP""]}
Payload:{"Ss":0,"Df":10,"St":0.0,"Dn":0.0,"Ct":0.0,"Rk":0,
"La":0}
```
2.The dispatcher responds simply with a positive acknowledgement (ACK) to show that the POST request has been accepted. The response includes a unique reference (CallID - **Figure 3** dashed ellipse), so that the new data can be accessed in future, and which will be used to cross-reference future events associated with this landing call:

```
Response:Code=2.01, Type=ACK, MID=142, Token=03: 
{"Content-Format":"text/plain"} Payload: 8 Bytes 34350805
```
3.The dispatcher then performs what it is uniquely designed to do – finding the optimal lift to allocate to unallocated landing calls, at the same time possibly

**Figure 3.** *<GroupDynamicData><RegisteredCalls><LandingCall>.*

re-allocating other calls. The resulting allocations will be updated in the <GroupDynamicData><RegisteredCalls><LandingCalls> node.

4.The update will trigger the dispatcher interface to issue GET response CallAssignment messages to any car that has subscribed to the node and also to the subscribed call stations (possibly via a cloud-based app in the case of a mobile device). The message includes the CallID reference so that if necessary the call station can be notified to inform the passenger that their call has been registered ("Ss":1) and, in the case of a destination call, which lift has been allocated to their call:

**Response payload:**{"Ss":1,"Df":10,"St":40578.6,"Dn":0.0, "Ct":0.0,"Rk":0, "La":2,"Id":34350805}

At the same time the resulting allocation will be notified to any subscribed lift and the allocated lift car will update its own <CarDynamicData><RegisteredCalls> <LandingCalls> node, which signals acceptance of the allocation (see **Figure 4**).

#### **Figure 4.**

*<CarDynamicData><RegisteredCalls><LandingCalls>.*

5.When the allocated lift arrives, to cancel the call it sends a CallCancellation ("Ss":2) UPDATE message to the dispatcher interface (in this case the system response time – Dn – was 20.5 s):

**Address of node:**"GroupDynamicData/RegisteredCalls/LandingCall"

```
Node query:[""Fr=01","Dr="UP"","Id=34350805"]
```
**Payload:** {"Ss":2,"Df":10,"St":40578.6,"Dn":20.5,"La":2," Id":34350805"}

This process works either with direction calls or destination calls and in fact supports configurations where both types of landing call station are used concurrently. This example is discussed in more detail in a separate publication [45].

**7.4 Example 4: modelling and recording demand profiles**

An architect designing a 10 storey office building wishes to simulate the operation of the lifts, particularly with respect to the expected traffic to and from the restaurant on the top floor during the lunch period of a working day. The building

#### *Standard Elevator Information Schema: Its Origins, Features and Example Applications DOI: http://dx.doi.org/10.5772/intechopen.92552*

has two entry/exit floors at the lowest levels – garage (floor 1) and a main terminal lobby (floor 2) for pedestrian entry/exit. The CIBSE Office lunch peak traffic template [46] is selected to define the traffic demand profile to drive the evaluation simulation. This template describes traffic in each of 12 five-minute intervals over the lunch hour in terms of the travelling population (actually the number of passenger arrivals) during the interval as a percentage of the total building population. The travelling population is divided by percentage into each of three categories – Incoming, Outgoing and Interfloor.
