SAREF extension for the Smart Lifts domain

The present document is a technical specification of SAREF4LIFT, an extension of SAREF for the Smart Lifts domain. This SAREF extension is based on a limited set of use cases and existing data models identified within available initiatives that was detailed in previous documents ETSI TR 103 546 [i.1] and ETSI TS 103 735 [i.2]. The work was initially conducted (in 2021) in the context of the closed STF 602 (https://portal.etsi.org/STF/STFs/STF-HomePages/STF602), which was established with the goal of creating SAREF extension for the domain mentioned above, i.e. Smart Lifts. This work has been developed in close collaboration with the industrial world and alliances.

The related initiatives and use cases considered for the intialdevelopment (in 2021) of the SAREF4LIFT extension are the ones reported previously in ETSI TR 103 546 [i.1] and ETSI TS 103 735 [i.2]. Such related initiatives and use cases are not repeated in the present document. Hence, the reader can rely on those references for further details.

The present document is a major 2024 revision of SAREF4LIFT ontology extension, developed in the context of the STF 641 (https://portal.etsi.org/xtfs/#/xTF/641), using updated reference ontology patterns specified in ETSI TS 103 548 [9] to solve the harmonization needs identified in ETSI TR 103 781 [i.5], with updated development framework and tools defined in ETSI TS 103 673 [i.6].

Requirements

The requirements presented in this clause 5 have been derived from the previously presented use cases. Even if not every requirement is useful for every use case, the different categories of requirements taken into account are expected to support at least the use cases described in ETSI TS 103 735 [i.2].

The associated requirements have been grouped in different categories and are presented from Table 5-1 to Table 5-11.

SAREF4LIFT ontology and semantics

Introduction and overview

The present document is a technical specification of SAREF4LIFT, an extension of SAREF (ETSI TS 103 264 [1]) for the Smart Lifts domain. Clause 6.1 of the present document shortly introduces a high level view of the envisioned SAREF4LIFT semantic model and modular ontology, with the retained concepts (i.e. classes) and their relations.

SAREF4LIFT has been specified and formalized by investigating related resources in the Smart Lifts domain, as reported in ETSI TR 103 546 [i.1] and ETSI TS 103 735 [i.2]. Therefore, SAREF4LIFT shall both:

• allow the implementation of a limited set of related use cases already identified in ETSI TR 103 546 [i.1]; and
• fulfil the requirements provided in clause 5, mainly the ontological ones that were mostly taken as input for the ontology specification.

SAREF4LIFT is an OWL-DL ontology. For embedded semantic analytics purposes, SAREF4LIFT shall be designed using the modularity principle and can thus be mainly described by a set of knowledge modules. All these SAREF4LIFT modules are fully detailed in clause 6.2 of the present document.

The prefixes and namespaces used in SAREF4LIFT and in the present document are listed in Table 6.1-1.

SAREF4LIFT

General Overview

Figure 6.2.1-1 presents the high level view of the envisioned model of SAREF4LIFT ontology. In Figure 6.2.1-1, classes directly imported from SAREF ontology are in light orange, classes directly imported from other SAREF extension ontologies are in green. While, classes developed for SAREF4LIFT are in blue and, finally, individuals are illustrated in white blocks.

Within Figure 6.2.1-1, as well as within all the figures that are depicted in clause 8 of the present document, the following conventions are used:

• Arrows are used to represent properties between classes and to represent some RDF, RDF-S and OWL constructs, more precisely:
  • Plain arrows with white triangles represent the rdfs:subClassOf relation between two classes. The origin of the arrow is the class to be declared as subclass of the class at the destination of the arrow.
  • Dashed arrows between two classes indicate a local restriction in the origin class, i.e. that the object property can be instantiated between the classes in the origin and the destination of the arrow. The identifier of the object property is indicated within the arrow.
• Datatype properties are denoted by rectangles attached to the classes, in an UML-oriented way. Dashed boxes represent local restrictions in the class, i.e. datatype properties that can be applied to the class they are attached to.
• Individuals are denoted by rectangles in which the identifier is underlined.

As already introduced in clause 6.1 of the present document SAREF4LIFT is an OWL-DL ontology and shall be designed using the modularity principle (see ETSI TR 103 510 [i.4]) and can thus be mainly described by the following self-contained knowledge modules:

• Systems and connections. This module defines the different systems modelled within a smart lift environment. A system is described as a component virtually isolated from the environment, whose behaviour and interactions with the environment are specifically defined. Systems can be connected to other systems. Connected systems interact in some ways. Systems can also have subsystems. Properties of subsystems somehow contribute to the properties of the supersystem.
• Devices and commands. This module defines the devices included within a smart lift. A device is defined as a tangible object designed to accomplish a particular task. In order to accomplish this task, the device performs one or more functions. The root of this branch (saref:Device) is inherited directly from the SAREF Core ontology. Also, this module defines commands supported by the defined smart lift. A command is defined as a directive that a device should support to perform a certain function. A command may act upon a state, but does not necessarily act upon a state. For example, the ON command acts upon the ON/OFF state, but the GET command does not act upon any state, it simply gives a directive to retrieve a certain value. The root of this branch (saref:Command) is inherited directly from the SAREF Core ontology.
• States and observations. This module defines states that features of interest in a smart lift installation can be found in, and observations that can be made about features of interest in a smart lift.
• Signals. This module describes the types of signals supported by a smart lift. Four types of signals have been identified: car signal (s4lift:AlarmSignal), fault signal (s4lift:FaultSignal), status signal (s4lift:StatusSignal), and statistic signal (s4lift:StatisticSignal). Clause 6.2.5 provides a complete taxonomy of supported signals with respect to the ones reported in Figure 6.2.1-1.

Besides the four modules described above, the SAREF4LIFT extension defines also two new property types (s4lift:Load and s4lift:Voltage) defining the load in the smart lift car and the electric voltage of some electric power system.

Systems and connections

This module specializes the SAREF4SYST ontology pattern for the Smart Lift domain.

A Smart Lift system can be defined as a s4syst:System made by different components. This module defines the subcomponents that are part of Smart Lift. In particular, two subcomponents are denoted: the s4lift:SmartLiftEdgeComponent and the s4lift:SmartLiftEdgeControlUnit. The former is dedicated to the hosting of smart lift additional modules in the case that they are not hosted directly in the s4lift:SmartLiftEdgeControlUnit. An example could be the case of an additional earthquake sensor added after the lift deployment and not controlled by the s4lift:SmartLiftEdgeControlUnit. The latter is the main element of a Smart Lift installation and it is typically associated with the lift control cabinet.

A s4lift:SmartLiftInstallation corresponds to a single lift, with all its elements. Such a concept is equipped with the list of properties shown in Figure 6.2.2-1. Seven types of installations are considered relevant for this extension: namely s4lift:AccessibleGoodsOnlySmartLift as per EN 81-31 [2], s4lift: FirefightersSmartLift as per EN 81-72 [3], s4lift:GoodsSmartLift, and s4lift:MachineRoomLessSmartLift, s4lift:PassengerAndGoodsPassengerSmartLift as per EN 81-20 [4], s4lift:SmartLiftWithoutEmergencyCallSupport, s4lift:VerticalSmartLiftingPlatform as per EN 81-41 [5]. All these concepts represent a type of smart lift that can be instantiated by the ontology.

A s4lift:SmartLiftGroup represents the correlation of multiple Smart Lifts Installation and it is supported by the introduction of a Smart Lift Group identifier common each Smart Lifts Installation belonging to the same Smart Lift Group. Such kind of installations usually presents control units connected one each other to coordinate the movement and position of the different lifts, where the common commands (e.g. the call buttons) are given to one of these control units that acts as a principal master and coordinates the other installations or is composed by peer installations that coordinates one each other.

A s4lift:SmartLiftCar represents the car of a Smart Lift. A s4lift:SmartLiftInstallation usually contains different s4lift:CarStopSpaces serving different spaces of different floors at s4lift:Smart LiftCarService. A s4lift:SmartLiftCar can connect to some s4bldg:BuildingSpace through some s4lift:SmartLiftCarService at some s4lift:DoorConnectionPoint.

A s4lift:Network is the class of communication networks. Systems can connect to other networks through a potential s4lift:NetworkAccess connection.

Devices and commands

This model specifies the list of commands that is considered relevant for the smart lift domain. Six new commands are defined as instances of the saref:Command concept that can be triggered, in turn, by a saref:Function as presented in Figure 6.2.3-1:

• s4lift:MainBoardResetCommand defines the command for resetting the main board of a smart lift;
• s4lift:SendCarToSpecificServiceCommand defines the internal command for sending the car to a specific service;
• s4lift:SetOutOfServiceCommand defines the command for putting the smart lift in out of service mode;
• s4lift:SetRealTimeModeCommand defines the command for putting the smart lift in out of service mode;
• s4lift:TestEmergencyNumberCommand defines the command for testing if the emergency number is working;
• s4lift:TestRideCommand defines the command for performing a test ride of a smart lift.

States and observations

This module defines states that features of interest in a smart lift installation can be found in, and observations that can be made about features of interest in a smart lift.

Signals

This module describes the types of signals that can be read from a smart lift console. Figure 6.2.5-1 shows the taxonomy of the relevant types of signals foreseen within this extension.

It is possible to observe a set of four main types of signals:

• s4lift:AlarmSignal: this defines high priority signals used to attract the operator's attention to important deviations or abnormal events in system operation.
• s4lift:StatisticSignal: such signals convey (s4lift:conveys) a s4lift:StatisticsObservation about the smart lift usage.
• s4lift:FaultSignal: these are the signals sent by the smart lift car about its overall status. This concept subsumes three further concepts grouping likewise car signal types.
• s4lift:StatusSignal: these are signals that convey (s4lift:conveys) a saref:State of a feature of interest.

Descendants of the s4lift:Signal inherit the saref:hasTimestamp, saref:isAbout, and s4lift:conveys properties defining the timestamp when the signal has been generated and its value, respectively.

Object properties

A list of the object properties defined into the SAREF4LIFT extension is reported in Table 6.2.6-1. For each object property, the name, the domain, the range, and its definition are reported.

Datatype properties

A list of the datatype properties defined into the SAREF4LIFT extension is reported in Table 6.2.7-1. For each datatype property, the name, the domain, the range, and its definition are reported.

Instantiating SAREF4LIFT

This clause shows different examples of how to instantiate the SAREF4LIFT extension of SAREF.

The example presented in Figure 7-1 demonstrates how to represent information from group name SLIdentification as described in ETSI TS 103 735 [i.2], clause 6.2a. There are two new global identifiers of respective smart lifts installations defined: (mailto:lift.1415@company1.com and mailto:lift.1416@company1.com) and the global identifier of the associated group (mailto:group.10354@company1.com). Through the object properties s4lift:isMasterInGroup and s4lift:isSecondaryinGroup it is possible to define the importance level of each identifier.

The example presented in Figure 7-2 demonstrates how to represent administrative information associated with a s4lift:SmartLiftInstallation as described in ETSI TS 103 735 [i.2], clause 6.3.

The individual mailto:lift.1415@company1.com is subclass of both s4lift:SmartLiftInstallation and s4lift:PassengerAndGoodsPassengerSmartLift concepts in order to specify precisely the type of smart lift. Then, data properties describing the installation are provided and associated with it.

Finally, the example presented in Figure 7-3 demonstrates how to represent information from group name SLInstallation as described in ETSI TS 103 735 [i.2], clause 6.4.

As shown in Figure 7-1 and Figure 7-2, the installation labelled as mailto:lift.1415@company1.com is associated with the respective group and the related administrative information are defined.

Here is shown how the load capacity is defined through the definition of a the s4lift:carloadlimit property (linked through the s4lift:hasCarLoadLimit object property) that is associated with the related saref:Observation (s4lift:CarLoadLimitObservation).

Then, both the main power supply and the standard power supply are defined.

The s4lift:mainPowerSupply individual instantiates both the s4lift:ElectricalConnectionPoint and s4lift:ThreePhaseConnectionPoint concepts, it is associated with the measure property (s4lift:mainPowerSupplyVoltage) that in turn relates to the saref:Observation individual s4lift:mainPowerSupplyVoltageObservation.

Similarly, the s4lift:standardPowerSupply individual instantiates both the s4lift:ElectricalConnectionPoint and s4lift:SinglePhaseConnectionPoint concepts, it is associated with the measure property (s4lift:standardPowerSupplyVoltage) that in turn relates to the saref:Observation individual s4lift:standardPowerSupplyVoltageObservation.

Discussion

In the present clause 8, several observations about the SAREF4LIFT ontology and its usage are mentioned.

The hierarchies and individuals defined in the extension should not be considered exhaustive, the ontology currently represents those devices described in different relevant standards and directives. It might be needed to extend the hierarchies and lists of individuals for particular use cases, as well as to specialize some of the defined classes.

A last attention point is related to the possibility that this extension will overlap with existing standards related to the smart lifts domain, in particular, people can find on the web the mentions to a standard defined by the American Society of Mechanical Engineers (ASME, see https://www.asme.org/). However, on the ASME's website people are looking for the standard's documentation, but without succeed. Hence, people were not able to compare such a standard with the structure of SAREF ontology.

The SAREF4LIFT extends the SAREF core ontology by defining new subclasses of saref:Device, saref:Observation and saref:Property concepts. Details are reported below:

• saref:Device
  • s4lift:ElectricalDevice
  • s4lift:HydraulicDevice
  • s4lift:SmartLiftEdgeComponent
  • s4lift:SmartLiftEdgeControlUnit
• saref:Observation
  • s4lift:StatisticsObservation
    • s4lift:DownwardTravelsStatistics
    • s4lift:NumberOfCallsStatistics
    • s4lift:NumberOfFaults
    • s4lift:NumberOfResetSequencesStatistics
    • s4lift:TotalFloorsCoveredStatistics
    • s4lift:TotalNumberOfOpeningOfDoorStatistics
    • s4lift:TotalReversalDirectionStatistics
    • s4lift:UpwardTravelsStatistics
• saref:Property
  • s4lift:Load
  • s4lift:Voltage

The two new properties, since they are generic and could be used in other extensions, might be included in a future version of the SAREF ontology.

References

Normative references

• [0] ETSI TS 103 410-11 (V2.1.1): "SmartM2M;; Extension to SAREF; Part 11: Lift Domain".
• [1] ETSI TS 103 264: "SmartM2M; Smart Applications; Reference Ontology and oneM2M Mapping".
• [2] EN 81-31:2010: "Safety rules for the construction and installation of lifts - Lifts for the transport of goods only - Part 31:Accessible goods only lifts", (produced by CEN).
• [3] EN 81-72:2020: "Safety rules for the construction and installation of lifts - Particular applications for passenger and goods passenger lifts - Part 72: Firefighters lifts", (produced by CEN).
• [4] EN 81-20:2020: "Safety rules for the construction and installation of lifts - Lifts for the transport of persons and goods - Part 20: Passenger and goods passenger lifts", (produced by CEN).
• [5] EN 81-41:2010: "Safety rules for the construction and installation of lifts - Special lifts for the transport of persons and goods - Part 41: Vertical lifting platforms intended for use by persons with impaired mobility", (produced by CEN).
• [6] IETF RFC 3966: "The tel URI for Telephone Numbers".
• [7] EN 81-28:2018+AC:2019: "Safety rules for the construction and installation of lifts - Lifts for the transport of persons and goods - Part 28: Remote alarm on passenger and goods passenger lifts", (produced by CEN).
• [8] ETSI TS 145 008: "Digital cellular telecommunications system (Phase 2+) (GSM); GSM/EDGE Radio subsystem link control (3GPP TS 45.008)".
• [9] ETSI TS 103 548: "SmartM2M; SAREF reference ontology patterns".
• [10] Void.

Informative references

• [i.1] ETSI TR 103 546: "SmartM2M; Requirements & Feasibility study for Smart Lifts in IoT".
• [i.2] ETSI TS 103 735: "SmartM2M; Smart Lifts IoT System".
• [i.3] ISO 16484-5:2017: "Building automation and control systems (BACS) -- Part 5: Data communication protocol".
• [i.4] ETSI TR 103 510: "SmartM2M; SAREF extension investigation; Requirements for Wearables".
• [i.5] ETSI TR 103 781 (V1.1.1): "SmartM2M; Study for SAREF ontology patterns and usage guidelines".
• [i.6] ETSI TS 103 673: "SmartM2M; SAREF Development Framework and Workflow, Streamlining the Development of SAREF and its Extensions".

Acknowledgements

The editors would like to thank the ETSI SmartM2M technical committee for providing guidance and expertise.

Also, many thanks to the ETSI staff and all other current and former active Participants of the ETSI SmartM2M group for their support, technical input and suggestions that led to improvements to this ontology.

Also, special thanks goes to the ETSI SmartM2M Technical Officer Guillemin Patrick for his help.