Licenses for Offline Devices
Industry 4.0, IoT, IIoT, SaaS, Azure, and AWS: We are living in a world of devices that are always online and communicating with each other in the cloud. This is definitely true for office and home electronics, but it is only slowly picking up in the industrial realm. The makers of revolutionary smart controllers and devices who want to find ways to monetize their software face an uphill challenge: How to roll out licenses and license updates to offline devices. CodeMeter offers not one, but several ways to do so.
Not entirely offline
The 1996 blockbuster “Independence Day” included the iconic line: “Mr. President, that is not entirely accurate.” Another thing that is not entirely accurate is the belief that certain devices are completely offline and cut off from the outside world. With this in mind, let us consider how CodeMeter licenses are allocated.
Whenever any message is shared, the transfer can occur in either of two ways: Push or pull. Push messages are sent from a central server to a local device; the server decides when to initiate the transfer and calls a service that is running permanently on the target device, not unlike the webservers that run on such devices for configuration purposes. However, many companies keep their devices seemingly offline by blocking this access route – and that is why CodeMeter does not include a standard push implementation.
The alternative option for push messages is that the target device has a special client software installed that establishes the connection with the server in the cloud and logs on in order to receive the push messages. The server can then use the opened channel, and the target device receives the messages. This method again requires a permanent Internet connection and a permanently active client. This is the method used e.g. by iPhones: The operating system provides the client and push message server as ready-made infrastructure, which means that only a connection needs to be kept open – which, however, is again a problem for many industrial users.
Pull messages are received by the client on the device regularly checking in with the server whether there are any new messages. The connection is outbound, with dedicated and known data packages sent to a dedicated server. The answer is verified by the client before it is used, which keeps the security risk down. In some projects, this option is available, which is why Wibu-Systems supports it with the Software Activation Wizard (as the client) and CodeMeter License Central. The client does not even have to run permanently. In most cases, it is run automatically at regular intervals, e.g. once per day (Cron-Job); a manual launch can also be required for special cases.
Bridges and Ferries
Whenever a device cannot or must not create an outbound connection with the Internet, a separate computer can often be used as a bridge. That computer is located on the internal network and can therefore access the target device. At the same time, the computer can make the connection with CodeMeter License Central on the Internet. A service technician would initiate the update, which would then be transferred automatically without any further manual intervention by the technician.
This can be implemented in two ways: The first option is to include the entire technology in a webserver that is usually already available on the device. The technician would then only have to use a browser to call that webserver.
The second option is a customized Software Activation Wizard on the technician’s computer. The wizard uses the gateway API to communicate with CodeMeter License Central and a proprietary protocol to speak with the target device, which is usually already made available by the device’s maker. Typically, only three new types of transactions need to be added: Listing CmContainers, receiving the context file of CmContainers, and using update files for CmContainers.
Using a software activation wizard offers another great advantage: If it is not possible to create a simultaneous connection with the device and with the Internet, the context and update files can be ‘parked’ and the process broken down into three separate steps. The third and final step is optional, as it only handles the receipts. This approach could be visualized as a ferry service that moves from riverbank to riverbank.
License Transfer (Move)
In this scenario, any number of licenses can be transferred onto a CmDongle (the transfer dongle). The target device that these licenses are intended for does not have to be known at this point. A service technician would use the transfer dongle and connect his laptop with the target device, resembling the bridge with CodeMeter License Central. The license is again transferred as in the case of the bridge: A special lean Software Activation Wizard uses the proprietary protocol to transfer the licenses, and the mentioned three transactions again handle the process.
The magic happens offline in this case, which is a blessing and a curse. No Internet connection is required, but that also means that CodeMeter License Central has no up-to-date information about the licenses’ current state, which limits the ability to update licenses. The approach is particularly good for rolling out individual additional licenses (as separate Product Items), but not for updating licenses.
Let us return to the push approach: Once a device is known to CodeMeter License Central, a context file of the CmContainer on the user’s device will be available in CodeMeter License Central, and the update file can be created for the target device. No data from the device, except the serial number of the used CmContainer, is needed to create the license update. The assignment between license and CmContainer can already be made when cre-ating the license in CodeMeter License Central or later by the technician on site, when they download the license update.
The update file can be imported onto the device via a memory stick, requiring only one new transaction “Using update files”. All of this can happen locally on the target device without any additional computer or proprietary protocol, or the bridge approach can be replicated by importing the file via a webserver and browser on the technician’s computer.
It is not a problem if an update is missed in this case. If CodeMeter License Central did not receive a confirmation that the license has arrived at the target device, it will include all older updates in the next update. This is transparent for the user, as the updates are all packaged up in one combo-file.
This resembles the ferry scenario, with the only difference that the selection of a CmContainer in CodeMeter License Central or WebDepot is replaced by the creation of the context file. This can be done beforehand without technicians needing physical access to the target device.
KEYnote 39 – Edition Spring 2020