The platform took 7 months to build (with several-week breaks, during which the client worked out solutions for the next modules).

This project will stay in the memory of Nettom's team for a long time — both because of how long it took, its interesting and out-of-the-ordinary subject matter, and the later mentions in the press and on television :)

To top

The hierarchy consists of three separate levels.

At the top level is the LAMBDA administrator, who defines clients. Clients own the installations and choose their service provider, who is responsible for the proper functioning of the installations.

Once the administrator creates a client account, the client can personally manage the services provided by the service provider. For their part, the service provider can manage installations, data access, and so on.

To top

There are different types of users with different permissions. The two basic groups are "service provider" and "client."

• Service provider – manages the elevator; they receive notifications about problems and respond to them.
• Client – owner of the elevators.
• Client admin – can create service provider admin accounts, who can, in turn, create other service provider-type accounts (except admin).
• Client admin accounts are created by the administrator (LAMBDA).
• There can be multiple accounts of each type, except for the Main Administrator account, which is unique.
• Service provider – data recipient: Receives event signals and can manually enter events into the database.
• Service provider – consultant: Can only view the database.
• Service provider – secretary: Can enter information about maintenance technician interventions.
• Service provider – Admin: Can act as a recipient, consultant, and secretary, and can manage the elevator groups assigned to them.
• Client: Can view the database and statistics.
• Client admin: Can create elevator teams and assign them to a given service provider.
• Administrator (LAMBDA): Can do everything except create administrator accounts.
• Main Administrator (LAMBDA): Can do everything.

To top

Installations and users are organized into groups, similar to "workgroups" in a computer network.

• A user is only permitted to view installations within their own group.
• A user can belong to multiple groups.
• An installation can belong to multiple groups.

To top

User of the type customer the admin can create groups whom elevators contain and users of the type customer (and customer admin).
User the admin can create groups whom elevators contain and users of the type contractor.

To top

Manual event entry

The user should be able to manually add an event to the list of events for an installation. This occurs as a result of a client complaint made by letter, fax, phone, etc. … when the camera system has not yet transmitted the information to the database.

The entry window should allow a text area to be filled in either manually or via a pop-up list (e.g., "phone call from Mr. Kowalski").

The error should be selected from a pop-up list; the list of errors is predefined.

The error type is either "appearance" or "disappearance."

The date and time are recorded automatically.

Deleting an event

The user must be able to click on an event to delete it.

This means that if the system received a notification about an elevator failure, but the clearing of the error was never recorded, and the return of the elevator to service is confirmed, the user can manually add the end of the failure to the database. The name of the user who deleted the event will be recorded along with the date and time of deletion.

Entering data on interventions performed by the elevator manager

Each installation must have an assigned table containing a list of repairs carried out on that elevator.

The user should be able to select the installation and add information about completed repairs to the list.

The user must have access to a list of possible interventions, parts used, etc. This list will be defined by LAMBDA, who will also be able to modify it.

The user should be able to select items from the list with a single click.

The entry date will make it possible to determine whether the intervention took place in the morning or in the afternoon.

The user can also select the type of intervention (repair, urgent repair, maintenance), the technician's name, and the elevator manager's name (automatically).

The name of the user who added the intervention to the list will be recorded along with the date and time the data was entered.

Viewing intervention data

The client should be able to list interventions for one or multiple elevators, filtered by date range, elevator groups (residential building, CP), and elevator manager.

Alert upon receiving an event

If the user is a "service provider – data recipient," the window should draw their attention to a received event via a pop-up or another eye-catching method.

Only events received from installations assigned to the given user trigger a pop-up.

Only one pop-up window should appear at a time.

The user must be able to see the list of events received but not yet resolved.

The name, address, defect (clearly specified), defect type, time, and date should be displayed.

Each event must have a text area that the user can fill in from a pre-configured pop-up list containing "standard" texts defined by LAMBDA.

A checkbox for "resolved" (completion, clearing?).

A "resolve all" option.

When an event is marked as resolved, the name and details of the user are also recorded.

Event color and priority

Priority and color can be associated with each defect type.

A high-priority event (e.g., passengers trapped in the elevator) will be displayed at the top of the list, in a bright color. The display order of other events will depend on priority and order of arrival. This sorting applies to unresolved events; once resolved, events are listed chronologically, from oldest to newest (at the top of the list).

Event filtering

Event filtering will be possible; all filtered-out events will not trigger a pop-up and should be removed from view.

Alert for event duration

It is possible to set up an alarm if certain events last too long (e.g., a technician's presence on site). This can be configured by the user depending on the event type and its duration.

To top