**5.3 Aggregated information**

Aggregated information is subdivided, again to improve the efficiency of communications, into:


<sup>2</sup> NB the text of the following subsections is graphically illustrated on the SEIS website – SEIS element names are in Courier New typeface [39]

#### *5.3.1 Static data*

For a lift car (CarStaticData) – the list of floors served by the specific lift, the number of car decks and door operators, the reference speed profile(s), door timing and energy profile(s).

For a group (GroupStaticData) – information such as the floors served by the group, named floors, pre designated priority floors, floors included in fixed zones plus a selected dispatcher algorithm name. Additionally, the group static data contains the collection of car static data for the lifts in that group.

For a building (LocationStaticData) – the location name along with the collection of group static data and/or car static data for the groups and any single cars at the location.

#### *5.3.2 Dynamic data*

DynamicData describes the current state of individual lifts and each group as a whole. The root element of each aggregation of dynamic data elements is timestamped to specify the instant that it is valid in order to avoid inaccuracies due to possible communication delays. It should be noted that many of the dynamic data elements are specified as optional (multiplicity 0…1) to provide as much flexibility as possible to accommodate different installation configurations. Again, the dynamic data is separated into car-specific, group-specific and location-specific aggregations of elements of information:

**CarDynamicData** – includes floor position, committed (or next) direction of travel, door state, load, registered car and allocated landing calls. An optional additional element defines the Route which the car will follow in responding to its list of currently registered calls, which can be used for example to drive passenger information displays or to assist development and test activities.

**GroupDynamicData** – includes registered passenger landing calls (directional and/or destination) plus the collection of car dynamic data for the lifts in that group. Additionally, an optional DemandProfile for the group covering a number of data collection periods.

**LocationDynamicData** – is currently, simply the location name along with the collection of group dynamic data and/or car dynamic data for the groups and any single cars at the location. Additionally, an optional DemandProfile for the location covering a number of data collection periods.

#### **5.4 Event information**

Every event is time-stamped and includes the identifiers of the lift and/or group which generated the event. Optionally, the event may also include a destination identity which specifies the target object of the event (i.e. rather than the destination of the event message). Events may be communicated individually as a stream of updates or batched, providing flexible and efficient options for the design of data logging and status reporting systems. The time-stamp ensures that the sequence of events and the time they occurred are retained even if a communication link is temporarily lost or deliberately terminated.

A predefined set of event types, discovered from a thorough review of available literature plus experience of designing controller and management systems, is included in SEIS and this set may be enhanced as further experience is gained. It is therefore a requirement of SEIS that it is backwards compatible. Each predefined event type may have special properties, derived from SEIS type definitions, which are specific to that event.

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

**ExceptionEventType** – (describing a specific event instance) may contain other events thereby creating a context for the root event. This may represent the occurrence of an error, warning or simply some noteworthy information.

Recent developments of applications, which enable pre-emptive or predictive maintenance, use operating 'signatures' of devices to identify deviations from normal behaviour as an early indication of potential failure. Currently, the addition of an optional Signature property to the LogEventType is under consideration. Such a Signature data-type would need to be flexible and include the possibility of textual representation of a sequence of binary or analogue data values and an associated sampling interval.

### **5.5 Message formats**

We have already noted that SEIS is written in XML Schema Definition language (XSD) so XML might seem a logical choice for formatting messages that conform to the schema. The benefit of this is that received XML messages can be validated automatically against the schema using a number of third-party libraries and there are several editor tools that can generate validation classes directly from the schema in a variety of programming languages. Such tools and libraries can relieve software developers from the burden of significant code development and continuing maintenance effort.

However, an XML message format is not a requirement and similar auto-generation of validation code can be found for other formats, for example JSON. The advantage of JSON is that it is a much more efficient representation and removes a great deal of the bulk of tags that are required for XML. Even if XML is used, more compact messages can be achieved by translating SEIS's long tag names into short acronyms. This could even be achieved in real time by using an XSL style-sheet (this is illustrated in Section 7. Example 3).

#### **5.6 REST**

SEIS is a schema that defines an information model – it does not include any specification of functionality and so there are no supporting function calls specific to the operation of passenger lifts. Instead, the same set of standard generic functions can be requested from any supported node of the model and these functions are not at all related to building transportation systems. Thus every supported node in the model must offer the same four functions:


which might be implemented, for example, as a 'RESTful' [40] interface in a variety of programming technologies, or as a relational database with stored procedures, or similar. This underlines the technology-independent nature of SEIS. Nodes which have a multiplicity greater than 1 (i.e. lists) must support queries using the properties and referenced links of the node (this is illustrated in Section 7. Example 3). SEIS is independent of any network topology (e.g. proxies, gateways, firewalls, etc) so is scalable, which is another characteristic of REST.
