We consider a host of different actions and processes to be able to respond to customer needs quickly. One important ingredient, we look at in the mix, is having the right software infrastructure built around processes that help us to improve our customer’s experience with our products.
To achieve this, we’ve created an infrastructure that is highly responsive to analyze live data and perform actions based on the result of their interpretation. For example, being prepared to respond to live incidents quicker, or to improve the maintenance logistics of the product.
That’s also why elevator systems need to be tuned to today’s quality standards.
In the information systems industry, this corresponds to creating a scalable, reliable, and maintainable system. We achieve this thanks to tools like APIs and cloud computing.
In addition, the right environment needs to be built around these processes, with different layers of protection for maximum security around the data.
Let’s take a look at an example of how we ensure reliability and protection on a task, like the enrollment of a newly delivered elevator in our digital systems, and how we enforce safe data exchange with our cloud.
New elevators are shipped in different modules, and each of these components has its own ID that is stored remotely. There are some excellent reasons to do it this way: it’s easier for the elevator operators to assemble it, it’s easier to register the single component, and in case of a single faulty part, it’s easier for us to backtrack its type and schedule a replacement.
The registration of a module happens through an API that can be reached from both the elevator itself and any other device that can authenticate itself.
We use Azure to host both the API and the database, by an App Service and a SQL Server or Postgres instance.
We secure the connection through HTTPS and client certificates, generated by an internal trusted authority, that are installed on the machine.
An example of one component we may want to install is the belt. To do this we call a PUT endpoint, to which we specify the identification number of the component and the manufacturing date.
An HTTP request is sent to the API carrying a certificate.
TLS (the layer that transports the certificate), by design, terminates after the HTTP request is received by Azure, so the certificate cannot be sent directly to the application.
To solve this, the Azure App Service will inject the certificate via the headers of the request and send it to the API [1].
Then the application will check if it is valid.
It does this by checking its chain and comparing its thumbprint with the thumbprint of our certified trusted authority. If the authentication is successful, the belt data is stored and a 200 (Success) is returned.
In the future, we may need to update wrong data, like the manufacturing date. To do this, we can then call the same PUT endpoint, because we expect an update will always produce the same result (idempotence), that other verbs like POST don’t guarantee [2][3].
In the image, a documentation example generated by Swagger tells us the PUT endpoint url (/Elevators/{elevatorId}/belts) that we can use to modify the manufacturing date property of a left belt with ID 1234 and a right belt with ID 1235 associated to an elevator with ID 42, an example of the model we can send written in json, and all possible HTTP codes that this request can return.
Besides the case above, there are many scenarios in which this can take place.
From a logistics point of view, we may take into consideration the example of a substitution of a component like the brakes. Components like brakes get consumed mainly by usage and not by time. So, creating a generic alert to replace them after several years is not the best way to do this.
Retrieving and storing live data can help us create alerts based on how many times components are used, like scheduling a change of brakes when they hit the pre-defined maximum number of cycles. This lets us define a usage expiry rather than an expiration date.
Also, by making a whole remote service available based on the live information from the elevator, and given the chance to interact with it, the potential of this system become infinite. This produces what we can call a complete "transport as a service", from being able to schedule and control a smart and complex system like the one provided by Schindler PORT, to fully automated agents that can take advantage of it.
References
[1] Access client certificate
[2] HTTP Request Methods
[3] Microsoft API Guidelines