12.28 Use Cases for Smart Lifts
12.28.1 Description
These use cases have been elaborated to facilitate the potential support in oneM2M for Smart Lifts collecting and developing type and range of data which might be exchanged between lifts and their relevant management applications. It also includes the information about the monitoring of the activities and the performance of such lifts, including the possible interactions with the rest of the IoT devices and applications.
The information provided include:
- the combination of the data exchanged and their classification,
- the possible users of the data currently collected, organized as actors and user roles categories.
12.28.2 Actors
There are several type of user roles that are organized within three main categories:
- The users of the lift (the passengers) that could have different needs.
- The people and companies that work on the lift market.
- The owner of the building or administrator of group of building where the lift(s) is(are) installed.
For the purposes of the present use cases, users and roles have been classified as follows:
Building owner:
The owner of the building or a group of building.
Maintenance companies:
The companies that are in charge of the maintenance of the lifts, with the target to manage every problem that could arise on the lift.
Maintenance technicians:
The technicians of the maintenance companies, i.e. the people that work often on site, to fix problems and perform maintenance-related activities in general.
Passengers without priority:
The standard passenger of the lift.
Passengers with priority:
All the other kind of passenger that could have priority to use the lift (disabled people, elderly people, etc.).
Supplier technicians (especially of control cabinet):
The control cabinet is the brain of the lift, all the information is managed by the control cabinet; these are the technicians of the company that manufactured the control cabinet.
Control room operator:
People located in a (usually remote) control room, whose task is to supervise and control the operations of lifts or group of lifts.
12.28.3 Potential requirements
No specific new features are currently identified as result of the analysis of Smart Lift use cases. The oneM2M system Rel 3 seems to support properly these use cases. It remains necessary to include the data structure to be exchanged by Smart Lifts in the oneM2M semantic work. As it is also deemed to be included in the ETSI SAREF package to assure proper semantic interoperability with other systems it is also necessary to verify the SAREF alignment.
- oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in [i.21].
12.28.4 Management of Group of Lifts
12.28.4.1 Description
This case is about the control room operator that is in charge of monitoring and manage the lifts installed in the railway stations; the railways company want the possibility of monitoring the status of each lift and the possibility of controlling the lifts from a remote control room.
To achieve this purpose the control cabinet of the lift has to expose the status of several systems, making available the related signals and giving the possibility to send the commands to an individual lift or a to group of lifts (e.g. to make a ride to a specific floor).
This case could be extended to all the cases where the building's owners want to manage and monitor lifts in a single building or in several buildings (like railway stations, hospitals, office buildings, etc...); the objective is to manage and control the situation from a single and centralized control room.
Figure 12.28.4.1-1 Management of Group of Lifts: Overview
12.28.4.2 Source
RDM-2020-0011R03-Smart_Lifts_Use_Cases
Note
informative source refer to ETSI TR 103 546 Requirement & Feasibility study for Smart Lifts in IoT, Section 6.1 [i.22].
12.28.4.3 Actors
- [ ] Building owner.
- [ ] Maintenance companies.
- [ ] Maintenance technicians.
- [ ] Passengers without priority.
- [ ] Passengers with priority (disabled people, elderly people, etc.).
- [ ] Supplier technicians (especially of control cabinet)
- [X] Control room operator.
Note
the list above shows the actors identified in clause 12.28.2, those that are relevant for the current use case are marked with the symbol X.
12.28.4.4 Pre-conditions
The regulations for the railway stations are mandating that every day - before the opening of the railway station - the personnel who is in charge of the station has to perform a test ride; in this case this test ride can be performed from the control room by the operator.
To achieve this purpose the control cabinet of the lift has to expose the status of several systems making available the related signals and to give the possibility to send the commands to the lift or to a group of lifts (to make a ride to a specific floor, for example).
12.28.4.5 Triggers
The operator - by means of the control panel where he can see the status of the lifts - can evaluate if the test ride can be performed and - if all the parameters are OK - can conduct the test.
These test rides could be scheduled in function of the opening times of the railway stations, so the operator would not need to attend to all the tests in the control room.
12.28.4.6 Normal Flow
In the control room the operator would receive these categories of signals:
- Monitoring signals: all the monitoring signals except the statistic signals.
- Alarms signals: all the alarm signals.
- Command signal: call to a specific floor, send car to a specific floor, out of service, test ride.
12.28.4.7 Alternative flow
Another situation that the operator can manage from the control room, could be when a fault occurs and/or an alarm is activated.
In that case, by means of the CCTV display available in the control room the operator can have a view of what is happening in the lift and, based on that, take the needed actions, e.g.:
- alert the people in the railway station.
- notify the company that is in charge of the maintenance of the lift.
- alert the police or the firefighter.
12.28.4.8 Post-conditions
If the result of the test is positive, the lift can be left in service.
Result of test ride is notified to the railway station manager (e.g. by sending an email or via other suitable means).
12.28.4.9 High Level Illustration
None
12.28.4.10 Potential requirements
No specific new features are currently identified as result of the analysis of Smart Lift use cases. The oneM2M system Rel 3 seems to support properly these use cases. It remains necessary to include the data structure to be exchanged by Smart Lifts in the oneM2M semantic work. As it is also deemed to be included in the ETSI SAREF package to assure proper semantic interoperability with other systems it is also necessary to verify the SAREF alignment.
- oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in [i.21].
12.28.5 Predictive maintenance and Fault Resolution
12.28.5.1 Description
This case is about how the maintenance companies and technicians can use the available information to set a predictive maintenance program for the lift, and how they can use the remote connection with the lift to fix the faults or the problems.
Predictive maintenance is the "new" trend in lift industry even if it has been applied in several industrial sector for ages; the scope of predictive maintenance is to anticipate the event of a fault, evaluating the fault rate of the single components based on the number of runs of the lift. So, the maintenance companies can substitute the components before the fault arise and they can reduce the out of service for the lift.
Furthermore, there are some faults very hard to discover and that require long time to be fixed, so the capability for the maintenance technician to have the direct and real-time support by the control cabinet's technician could drastically reduce the out of service necessary to fix the fault.
A typical problem is that a fault has been detected but when the maintenance technician is on site the lift runs properly; this is a typical case when the users smash the manual landing doors with the consequence is that the locking devices work sometimes well and sometimes badly.
In this case for the maintenance technician it is very hard to discover the fault; the best solution is that the technician of the control cabinet supplier connects to the lift from the remote position and analyses the faults; by the history of the faults recorded and the capability of analysing the single input and output of the main board, he can very quickly identify which landing door causes the fault and - usually -- understand why the fault appears.
Figure 12.28.5.1-1 Preventive Maintenance and Fault Resolution: Overview
12.28.5.2 Source
RDM-2020-0011R03-Smart_Lifts_Use_Cases
Note
informative sources refer to ETSI TR 103 546 Requirement & Feasibility study for Smart Lifts in IoT, Section 6.1[i.22].
1228.5.3 Actors
- [ ] Building owner.
- [X] Maintenance companies.
- [X] Maintenance technicians.
- [ ] Passengers without priority.
- [ ] Passengers whit priority (disabled people, elderly people, etc.).
- [X] Supplier technicians (especially of control cabinet).
- [ ]Control room operator
Note
the list above shows the actors identified in clause 6.3.3, those that are relevant for the current use case are marked with the symbol X.
12.28.5.4 Pre-conditions
The lift is connected to a central platform, and the relevant information is transmitted.
On the platform, a set of automatic rules monitor the data received and determine if a failure is likely to happen soon, or if some part is likely to show sub-optimal performance due to predictable causes, such as wear.
Based on the kind of data and domain knowledge available, the rules complexity can range from simple ones, based on counting operating cycles or service time, to extremely sophisticated AI applications.
12.28.5.5 Triggers
With predictive maintenance the system sends a message to the maintenance company that the lifetime of a component (e.g. wheel of the doors, pushbutton, etc.) has expired.
12.28.5.6 Normal Flow
For the predictive maintenance:
- Monitoring signals: statistic signals.
For the fault's resolution:
- Monitoring signals: all the monitoring signals except the statistic signals.
- Command signal: call to a specific floor, send car to a specific floor, out of service, board reset.
12.28.5.7 Alternative flow
None
12.28.5.8 Post-conditions
Having received the notification of impending fault (e.g. by an e-mail report or by a message sent automatically by the lift), the maintenance company can send a technician to substitute the component with a new one. This can happen even in absence of a user call from the lift, thus reducing the time to repair and possibly avoiding the risk of service interruption altogether.
12.28.5.9 High Level Illustration
None
12.28.5.10 Potential requirements
No specific new features are currently identified as result of the analysis of Smart Lift use cases. The oneM2M system Rel 3 seems to support properly these use cases. It remains necessary to include the data structure to be exchanged by Smart Lifts in the oneM2M semantic work. As it is also deemed to be included in the ETSI SAREF package to assure proper semantic interoperability with other systems it is also necessary to verify the SAREF alignment.
- oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in [i.21].
12.28.6 Servicing Priority People
12.28.6.1 Description
There are some cases in which the system should manage passengers with priority (like disabled people) to give them the access to the lift - or better a group of lifts - in the faster and appropriate way.
In other cases, blind people could have a smart system when they can have access to a building more or less like all the other people, except the tactile path on the floor and/or tactile plan to understand where are the stairs, the lifts, the toilettes, etc.
Figure 12.28.6.1-1 Servicing Priority People: Overview
12.28.6.2 Source
RDM-2020-0011R03-Smart_Lifts_Use_Cases
Note
informative sources refer to ETSI TR 103 546 Requirement & Feasibility study for Smart Lifts in IoT, Section 6.1[i.22].
12.28.6.3 Actors
- [X] Building owner.
- [ ] Maintenance companies.
- [ ] Maintenance technicians.
- [X] Passengers without priority.
- [X] Passengers whit priority (disabled people, elderly people, etc.).
- [ ] Supplier technicians (especially of control cabinet).
- [ ] Control room operator.
Note
the list above shows the actors identified in clause 6.3.3, those that are relevant for the current use case are marked with the symbol X.
12.28.6.4 Pre-conditions
To achieve this the building has to manage and exchange the information through the devices and put the information available to the app. Both for the disabled people and blind people, the capability to do by them self every task is very important and with a simple application for mobile phone they can improve their quality of life.
12.28.6.5 Triggers
In a building with a group of lifts (for example office building, hospital, railway station, etc.), due to the traffic during the peak time, the cars of the lifts are full; if a system can recognize the people with disability (especially people on a wheelchair), the system can give priority to them and "reserve" a specific lift.
Another case is about blind people: if the system can recognize them at the entrance of the building and if the building is a Smart building, by an app on the mobile phone or similar device, the blind people can use the information available on the app to find the appropriate path inside the building, reach the lift and go to the office (or the train, etc.).
12.28.6.6 Normal Flow
All the signals,
- Monitoring signals: all the monitoring signals except the statistic signals.
- Alarms signals: all the alarm signals.
- Command signal: call to a specific floor, send car to a specific floor.
12.28.6.7 Alternative flow
None
12.28.6.8 Post-conditions
None
12.28.6.9 High Level Illustration
None
12.28.6.10 Potential requirements
No specific new features are currently identified as result of the analysis of Smart Lift use cases. The oneM2M system Rel 3 seems to support properly these use cases. It remains necessary to include the data structure to be exchanged by Smart Lifts in the oneM2M semantic work. As it is also deemed to be included in the ETSI SAREF package to assure proper semantic interoperability with other systems it is also necessary to verify the SAREF alignment.
- oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in [i.21].
12.28.7 Management of maintenance and inspection visits of the lift or group of lifts
12.28.7.1 Description
This case is about how to check the visits scheduled by the maintenance company, as well as those of verification of the notified body.
The owner or manager of the lift checks that the scheduled maintenance visits defined in the contract with the maintenance company are carried out with the agreed deadline and also checks that the notified body performs the pertinent checks.
In this case the control panel must recognize and record the access to the system in case of maintenance and / or verification and send a signal (e-mail report or a message).
The owner or manager of the lift records the event and can make the data available to the owners of the building.
Figure 12.28.7.1-1 Management of maintenance and inspection visits of the lift or group of lifts: Overview
12.28.7.2 Source
RDM-2020-0011R03-Smart_Lifts_Use_Cases
Note
informative sources refer to ETSI TR 103 546 Requirement & Feasibility study for Smart Lifts in IoT, Section 6.1[i.22].
12.28.7.3 Actors
- [X] Building owner.
- [X] Maintenance companies.
- [X] Maintenance technicians.
- [ ] Passengers without priority.
- [ ] Passengers whit priority (disabled people, elderly people, etc).
- [ ] Supplier technicians (especially of control cabinet).
- [ ] Control room operator.
Note
the list above shows the actors identified in clause 6.3.3, those that are relevant for the current use case are marked with the symbol X.
12.28.7.4 Pre-conditions
Building managers (condominium administrators or real estate management companies) report property owners on the expenses incurred in general building management. In the specific case of the lift, a maintenance contract is stipulated with the company in charge that provides for a number of maintenance visits (defined according to the type of plant) to keep the plant in efficient service. Furthermore, periodically, a notified body must verify the lift safety devices.
12.28.7.5 Triggers
The maintenance technician, who arrives on the plant, by means of the control panel, activates the maintenance operation mode and automatically sends a signal (e.g. e-mail or message) to the operator who can record the intervention and check whether it is congruous with the planned dates of the contract.
12.28.7.6 Normal Flow
The plant manager receives:
- maintenance start signal.
- end of maintenance signal.
- inspection start signal.
- end of inspection signal.
12.28.7.7 Alternative flow
None
12.28.7.8 Post-conditions
Records are kept demonstrating that maintenance activities have been performed according to the planned schedule.
Supervision authorities are notified that maintenance complies with regulation mandates and best practices.
12.28.7.9 High Level Illustration
None
12.28.7.10 Potential requirements
No specific new features are currently identified as result of the analysis of Smart Lift use cases. The oneM2M system Rel 3 seems to support properly these use cases. It remains necessary to include the data structure to be exchanged by Smart Lifts in the oneM2M semantic work. As it is also deemed to be included in the ETSI SAREF package to assure proper semantic interoperability with other systems it is also necessary to verify the SAREF alignment.
- oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in [i.21].
12.28.8 Call/Reserve Lift Car via Smartphone App
12.28.8.1 Description
This case concerns the passenger's interaction with the elevator via an application downloaded to the smartphone. The application allows you to call the predetermined elevator lift car and take it to the desired floor using an application and/or voice control. There is also the possibility of receiving notifications about scheduled maintenance or down time.
In this case, the application itself is made to provide an acknowledgment of the elevator or elevators to be used (an application can register and recognize multiple installations) via a QR Code. At this point, the passenger near the elevator can proceed to the choice of the lift, its identification and the call of the lift car on the desired floor. The application will exchange the request with the lift controller framework that will verify the ability to handle the call by bringing the cabin to the desired floor.
Figure 12.28.8.1-1 Call/Reserve Lift Car via Smartphone App: Overview
12.28.8.2 Source
RDM-2020-0011R03-Smart_Lifts_Use_Cases
Note
informative sources refer to ETSI TR 103 546 Requirement & Feasibility study for Smart Lifts in IoT, Section 6.1[i.22].
12.28.8.3 Actors
- [ ] Building owner.
- [ ] Maintenance companies.
- [ ] Maintenance technicians.
- [X] Passengers without priority.
- [X] Passengers whit priority (disabled people, elderly people, etc.)
- [ ] Supplier technicians (especially of control cabinet).
- [ ] Control room operator.
Note
the list above shows the actors identified in clause 6.3.3, those that are relevant for the current use case are marked with the symbol X.
12.28.8.4 Pre-conditions
The plant manufacturer or maintainer makes a QR code of the elevator visible (in and/or near the elevator).
A suitable app is installed on the passenger's smartphone.
The user of the system, with the smartphone or similar device, recognize through the QR code the application downloaded to the device. Once the application installed, the passenger will be able to identify the system and send the call request to the floor both near the elevator and at a distance. The control panel recognizes the request, verifies the status of the system and accepts the call, sending the lift car to the desired floor.
12.28.8.5 Triggers
The passenger is able to identify the system (via the QR codes) and sends the call request to the floor both near the elevator and at a distance.
12.28.8.6 Normal Flow
The control panel recognizes the request, verifies the status of the system and accepts the call, sending the lift car to the desired floor.
Passenger receives from lift car:
- lift car position (floor number).
- lift car status (if doors open/closed).
- lift car direction (ascending/descending).
- lift car status (moving/out of service).
12.28.8.7 Alternative flow
None
12.28.8.8 Post-conditions
None
12.28.8.9 High Level Illustration
None
12.28.8.10 Potential requirements
No specific new features are currently identified as result of the analysis of Smart Lift use cases. The oneM2M system Rel 3 seems to support properly these use cases. It remains necessary to include the data structure to be exchanged by Smart Lifts in the oneM2M semantic work. As it is also deemed to be included in the ETSI SAREF package to assure proper semantic interoperability with other systems it is also necessary to verify the SAREF alignment.
- oneM2M shall support Smart Lift data model and its possible evolution, e.g. as identified in [i.21].