Using the virtual terminal for universal remote access
This article explains the concept of the virtual terminal interface defined in the CiA 417 Lift application profile. It also describes the motivation and needs of this interface and tries to promote the power and the benefits given, together with a summary of the functionalities and the implementation.
In a complete lift control system, there are many different intelligent devices today. Of course, first there is the main controller, which could be considered the “brain” of the system, but there are also the VVF inverter (for an electrical lift) or the hydraulic drive for a hydraulic lift, the door operator, the load measuring unit, the car and floor panels, and so on. All these interconnected devices are now complex electronic devices, and to best fit the targeted lift, most of the time a local HMI (human-machine interface) is integrated to adjust the parameters and give a better diagnosis when needed. Some of these devices also propose an optional remote tool, but very often with a specific protocol upon a specific wire, which offers a friendlier HMI. Now think of the lift technicians during installation or maintenance, as they have to master all of the tools of all the devices. Just think of your living-room table with the set of four or five remote controls – and sometimes more for your home audio-video devices (TV, DVD-player, recorder, audio amplifier, satellite decoder) – and you won't be far from the problem of our technician.
But even if the technicians are quite at ease with many different tools, the physical access to the devices becomes also more difficult. Nowadays, with the increase of machine roomless lifts, the frequency inverter and sometimes the main controller – the most consulted devices – are very often located in the lift shaft.
There are two issues to solve: the universality of the tool and the remote access with this tool. And for years, a solution has been offered by the CiA 417 CANopen application profile for lift control systems.
Members of the CANopen SIG (Special Interest Group) Lift have developed the CiA-417 application profile. These members are different designers and manufacturers of lift equipment located in different European countries. This profile, whose main objective is to ensure interconnectivity of lift devices, describes how data is exchanged over a CAN network based on the CANopen application layer (internationally specified in EN 50325-4, also known as CiA 301).
In the communication profile area of the CANopen object dictionary, the CiA-301 defines the “OS prompt” object (Index = 1026h) in order to permit remote configuration and remote debugging of a can node. This is done by the use of well-known input and output streams: the stdin and stdout. Sub-index 01h of object 1026h is the stdin, and sub-index 02h is the stdout, each of one byte. These entries are intended to send a keyboard character to a node (the stdin) and receive a text character from this node (the stdout).
Inspired by this object, the CiA-417 profile introduces the Virtual Terminal Interface object (at index 600Ah) with the two same sub-indexes but with a size of 4 byte to improve the stream transfer rate. With the "front-end" contents of the standard input/output streams (keyboard/screen), this is the best way to achieve compatibility with any HMI, and therefore to have a unique tool, which is able to connect to every device of a lift system, while the remote access is inherently given by the connection upon the CAN network.
Both nodes, the remote tool and the lift device consulted, shall implement the virtual terminal interface object, with opposite accesses (the remote tool sends the stdin, and receives the stdout, while the lift device receives the stdin and sends the stdout). But what is the best service to transmit this data? It clearly looks like the connection between both nodes should be in a peer-to-peer manner with client/server relationship: the remote tool is the virtual terminal client, which wants to virtualize the HMI of the lift device, which is then the virtual terminal server.
First we naturally think of SDOs, as SDOs are designed for a peer-to-peer connection in a client/server relationship and the range of CAN-IDs for SDOs have lower priority than PDOs so the transfer of HMI data won’t disturb more important data. But for every SDO client request, there is a response of the SDO server. It could slow down the transfer rate and cause bad behavior of the remote tool because of a delay (remember how unpleasant it is to press a key and see the screen react one or two seconds after). SDOs should be used, as the problem of the delay will only be relevant when using big HMI with a lot of characters to be transferred, but there is the need to find a more efficient transmission service.
Then we naturally think of PDOs, which are designed to process data, (this is the case with stdin/stdout), but the broadcasting of a PDO is a little bit annoying: every virtual terminal server will react to the transmission of the stdin (600A 01h) by the virtual terminal client! Because we need a peer-to-peer connection and because there are up to 127 nodes connected on a CANopen-Lift profile network, that means 127 different PDOs have to be defined only for the remote access of each device. This reduces the range of other PDOs available on the network for other purposes drastically. So normal PDOs are not the best solution either.
There is another service available, not the most well known, but recommended by the CiA 417 for transmission of virtual terminal data: the MPDO service. MPDO stands for Multiplexed Process Data Object. In a nutshell, these objects are hybrids between SDOs and PDOs.
There are no PDO mappings for MPDOs as the address of the object (index and sub-index, called the multiplexer) is given in the message like a SDO, but this transfer is without confirmation, like for a PDO. MPDOs allow multicasting and unicasting with up to 4 byte of data within each message. There are two kinds of MPDOs: the DAM-MPDO and SAM-MPDO, meaning “Destination Address Mode” and “Source Address Mode”. The names simply indicate that the multiplexer is a reference object of the transmitter in SAM mode or of the receiver in DAM mode. The SAM-MPDO allows multicasting, while the DAM-MPDO is used for unicasting.
Using a DAM-MPDO, the virtual terminal client (the remote tool) sends key-codes to the virtual terminal server, which answers by SAM-MDPO carrying screen characters. The used key-codes and screen characters are from standard ASCII codes according to ISO 88915. The virtual terminal server may also use control sequences (e.g. to clear lines or move the cursor in only one command), defined by the old but efficient VT52 terminal. More details on the contents of the transmission can be found in the CANopen-Lift wiki.
Table 1: Virtual terminal commands
Let’s go back to a whole lift installation compliant to the CiA 417 profile and lets explore the benefits of the virtual terminal. With a main controller that implements the client interface, every HMI of each device is reach able from the cabinet where the controller is located. Directly from there, the lift’s technician can access, configure and diagnose all other devices of the lift (which, of course, implements the virtual terminal server interface). The HMI of the controller is used first to set the controller, but in a dedicated menu, it can offer to connect to these other devices. The controller’s HMI buttons then act on the HMI of the remote device, and the controller’s HMI screen becomes the screen of the remote device’s HMI: its terminal has been virtualized.
The controller may also implement the virtual terminal server in order to be accessed by a remote tool. Some manufacturers implement it in their controller and propose a smartphone application. This application is nothing more than a virtual terminal client, and with a wireless gateway connected to the CANopen bus, the smartphone becomes the remote tool of the controller, which is now accessible almost anywhere in the lift installation. It’s very useful for the technician, who very often works around the lift’s car.
Another very significant use case is the virtualization of the frequency inverter’s terminal by the controller. As said before, in a machine room-less lift, the inverter is located in the shaft, and thanks to the virtual terminal, the technician can configure it from the controller located on the floor, more at ease than if he had to be in the shaft. This case is such a frequent occurrence that the virtual terminal object is mandatory for an inverter device. It simply means that an inverter that doesn’t implement this object can’t be CANopen-Lift certified.
HMIs in industrial equipment are evolving, especially in size and the kind of screen. The use of this kind of HMIs is growing in lift devices and so the virtual terminal interface has to evolve. The next step will be to define inside the application profile how to virtualize the graphical displays and not only the alpha-numeric displays, together with a complete description of the HMI, in order to be able to virtualize it in the best way.
Even with these needed evolutions, we can see the power and efficiency of the concept, as with it a lot of things become possible regarding accessibility of CANopen-Lift devices. So there are no boundaries to extend this virtual terminal interface from the lift profile to many other industrial profiles where the HMI’s access to every device is needed.
Published at CAN Newsletter October 2013 - Author: David Souche - Sprinte